جاوااسکریپت و سئو، چالش همیشه تیم فنی

اگر یک بار هم در جلسه‌ی مشترک «سئو + تیم فنی» نشسته باشید، احتمالاً این سناریو را دیده‌اید: متخصص سئو می‌گوید «محتوای اصلی در سورس نیست، لینک‌ها کراول نمی‌شوند، ایندکس دیر می‌شود»، و برنامه‌نویس با اعتمادبه‌نفس جواب می‌دهد: «گوگل که جاوااسکریپت رو می‌فهمه؛ مشکلی نیست.» همین‌جا دقیقاً همان نقطه‌ای است که پروژه‌ها وارد یک جنگ فرسایشی می‌شوند؛ جنگی که نه به نفع سئو است، نه به نفع تیم فنی، و نه به نفع کسب‌وکار.

واقعیت این است که مسئله «توانستن یا نتوانستن گوگل» نیست؛ مسئله هزینه و اولویت است. گوگل می‌تواند جاوااسکریپت را رندر کند، اما این کار برایش گران‌تر، کندتر و پرریسک‌تر از خواندن HTML آماده است و در مقیاس وب، تصمیم‌های گوگل همیشه اقتصادی و به صرفه اند! همین نکته ستون اصلی دعوای شما با “جاوااسکریپت‌ سالارها” است. محسن طاوسی یک جمله معروف دارد و آن این این است که اغلب فنی ها، دید تجاری ندارند و همه چیز را بر پایه تکنولوژی و مقدور بودن می سنجند و نه بر پایه صرفیدن و توجیه مالی داشتن!

گوگل با جاوااسکریپت دشمن نیست، با هزینه‌ی آن مشکل دارد

در نگاه فنی، توسعه‌دهنده می‌گوید: «مرورگر کاربر جاوااسکریپت را اجرا می‌کند و صفحه کامل نمایش داده می‌شود؛ پس گوگل هم باید بتواند.» اما متخصص سئو باید نگاه دیگری داشته باشد: گوگل مرورگرِ همه‌ی دنیا نیست. گوگل باید میلیاردها URL را دریافت کند، HTML را بخواند، منابع را دانلود کند، رندر کند، جاوااسکریپت را اجرا کند، DOM را بسازد، لینک‌ها را استخراج کند و بعد تصمیم بگیرد چه چیزی ارزش ایندکس دارد. این زنجیره در مقایسه با «خواندن HTML آماده» چند برابر منابع CPU/RAM/Storage و پهنای‌باند می‌خواهد و این همان جایی است که گوگل برای همه سایت‌ها «یکسان و نامحدود» خرج نمی‌کند.

به همین دلیل گوگل در مستندات رسمی‌اش، به جای اینکه بگوید «نمی‌توانم»، می‌گوید: «توصیه نمی‌کنم» یا «راه‌حل بلندمدت نیست». این ادبیات، همان سیاست همیشگی گوگل است: ضعف را مستقیم نمی‌گوید، اما مسیر توصیه‌شده را واضح اعلام می‌کند. گوگل در این لینک دقیقا این جمله را نوشته است: While Google Search does run JavaScript, there are some differences and limitations that you need to account for when designing your pages and applications to accommodate how crawlers access and render your content. 

اما واقعیت این است که گوگل سیاستی در مستندات خود دارد که اشاره به ضعف نمی کند(به نقل همیشه محسن طاوسی) و خیلی ظریف ضعف خود را بیان می کند. برای مثال در جمله بالا گوگل گفته است گوگل جاوااسکریپت را اجرا می کند اما یک سری تفاوت ها و محدودیت هایی وجود دارد اگر می خواهید خزنده های گوگل، بتوانند محتوای شما را بخوانند! و وقتی عمیق شوید می بینید که کلا نمی تواند بخواند! مگر اینکه محتوای خود را برای گوگل، بدون جاوااسکریپت نشان دهید!

“View Source” با “DOM” یکی نیست

