چرا رندر سمت سرور و سئو با جاوااسکریپت بههم نمیرسند؟ علتهای پنهان
فریمورکهای مدرن مثل ریاکت و ویو صفحه را در مرورگر کاربر میسازند؛ اگر سرور فقط یک پوستهٔ خالی بفرستد، چیزی که گوگل در موج اول خزش میبیند تقریباً هیچ است. برای همین رندر سمت سرور — ساختهشدن محتوای اصلی روی سرور و ارسال HTML پُر — برای صفحات درآمدساز معمولاً نقطهٔ شروع درست است. اما تجربهٔ ممیزیهای ما چیز دیگری هم نشان میدهد: سایتهایی که دقیقاً رندر سروری دارند و باز هم در گزارش صفحههای سرچکنسول معطل میمانند.
علت بهندرت در خود SSR است؛ در چهار اشتباهی است که بعد از استقرار اتفاق میافتد و کمتر کسی دنبالش میگردد، چون ابزارهای رایج فقط میبینند سایت بالا است یا نه، نه اینکه گوگل چه چیزی میبیند. در ادامه هر علت را با نشانهٔ زندهٔ آن میبینید، بعد روش تشخیص دوقدمی را تمرین میکنید و در پایان ترتیب اصلاح را روی یک برنامهٔ دوهفتهای میچینید. مبانی چهارستونی را اگر لازم دارید، در سئو فنی چیست؛ چهار ستونی که جستوجو روی آن میایستد جداگانه باز کردهایم.
رندر سمت سرور و سئو؛ دو مرحلهٔ جدای گوگل
گوگل خزنده را با رندرکننده یکی نمیداند. طبق توضیح مستندات Google Search Central، خزش و رندر دو مرحلهٔ جداست: خزنده ابتدا HTML خام را میگیرد و صفحه برای اجرای جاوااسکریپت به صف رندر میرود و نسخهٔ رندرشده بعداً ایندکس میشود (تاریخ گردآوری: آبان ۱۴۰۵). یعنی میان «خزیده شدن» و «دیده شدن» یک فاصلهٔ واقعی هست و هر چیزی که فقط در جاوااسکریپت باشد، وارد همین فاصله میشود.
رندر سمت سرور این فاصله را کوچک میکند، چون محتوای اصلی را در HTML اولیه میفرستد و خزش موج اول از همان محتوا میگذرد. اما این فقط شرط ورود است، نه شرط نتیجه: صفحات رندرسروری هم وقتی به نتیجه نمیرسند که یکی از چهار علت بخشهای بعد روی صفحه فعال باشد. پس بهجای این پرسش که «SSR داریم یا نه»، پرسش درست این است: نسخهای که گوگل رندر و ایندکس میکند، چقدر به نسخهٔ کاربر شبیه است؟
علت اول؛ محتوای مهم فقط پس از تعامل ظاهر میشود

