اگر سایت شما با جاوا اسکریپت ساخته شده یا بخش مهمی از رندر و نمایش محتوا را به JavaScript سپردهاید، احتمالاً بارها این جمله را شنیدهاید که «گوگل میتواند JS را رندر کند». مسئله این است که «میتواند» با «حتماً انجام میدهد» فرق دارد. آپدیتهای مستندات رسمی گوگل در دسامبر ۲۰۲۵ دقیقاً همین فاصله را هدف گرفتهاند و با یک پیام خیلی روشن جلو آمدهاند: برای اینکه گوگل اصلاً به مرحلهای برسد که جاوا اسکریپت شما را اجرا کند و سیگنالهای بعد از رندر را ببیند، باید دو چیز از اول درست باشد: پاسخ سرور (بهخصوص کد وضعیت ۲۰۰) و هماهنگی سیگنال کانونیکال بین HTML خام و نسخه رندرشده.
اینجا موضوع فقط «ایندکس شدن یا نشدن» نیست. پای انتخاب نسخه درست URL، تجمیع اعتبار لینکها، جلوگیری از تکراری شدن صفحات، کنترل پارامترها و حتی دیده شدن محتوایی وسط است که فقط بعد از اجرای JS ساخته میشود. وقتی یکی از این دو پایه بلرزد، گوگل ممکن است یا اصلاً رندر نکند، یا رندر کند ولی به خاطر تناقض سیگنالها نسخهای را بهعنوان canonical انتخاب نماید که شما انتظارش را ندارید.
گوگل در صفحه «Latest Google Search Documentation Updates» و همچنین در راهنمای «JavaScript SEO basics» چند نکته را اضافه و پررنگ کرد که عملاً یک نقشه راه عملی به شما میدهد:
کانونیکالسازی قبل از رندر و بعد از رندر انجام میشود. پس اگر با جاوا اسکریپت canonical را تغییر میدهید، باید همان URLی باشد که در HTML خام اعلام کردهاید. اگر اینکار ممکن نیست، بهتر است canonical را از HTML خام حذف کنید تا دو سیگنال متناقض تولید نشود.
همه صفحاتی که کد وضعیت HTTP 200 دارند به صف رندر (Rendering Queue) ارسال میشوند، چه جاوا اسکریپت داشته باشند چه نداشته باشند. اما اگر کد وضعیت غیر ۲۰۰ باشد، رندر ممکن است کلاً انجام نشود.
نکته مهم این است که این دو پیام جدا از هم نیستند. در عمل، دومی پیشنیاز اولی است؛ چون اگر صفحه وارد رندر نگردد، هر چیزی که شما «بعد از رندر» با JS میسازید (از جمله canonical، محتوای اصلی، لینکهای داخلی تولیدشده با JS و غیره) ممکن است اصلاً دیده نشود.
برای فهم این موضوع، باید رفتار واقعی گوگل با صفحات جاوا اسکریپتی را به زبان ساده تصور کنید:
در قدم اول، گوگل پاسخ اولیه سرور را میگیرد. این همان HTML خام است، قبل از اینکه جاوا اسکریپت اجرا شود.
بعد، اگر URL وارد صف رندر شود، گوگل یک نسخه رندرشده هم تولید میکند (با اجرای JS) و آن را هم تحلیل مینماید.
حالا دو سناریوی رایج را در نظر بگیرید:
سناریوی اول) تناقض کانونیکال: شما در HTML خام میگویید canonical برابر X است، ولی جاوا اسکریپت بعد از اجرا canonical را Y میکند. گوگل با دو سیگنال روبهرو میشود، یکی قبل از رندر و یکی بعد از رندر. طبق توضیح گوگل، چون canonicalization هم قبل و هم بعد از رندر اتفاق میافتد، این تضاد میتواند نتیجه را غیرقابل پیشبینی کند یا باعث شود گوگل نسخهای غیر از ترجیح شما را انتخاب نماید.
سناریوی دوم) کد وضعیت اشتباه: صفحهای که واقعاً وجود دارد به هر دلیل با کد غیر ۲۰۰ پاسخ داده میشود، مثلاً ۴۰۴ یا ۵۰۰. در این حالت، گوگل ممکن است اصلاً وارد رندر نشود. یعنی حتی اگر شما قرار بوده canonical را با JS درست کنید یا محتوا را با React/Vue بسازید، گوگل ممکن است هیچوقت آن نسخه را نبیند. مستندات رسمی دقیقاً همین را میگوید: برای وضعیتهای غیر ۲۰۰ «ممکن است رندر رد شود».
نتیجه عملی این دو مورد، یک دردسر مشترک است: شما یک صفحه را در مرورگر «درست» میبینید، اما گوگل یا محتوای درست را نمیبیند، یا canonical درست را نمیفهمد، یا هر دو.
خیلیها کانونیکال را یک تگ ساده میبینند: یک خط در head و تمام. اما در دنیای جاوا اسکریپت، کانونیکال به یک سیگنال چندمرحلهای تبدیل میشود. گوگل صراحتاً تأکید میکند؛ چون canonicalization قبل و بعد از رندر انجام میشود، باید canonical را تا حد ممکن شفاف و یکدست نگه دارید. برای صفحات JS این یعنی:
اگر canonical را در HTML خام گذاشتهاید، بعد از اجرای JS همان مقدار باید در DOM نهایی هم دیده شود.
اگر نمیتوانید canonical درست را در HTML خام بگذارید، بهتر است canonical را کلاً از HTML خام حذف کنید و فقط با JS مقداردهی کنید تا تضاد ایجاد نشود.
این توصیه از نظر اجرایی خیلی مهم است؛ چون به شما میگوید «داشتن دو canonical» (یکی در HTML و یکی بعد از رندر) اگر همخوان نباشند، بدتر از «نداشتن canonical در HTML خام» است.
تقریباً در اکثر سناریوهای معمول، مخصوصاً وقتی URL نهایی از قبل معلوم است: صفحات دستهبندی، مقاله، محصول، صفحه خدمات و هر چیزی که URL ثابت دارد.
مزیت اینکار واضح است: گوگل همان ابتدا سیگنال را میبیند، حتی قبل از رندر. پس اگر به هر دلیل رندر با تأخیر انجام شود یا محدودیتهایی رخ دهد، شما سیگنال اصلی را از دست ندادهاید.
این حالت معمولاً وقتی رخ میدهد که URL نهایی واقعاً در لحظه پاسخ اولیه مشخص نیست یا به دادههای سمت کلاینت وابسته است. با اینحال، در بسیاری از پروژهها این «مجبور بودن» از یک تصمیم معماری میآید، نه از ضرورت واقعی. اگر شما بتوانید با SSR یا prerender یا حتی تولید head سمت سرور canonical را قطعی کنید، تقریباً همیشه انتخاب مطمئنتری است.
گوگل در آپدیت جدید یک جمله کلیدی را اضافه کرده که خیلی از سوءبرداشتها را جمع میکند: همه صفحات با کد وضعیت ۲۰۰ به صف رندر میروند، ولی اگر کد وضعیت غیر ۲۰۰ باشد «ممکن است رندر انجام نشود».
این یعنی چه؟ یعنی گوگل قبل از اینکه اصلاً وقت و منابع رندر را خرج کند، به یک سیگنال پایه نگاه میکند: وضعیت پاسخ سرور. این نگاه کاملاً منطقی است. صفحهای که از دید پروتکل HTTP «خطا» محسوب میشود، معمولاً ارزش رندر کردن ندارد. اما مشکل از جایی شروع میشود که بسیاری از سایتهای مدرن، خطا را اشتباه گزارش میکنند یا یک صفحه واقعی را با کد وضعیت نامناسب برمیگردانند.
در پروژههای واقعی، چند اتفاق زیاد دیده میشود:
روتینگ SPA درست کار میکند، اما سرور برای مسیرهای داخلی (deep link) تنظیم نشده و به جای ۲۰۰، ۴۰۴ یا ۳۰۲ یا حتی ۵۰۰ میدهد.
CDN یا پروکسی یا WAF بر اساس هدرها یا کشور یا user-agent بعضی درخواستها را با کد غیر ۲۰۰ پاسخ میدهد.
پیادهسازی SSR یا middleware دچار مشکل میباشد و برای برخی URLها خطا برمیگرداند، در حالی که در مرورگر برای کاربر قابل نمایش است.
در تمام این حالتها، ریسک اصلی این میباشد: گوگل ممکن است JS را اجرا نکند، پس محتوای واقعی و canonical نهایی هم دیده نمیشود.
یک نکته ظریف هم وجود دارد: بعضی سایتها برای همه چیز ۲۰۰ برمیگردانند، حتی برای صفحات وجودنداشته. اینکار گاهی باعث Soft 404 و مشکلات ایندکس میشود. یعنی شما از نظر فنی ۲۰۰ دادهاید، اما گوگل محتوا را شبیه صفحه خطا تشخیص میدهد. این مسئله جدا از آپدیت جدید است، ولی در عمل روی سایتهای SPA زیاد دیده میشود و باید با طراحی درست صفحه ۴۰۴ واقعی، پیامهای خطای درست و کنترل محتوای صفحات وجودنداشته مدیریت شود.
پس نسخه حرفهای موضوع این است:
هم کد وضعیت باید درست باشد، هم معنی آن. صفحه واقعی ۲۰۰، صفحه ناموجود ۴۰۴. این به گوگل کمک میکند منابع رندر را روی URLهای درست خرج نماید و انتخاب canonical هم قابل اعتمادتر میشود.
بیایید وارد بخش اجرایی شویم. اینجا هدف این است که به یک سیستم برسید که:
گوگل در HTML خام یک canonical شفاف ببیند، یا اگر ممکن نیست اصلاً canonical نبیند تا تضاد شکل نگیرد.
در نسخه رندرشده هم همان canonical نهایی وجود داشته باشد.
همه URLهای قابل ایندکس با ۲۰۰ پاسخ داده شوند.
این روش معمولاً سادهترین و کمریسکترین انتخاب است. canonical را از همان ابتدا در پاسخ سرور و داخل HTML خام قرار میدهید و کاری میکنید که بعد از اجرای جاوا اسکریپت هیچ تغییری در آن ایجاد نشود. اگر احساس میکنید باید canonical را با JS تغییر دهید، اول علت را دقیق بررسی کنید. در بسیاری از پروژهها، این نیاز از مشکلاتی مثل پارامترها و UTMها یا وجود چند مسیر متفاوت برای یک محتوا ناشی میشود؛ مسائلی که بهتر است با ریدایرکتهای درست، کنترل پارامترها و یکسانسازی لینکهای داخلی (همه به سمت URL استاندارد) حل شوند؛ نه با دستکاری canonical در جاوا اسکریپت.
این دقیقاً همان سناریویی است که گوگل برای «وقتی نمیشود canonical را در HTML خام گذاشت» پیشنهاد میدهد: canonical را از HTML خام حذف کنید و فقط با JS تنظیم کنید.
اینکار از نظر سیگنالدهی ریسک دارد؛ چون اگر رندر انجام نشود، canonical هم دیده نمیشود. بنابراین فقط وقتی منطقی است که واقعاً راه دیگری ندارید و از طرف دیگر مطمئن هستید صفحه با ۲۰۰ پاسخ میدهد و معمولاً وارد رندر میشود.
گوگل بارها در مستندات مختلف تأکید کرده که برای فهم canonical انتخابشده و مشکلات canonicalization باید از ابزار URL Inspection استفاده کنید. این ابزار به شما نشان میدهد گوگل چه URLی را بهعنوان canonical انتخاب کرده و چه نسخهای را دیده است.
در عمل، URL Inspection برای JavaScript SEO یک کاربرد طلایی دارد: مقایسه «HTML خام» و «نسخه رندرشده». اگر شما احساس میکنید گوگل محتوا را نمیبیند، یا canonical اشتباه انتخاب میکند، بهترین مسیر این است که ببینید در هر دو مرحله چه سیگنالهایی وجود دارد.
اگر در URL Inspection دیدید نسخه رندرشده با چیزی که انتظار دارید متفاوت است، معمولاً یکی از این عوامل مقصر میباشد:
منابع JS/CSS بلاک شدهاند یا با خطا لود میشوند.
درخواستهای API در رندر گوگل جواب متفاوت میدهند.
کد وضعیت پاسخ برای گوگل متفاوت از کاربران میباشد.
canonical قبل و بعد از رندر متفاوت است.
همه اینها با همین آپدیتهای ۲۰۲۵ همراستا هستند؛ چون گوگل دقیقاً روی همین نقاط، شفافسازی کرده است.
اگر بخواهیم کل موضوع را به زبان اجرایی خلاصه کنیم، مسیر درست این است:
اول کدهای پاسخ را درست کنید: صفحات قابل ایندکس باید ۲۰۰ واقعی باشند و صفحات خطا ۴۰۴ یا ۵xx واقعی؛ چون پاسخ غیر ۲۰۰ ممکن است رندر را متوقف کند.
بعد سراغ کانونیکال بروید: یا canonical را در HTML خام تعیین کنید و اجازه ندهید JS تغییرش دهد، یا اگر مجبورید canonical را با JS تعیین کنید، canonical را از HTML خام حذف نمایید تا تضاد شکل نگیرد.
در نهایت با URL Inspection تأیید کنید: به جای حدس زدن، ببینید گوگل چه چیزی را دیده و چه کانونیکالی را انتخاب کرده است.
اگر URL نهایی صفحه ثابت است و میتوانید آن را سمت سرور یا داخل HTML خام تولید کنید؛ canonical را در HTML خام قرار دهید و اجازه ندهید جاوا اسکریپت آن را تغییر دهد. ریسک این حالت پایین میباشد. برای اطمینان، خروجی را با URL Inspection بررسی کنید.
اگر URL نهایی واقعاً فقط بعد از اجرای جاوا اسکریپت مشخص میشود؛ canonical را از HTML خام حذف کنید و فقط با JS مقداردهی نمایید تا تضاد سیگنالها شکل نگیرد. ریسک این حالت متوسط تا زیاد است؛ چون اگر رندر انجام نشود canonical هم دیده نمیگردد. پس باید مطمئن باشید صفحه همیشه با HTTP 200 پاسخ میگیرد و وضعیت رندر را مرتب تست کنید.
اگر برخی URLهای مهم سایت با کد وضعیت غیر ۲۰۰ پاسخ داده میشوند؛ فعلاً وقت را روی canonical نگذارید، چون ممکن است اصلاً مرحله رندر رخ ندهد. اول باید مشکل status code، روتینگ، SSR ،CDN یا پراکسی را حل کنید. ریسک این حالت بسیار بالاست و میتواند باعث دیدهنشدن محتوا و سیگنالهای جاوا اسکریپتی شود.
اگر سایت SPA دارید و در گوگل رندر ناقص یا محتوای خالی میبینید؛ تا حد ممکن canonical را در HTML خام تثبیت کنید و اگر امکانش هست از SSR یا prerender کمک بگیرید. در کنار آن، لود شدن منابع JS/CSS، پاسخ APIها در حالت Googlebot و نتایج URL Inspection را بررسی نمایید تا نقطه شکست مشخص شود.
آپدیت دسامبر ۲۰۲۵ گوگل یک پیام مدیریتی برای سئوکارها و دولوپرها دارد: در پروژههای جاوا اسکریپتی، «مرحلهای فکر کردن» دیگر کافی نیست. نمیتوانید فقط روی canonical تمرکز کنید و وضعیت پاسخ سرور را نادیده بگیرید یا فقط روی رندر تمرکز نمایید و اجازه دهید canonical در دو مرحله با هم بجنگد. گوگل به صورت صریح بیان کرده که canonicalization قبل و بعد از رندر انجام میشود و رندر هم برای صفحات غیر ۲۰۰ ممکن است اصلاً رخ ندهد.
پس اگر هدف شما ایندکس پایدار، انتخاب canonical درست و دیده شدن محتوای واقعی صفحات React/Vue/SPA است، باید این دو شرط را مثل دو پایه یک پل ببینید: پایه اول HTTP 200 درست و پایدار، پایه دوم یکدستی سیگنال canonical بین HTML خام و نسخه رندرشده.
تهیه شده توسط تیم تخصصی سئو سید احسان خسروی (مدیر، متخصص و مشاور استراتژیک سئو)