یکی از کاربردی‌ترین راه‌ها برای پایان دادن به بحث‌های نظری این است که از تیم فنی بخواهید این تست ساده را انجام دهند:

• صفحه را باز کنید
• View Source (مثلاً Ctrl+U) را ببینید
• دنبال «محتوای اصلی اولیه» بگردید

اگر محتوای اصلی، عنوان‌ها، متن محصول/خدمت، لینک‌های داخلی مهم و حتی داده‌های ساختاریافته، در HTML اولیه (سورس) وجود نداشته باشد و فقط بعد از اجرای JS به DOM تزریق شود، شما وارد قلمرو ریسک‌های سئو شده‌اید: کراولِ گران‌تر، رندرِ عقب‌افتاده، لینک‌های دیر کشف‌شده و ایندکسِ غیرقابل پیش‌بینی. یعنی به طور خلاصه «Initial Main Content باید در سورس باشد». محتوای اصلی اولیه باید بدون نیاز به اجرای جاوااسکریپت، در سورس(نه DOM) باشد. این جمله دقیقا تأکید محسن طاوسی در مقاله مشکل گوگل با سئو سایت های جاوااسکریپتی است.

گوگل هم در راهنمای JavaScript SEO Basic دقیقاً درباره‌ی نحوه پردازش محتوای JS و مشکلات رایج (مثل SPAها، soft 404، روتینگ کلاینت‌ساید و…) هشدار می‌دهد.

چرا SPA و SEO در تضادند؟

Single Page Application برای تجربه کاربری عالی است؛ اما برای سئو، یک شرط دارد: هر URL باید نماینده‌ی یک محتوای واقعی و منحصر به فرد باشد و آن محتوا باید از دید خزنده قابل دریافت باشد. یعنی عملا دیگر Single Page نباشد!

در بسیاری از SPAها شما ظاهراً با کلیک روی دسته‌بندی‌ها، فیلترها یا حتی صفحات محصول «صفحه عوض می‌کنید»، اما در واقع:

• HTML اولیه ثابت است.
• محتوا با JS جایگزین می‌شود.
• صفحه ای جز صفحه نخست که قابل ایندکس باشد وجود ندارد!
• وضعیت‌های HTTP و سیگنال‌های ایندکس‌پذیری مبهم می‌شوند.
• و گوگل ممکن است این رفتار را به شکل soft 404 یا محتوای ناقص تفسیر کند.

پس بحث شما با تیم فنی نباید «SPA خوب نیست» باشد؛ بحث باید این باشد: در هر صفحه‌ای که برای سئو مهم است، رندر باید SSR باشد. یعنی عملا SPA نمی تواند قابل SEO باشد! صورت مساله پاک می شود!

لینک‌ها: جایی که جاوااسکریپت، خرابکاری می کند!

خیلی از پروژه‌ها از محتوا ضربه نمی‌خورند؛ از «لینک» ضربه می‌خورند.

تیم فنی ممکن است لینک‌ها را با کلیک‌هندلر، routerLink، onClick، یا تولید در لحظه با JS پیاده کند. برای کاربر انسانی عالی است؛ اما برای خزنده، همیشه قابل اتکا نیست.

گوگل در مستندات رسمی Link best practices واضح می‌گوید برای اینکه لینک‌ها قابل خزش باشند، شکل استاندارد تگ a با href اهمیت دارد.

Dynamic Rendering؛ چرا گوگل عقب‌نشینی کرد؟

سال‌ها «Dynamic Rendering» به عنوان یک راه‌حل میانی مطرح می‌شد: به کاربر نسخه CSR بدهید، به ربات نسخه رندرشده روی سرور. اما گوگل خودش در مستندات رسمی می‌گوید dynamic rendering فقط یک workaround است و راه‌حل توصیه‌شده/بلندمدت نیست.

این نکته خیلی مهم است، چون قبلا گوگل داینامیک رندرینگ را توصیه می کرد. اما بعد از چند سال گفت راه حل توصیه شده و دائمی نیست و باید به شکل سنتی به هر شکل ممکن برای من SSR یعنی Server Side Rendering باشد.