رایجترین حالت این است: توضیحات کامل محصول در تبِ کلیکخور است، نظرات با اسکرول بینهایت میآیند و نیمهٔ دوم مقاله پشت دکمهٔ «ادامهٔ مطلب» مانده. گوگل صفحه را رندر میکند، اما دکمه کلیک نمیکند و اسکرول بیپایان نمیکشد؛ نتیجه در نسخهٔ رندرشده هم همان پوسته است. رندر سروری هم این را نجات نمیدهد، چون محتوای پشت تعامل در HTML اولیه هم نبوده است.
نشانهٔ زندهٔ این علت ساده است: در view-source یک جملهٔ مشخص از محتوای اصلی را جستجو کنید؛ اگر نبود، در نسخهٔ رندرشدهٔ سرچکنسول هم نخواهد بود. راهحل عملی روشن است: محتوای اصلی — نام محصول، قیمت، توضیح کوتاه، متن مقاله — باید بدون هیچ کلیکی در HTML اولیه باشد. تببندی میتواند بماند، اما محتوای تبها از اول در DOM رندر شود و فقط نمایششان با CSS کنترل شود؛ کاربر همان تجربه را دارد و گوگل هم متن را میبیند.
علت دوم؛ آبشار API و اسپینر بیپایان
حالت دوم: صفحه سریع میآید ولی پُر نمیشود. پوستهٔ HTML از سرور میرسد، بعد اسکریپت بالا میآید، بعد درخواست اول به API و بعد درخواست دوم که به جواب اول وابسته است؛ کاربر چند ثانیه اسپینر میبیند. رندرکنندهٔ گوگل هم منبع محدودی دارد؛ اگر محتوا دیر برسد، از صفحهٔ شما عکسی از اسپینر باقی میماند — صفحهای که ظاهراً رندر شده ولی محتوایی برای ایندکس ندارد.
در فروشگاهها و سایتهای فریمورکی این الگو در صفحهٔ محصول رایج است: قیمت، موجودی و نظرات هرکدام یک درخواست جدا میزنند. راهحل: دادهٔ نمایش اولیه را سروری و کششده بفرستید، درخواستهای مستقل را موازی بزنید و زنجیرههای وابسته را در سمت سرور حل کنید. به تجربهٔ ما شکستن آبشارِ صفحهٔ محصول هم سرعت حسشدهٔ کاربر را بالا میبرد هم ایندکسِ قیمت و موجودی را پایدار نگه میدارد.
علت سوم؛ تغییر DOM بعد از ایندکس
علت سوم کمتر کسی را به ذهنش میرسد: صفحه درست ایندکس شده، ولی DOM بعداً عوض میشود. رایجترین شکلش هیدریشن ناهمخوان است — سرور متن درست را میفرستد و اسکریپت مرورگر همان صفحه را با نسخهٔ متفاوتی بازنویسی میکند: عنوانی که جابهجا میشود، توضیحی که کوتاهتر میآید یا قیمتی که با نسخهٔ سرور نمیخواند. شکل دیگرش آزمونهای A/B و ماژولهای بازاریابی است که بعد از بارگذاری، متن اصلی را جایگزین میکنند.
پیامد دووجهی است: نسخهٔ ایندکسشده با نسخهٔ زنده یکی نیست و هر بازبینی، سیگنال ثبات صفحه را هم ضعیف میکند. قانون سادهٔ ما این است: نسخهٔ رندرشده در مرورگر باید با HTML سرور محتوای یکسان داشته باشد؛ هر تفاوتی که برای کاربر لازم نیست، برای گوگل هم ابهام است. آزمون A/B را روی چیدمان و رنگ نگه دارید، نه روی متن و عنوان ایندکسشدنی.
علت چهارم؛ بودجهٔ رندر و صف دومرحلهای