پس راه‌حل چیست؟ SSR، Static، Hybrid؛

شما لازم نیست تیم فنی را مجبور کنید «همه‌چیز SSR باشد». شما باید دقیق تعریف کنید:

هر صفحه‌ای که قرار است در گوگل رتبه بگیرد، باید “محتوای اصلی اولیه” را در HTML پاسخ سرور به صورت SSR داشته باشد. بحث محتوای اصلی اولیه یا Initail Main Content همیشه جزئی از آموزش ها و تأکید های محسن طاوسی در بهینه سازی تکنیکال سایت های مبتنی بر جاوااسکریپت برای گوگل بوده است. با این تأکید که این محتوای اصلی اولیه، باید حتما به صورت سرور ساید رندر شود و در سورس صفحه وجود داشته باشد (نه DOM).

این می‌تواند با چند مدل انجام شود:

• SSR (Server-Side Rendering): HTML کامل (یا بخش اصلی) روی سرور تولید می‌شود و به مرورگر/ربات می‌رسد.
• Static Rendering / Pre-render: نسخه HTML از قبل تولید می‌شود (Build time یا Cache/CDN) و سریع سرو می‌شود.
• Hybrid Rendering: محتوای اصلی اولیه SSR/Static، و باقی تعاملات (فیلتر، سورت، کامنت، نوتیف) با CSR. این همان چیزی است که هم سئو را حفظ می‌کند هم تجربه کاربری مدرن را نابود نمی‌کند.

یعنی عملا برگشتیم به همان روش سابق همیشگی!

چک لیست SEO برای صفحات مبتنی بر Javascript

1. Initial Main Content در HTML اولیه باشد (در View Source قابل مشاهده) (نقل از محسن طاوسی با تکیه بر مستندات و واقعیت های گوگل در SERP)
2. هر URL یک محتوای منحصر به فرد داشته باشد و با روتینگ کلاینت‌ساید به soft 404 تبدیل نشود.
3. لینک‌های داخلی مهم با a href ارائه شوند (نه صرفاً onClick).
4. وضعیت‌های HTTP واقعی (200/404/301) کاملا سرورمحور یا SSR باشند (نه فقط نمایش پیام در UI).
5. از راه‌حل‌های موقتی مثل Dynamic Rendering به عنوان مسیر اصلی استفاده نشود. صرفا نگاه موقت.

مشکل واقعی جلسات سئو با تیم فنی

چرا توسعه‌دهنده مقاومت می کند؟ چون معمولاً احساس می‌کند متخصص سئو آمده «به تکنولوژی محبوبش حمله کند». پس شما اگر بحث را این‌طوری مطرح کنید که «جاوااسکریپت خوب نیست»، با مقاومت صددرصد تیم فنی روبرو می شوید.

اما اگر بحث را این‌طور ببندید، فضا عوض می‌شود:

• «JS برای تعاملات عالی است.» (تأیید واقعیت فنی)
• «اما برای صفحات ورودی گوگل، باید هزینه رندر را از دوش گوگل برداریم.» (منطق اقتصادی و مقیاس)
• «پس بیایید فقط صفحات قابل رتبه را SSR/Static/Hybrid کنیم.» (راه‌حل میانی و عملی)

جمع‌بندی: شما دنبال “SEO-Friendly JS” هستید، نه “No-JS”

اگر بخواهیم یک جمله‌ی نهایی داشته باشیم:

• گوگل با جاوااسکریپت دشمن نیست؛ با هزینه‌ی جاوااسکریپتِ شما در مقیاس وب مشکل دارد.
• پس شما باید کاری کنید که در موج اول دریافت صفحه، گوگل همان چیزی را ببیند که برای رتبه گرفتن لازم است: HTML واقعی، لینک‌های قابل خزش، وضعیت‌های درست، و محتوای اصلی اولیه.