منابع رندر گوگل محدود است؛ صف رندر با حجم کل کار گوگل رقابت میکند و صفحات سنگینتر دیرتر نوبت میگیرند. برای سایتهای کوچک و کماعتبارتر این انتظار طولانیتر است: صفحه خزیده میشود، در گزارش صفحهها مدتی «کشف شد — ایندکس نشده» میماند و صاحب سایت فکر میکند جریمه شده، در حالی که نسخهٔ رندرشدنی هنوز نوبت نگرفته است.
راهحل، سبککردن ورودی رندر است: جاوااسکریپتی که برای محتوای اصلی لازم نیست را از مسیر رندر اول بردارید، کتابخانههای تکراری را حذف کنید و صفحات مهم را با لینک داخلی قویتر به خزنده معرفی کنید. به تجربهٔ ما کمکردن حجم جاوااسکریپتِ صفحات کلیدی، فاصلهٔ خزش تا ایندکس را ملموس کوتاه میکند؛ چون نسخهٔ سروری پُر عملاً نیمی از کار صف رندر را بینیاز میکند.
تشخیص؛ view-source در برابر DOM رندرشده
تشخیص دو ابزار میخواهد و پنج دقیقه وقت. قدم اول: view-source — با Ctrl+U سورس خام را باز کنید و یک جملهٔ مشخص از محتوای اصلی را جستجو کنید؛ نبودِ جمله یعنی محتوای شما فقط سمت مرورگر ساخته میشود. قدم دوم: DOM رندرشده — در سرچکنسول با URL Inspection و گزینهٔ «آزمودن URL زنده» همان جمله را چک کنید؛ کد HTML رندرشده و اسکرینشات صفحه را میبینید و مشخص میشود گوگل بعد از اجرای جاوااسکریپت چه چیزی خواهد دید.
ترکیب نتیجهها مسیر را نشان میدهد: اگر هر دو نسخه پُر هستند و باز هم صفحه ایندکس نمیشود، سراغ علتهای سوم و چهارم بروید — هیدریشن ناهمخوان و بودجهٔ رندر. اگر view-source خالی و DOM پُر است، علت اول و دوم در کار است و اولویت شما انتقال محتوا به HTML اولیه است. این مقایسه را ماهی یکبار برای ده صفحهٔ اصلی سایت تکرار کنید؛ بهروزرسانی فریمورک و افزونهها معمولاً بیسروصدا همین توازن را بههم میزنند.
جمعبندی؛ ترتیب اصلاح در دو هفته
برنامهٔ دوهفتهای: هفتهٔ اول تشخیص — مقایسهٔ view-source و آزمودن URL زنده را روی ده صفحهٔ درآمدساز اجرا کنید و هر صفحه را با یکی از چهار علت برچسب بزنید. هفتهٔ دوم اصلاح — محتوای پشت تعامل را به HTML اولیه بیاورید، آبشار API صفحهٔ محصول را بشکنید و هیدریشن را با نسخهٔ سرور همراستا کنید؛ سبککردن جاوااسکریپت را هم در همین هفته جا بدهید. بعد از اصلاح، درخواست بررسی مجدد در سرچکنسول بزنید و چهار هفته در گزارش صفحهها دنبال کنید.
اگر سایتتان روی ویو ساخته شده، مسیر عملی استقرار در آموزش گامبهگام استقرار SSR برای سایتهای Vue قدمبهقدم آمده و نمای کل خوشه در هاب سئو فنی نگه داشته میشود. اگر میخواهید این رصد روزانه با ابزار و اپراتور انجام شود، قابلیتهای پلتفرم پایش انتشار و محتوا را نشان میدهد و ممیزی رایگان دامنه نقطهٔ شروع بدون هزینه است. چهار علت این مقاله هیچکدام پنهانکاری گوگل نیست؛ فاصلهٔ میان «استقرار رندر سروری» و «دیدن نسخهٔ درست توسط گوگل» است.
رصد ما، رشد شما.
سؤالات پرتکرار
گوگل محتوای جاوااسکریپتی را ایندکس میکند؟
بله، اما دومرحلهای: ابتدا HTML خام خزیده میشود و رندر جاوااسکریپت در صفی جدا انجام میشود. به تجربهٔ ما صفحاتی که محتوای اصلی را در HTML اولیه دارند، از این مسیر مطمئنتر عبور میکنند.
SSR یا CSR؛ کدام برای سئو مناسبتر است؟
برای صفحات درآمدساز — محصول، دسته و مقاله — نسخهٔ سروری با محتوای کامل در HTML اولیه انتخاب مطمئنتری است؛ بخشهای تعاملی میتوانند سمت کاربر بمانند، به شرط اینکه محتوای اصلی به تعامل گره نخورده باشد.
چطور بفهمم گوگل صفحهٔ من را درست رندر میکند؟
در سرچکنسول با URL Inspection گزینهٔ «آزمودن URL زنده» را بزنید و کد رندرشدهٔ HTML و اسکرینشات را با view-source مقایسه کنید؛ تفاوت اصلی، همان محتوایی است که دیر میرسد.
رندر سمت سرور سرعت سایت را پایین نمیآورد؟
زمان اولین پاسخ سرور معمولاً کمی بالا میرود اما با کش سرور جبران میشود؛ آنچه کاربر حس میکند — رسیدن سریع محتوای اصلی بدون اسپینر — معمولاً بهتر میشود.
چرا صفحاتم خزیده میشوند ولی ایندکس نمیشوند؟
وقتی HTML خام پوستهٔ خالی است، خزش بدون محتوا تمام میشود و رندر به صف میرود؛ محتوای اصلی را به HTML اولیه بیاورید و وضعیت را در گزارش صفحههای سرچکنسول دنبال کنید.