رندر سمت سرور و سئو؛ راهنمای کامل جاوااسکریپت و SSR
- چرا گوگل گاهی صفحهٔ جاوااسکریپتی شما را کامل نمی‌بیند؟
- سه مسیر نمایش صفحه؛ SSR، CSR و SSG به زبان بازار
- رندر سمت سرور و سئو؛ جدول تصمیم برای وردپرس و فروشگاه فارسی
- چهار سناریوی واقعی؛ هر کسب‌وکار کدام مسیر؟
- سنجههای سه‌گانهٔ کیفیت صفحه؛ خط قرمزهای گوگل
- سه اشتباه هنگام تعویض مسیر نمایش
- نقشهٔ اجرای امن؛ از آزمون تا انتشار
- جمع‌بندی؛ سه جمله‌ای که با خود ببرید
وقتی مشتری صفحهٔ شما را باز میکند، مرورگر او همهٔ کد جاوااسکریپت را همان لحظه اجرا میکند و صفحه کامل می‌شود؛ اما وقتی خزندهٔ گوگل میآید، ماجرا فرق دارد: طبق مستندات Google Search Central دربارهٔ مبانی جاوااسکریپت، گوگل صفحه را در سه فاز کراول، رندر و ایندکس پردازش میکند و اجرای جاوااسکریپت در فازی جدا از کراول انجام می‌شود (تاریخ گردآوری: آبان ۱۴۰۵). یعنی محتوایی که فقط بعد از اجرای کد ظاهر می‌شود، دیرتر دیده می‌شود و گاهی هرگز به نسخهٔ نهایی گوگل نمی‌رسد.
اینجاست که تصمیمِ معماری مطرح می‌شود. این راهنما جایگزین تشخیص مشکل نیست؛ نشانه‌ها و ریشه‌های خرابی را در «چرا رندر سمت سرور و سئو با جاوااسکریپت به‌هم نمی‌رسند؟ علت‌های پنهان» باز کرده‌ایم و این‌جا سراغ تصمیم می‌رویم: سه مسیر نمایش، جدول انتخاب برای وردپرس و فروشگاه فارسی، سنجههای خط قرمز گوگل و نقشهٔ اجرای امن تعویض مسیر. این ماجرا یکی از چهار ستون سئو فنی است؛ تصویر بزرگ‌تر را در «سئو فنی چیست؛ چهار ستونی که جست‌وجو روی آن می‌ایستد» نوشته‌ایم.
چرا گوگل گاهی صفحهٔ جاوااسکریپتی شما را کامل نمی‌بیند؟
برای یک صفحه دو داستان وجود دارد: داستان مرورگر کاربر و داستان خزنده. مرورگر کاربر کد را فوراً اجرا میکند و صفحه کامل دیده می‌شود؛ خزندهٔ گوگل اول HTML خام را می‌گیرد و اگر محتوای اصلی داخل جاوااسکریپت باشد، صفحه را در صفِ رندر می‌گذارد تا بعداً اجرا شود. همین صفِ اضافه، فاصلهٔ زمانی میان انتشار و دیده‌شدن می‌سازد.
این فاصله در عمل یعنی: محتوای HTML کامل معمولاً همان روزهای اول فهرست می‌شود؛ محتوای جاوااسکریپتی باید صبر کند تا نوبت رندر برسد و اگر خطا یا سنگینی در کار باشد، بخشی از صفحه هرگز در نسخهٔ نهایی نمی‌نشیند. ساده‌ترین آزمون هم «آزمون زندهٔ» سرچکنسول است: HTML دیده‌شدهٔ گوگل را همان‌جا می‌بینید و اگر نسخهٔ خالی باشد، قبل از هر تصمیم بزرگ پیدایش می‌کنید.
یک نکتهٔ کاربردی هم دربارهٔ زمان‌بندی: صفِ رندر گوگل بلافاصله خالی نمی‌شود و صفحه‌ای که کد سنگین‌تری دارد دیرتر نوبت می‌گیرد (تاریخ گردآوری: آبان ۱۴۰۵). پس کدِ سبک و صفحه‌ای که حتی بدون اجرای کد هم هستهٔ محتوایش خواناست، هم کاربر را زودتر راضی میکند و هم خزنده را.
سه مسیر نمایش صفحه؛ SSR، CSR و SSG به زبان بازار
سه مسیر، سه تشبیه بازار: SSR مثل بروشور چاپ‌شده است؛ چاپخانهٔ شهر (سرور) صفحهٔ کامل را از قبل آماده میکند و هر مشتری نسخهٔ آماده می‌گیرد. CSR مثل کاغذ سفید و کارمندی است که جلوی چشم مشتری صفحه را می‌سازد؛ تجربهٔ زنده و تعاملی، ولی منتظرِ دستگاه مشتری. SSG هم بروشورِ چاپ‌شدهٔ از قبل است، مخصوص صفحه‌هایی که کم تغییر می‌کنند.
تفاوت‌ها فقط فنی نیستند؛ هزینه و نگهداری هم فرق میکند. مسیر کلاینت یعنی منطق بیشتر روی دستگاه کاربر و بار کمتر روی میزبان؛ مسیر سرور یعنی HTML آماده، ولی درخواست‌های بیشتر برای میزبان که با کش مدیریت می‌شود. کارت کنار این بخش سه مسیر را در یک نگاه کنار هم گذاشته است.
برای اینکه تصمیم ملموس شود، یک مثال مشترک: صفحهٔ محصول وردپرسی که توضیحاتش در ویرایشگر متن نوشته شده، در هر سه مسیر HTML کامل می‌دهد؛ اما صفحهٔ مقایسه‌گری که نتیجه را با کلیک می‌سازد، بدون کد تقریباً خالی است. پس در یک سایت می‌توان هم‌زمان چند مسیر داشت؛ چیزی که نباید خالی بماند، صفحه‌های عمومی است که جستجوگران به آن‌ها می‌رسند.
رندر سمت سرور و سئو؛ جدول تصمیم برای وردپرس و فروشگاه فارسی
وردپرس — سیستمی که طبق آمار W3Techs حدود ۴۳٪ از همهٔ سایت‌های جهان را پوشش می‌دهد (تاریخ گردآوری: آبان ۱۴۰۵) — بهصورت پیشفرض در مسیر HTML کامل کار میکند؛ یعنی همان خانواده‌ای که هم گوگل را راحت میکند و هم دستگاه‌های ضعیف کاربران را. مشکل معمولاً از جایی شروع می‌شود که قالب یا صفحهساز، همهٔ صفحه را با جاوااسکریپت می‌کشد و نسخهٔ اولیه تقریباً خالی میماند.
به تجربهٔ ما برای فروشگاه‌های وردپرسی فارسی، پیش‌فرضِ HTML کامل با کشِ درست انتخاب امنتری است، چون هم قالبها و افزونههای فروشگاهی برای همین مسیر ساخته شدهاند و هم هزینهٔ نگهداری یک خط لولهٔ نمایش اضافه به پروژه تحمیل نمی‌شود. جدول زیر تصمیم را سناریو‌به‌سناریو ساده میکند:
| سناریو | مسیر پیشنهادی | چرا |
|---|---|---|
| فروشگاه وردپرسی با قالب استاندارد | HTML کامل (پیشفرض) + کش | قالبها برای همین مسیر ساخته شدهاند؛ کار گوگل ساده میماند |
| داشبورد و بخش وروددار کاربران | جاوااسکریپتِ کلاینت اشکالی ندارد | این صفحه‌ها نیازی به ایندکس ندارند |
| صفحه‌های کم‌تغییر مثل راهنما و دربارهٔ ما | کش کامل یا SSG | تغییر کم، سرعت بالا |
| صفحه‌های عمومی با تعامل سنگین مثل مقایسه‌گر | اسکلت HTML + لایهٔ تعاملی | محتوای اصلی در HTML میماند؛ تعامل روی کد |
جدول تصمیم برای سناریوهای رایج فروشگاه‌های فارسی؛ نه نسخهٔ واحد برای همه.
چهار سناریوی واقعی؛ هر کسب‌وکار کدام مسیر؟
سناریوی اول، فروشگاه وردپرسی فارسی: همان ردیف اول جدول؛ پیشفرض و کش، بدون پروژهٔ اضافه. سناریوی دوم، سایت خدماتی با ناحیهٔ کاربری: صفحه‌های عمومی HTML کامل؛ داشبوردِ بعد از ورود چون قرار نیست ایندکس شود، آزاد است با جاوااسکریپت ساخته شود.
سناریوی سوم، رسانه و بلاگ پرانتشار: هر چه انتشار تندتر، اهمیت HTML کامل بیشتر؛ محتوایی که در صف رندر بماند، روز اولِ ترافیک را از دست می‌دهد. سناریوی چهارم، لندینگ کمپین‌ها: صفحه‌های کم‌تغییر و حساس به سرعت؛ کش کامل یا SSG جواب می‌دهد.
اعتراف صادقانه: خود ما هم در یکی از پروژه‌های داخلی دو ماه روی صفحه‌ای کار کردیم که محتوای اصلی‌اش فقط با اجرای کد ساخته می‌شد؛ آمار سرچکنسول نشان می‌داد گوگل نسخهٔ اسکلت را می‌بیند و صفحه‌ای که باید دیده می‌شد، نمی‌دید. همان تجربه برایمان قاعدهٔ ساده‌ای نوشت: اول HTML کامل، بعد تجربهٔ تعاملی.
سنجههای سه‌گانهٔ کیفیت صفحه؛ خط قرمزهای گوگل
انتخاب مسیر را با حس‌وحال انجام ندهید؛ گوگل سه سنجهٔ رسمی دارد: بزرگ‌ترین عنصر دیدنی (LCP) باید تا ۲٫۵ ثانیه ظاهر شود، پاسخ به ورودی کاربر (INP) تا ۲۰۰ میلیثانیه بماند و جابه‌جایی چیدمان (CLS) تا ۰٫۱ — آستانههای Core Web Vitals در مستندات Google Search Central (تاریخ گردآوری: آبان ۱۴۰۵).
مسیر نمایش روی هر سه سنجه اثر می‌گذارد: صفحه‌ای که همه‌چیز را از کد می‌سازد، LCP را دیرتر نشان می‌دهد؛ کدی که وسط بارگذاری عناصر را جابه‌جا میکند، CLS را خراب میکند. مسیر سرور و کش، نقطهٔ شروع بهتری برای این سه سنجه است، هرچند افزونههای سنگین و کشِ بد هر معماری را خراب می‌کنند. قبل و بعدِ هر تغییر را در گزارش Core Web Vitals سرچکنسول ثبت کنید تا تصمیم، داده‌محور بماند.
سه اشتباه هنگام تعویض مسیر نمایش
اشتباه اول، تعویض بدون اندازه‌گیری: مسیر جدید را از روی ترند انتخاب می‌کنید و سه ماه بعد نمی‌دانید بهتر شد یا بدتر؛ قبل از هر تغییر، سه سنجه و وضعیت ایندکس را ثبت کنید. اشتباه دوم، جابه‌جایی آدرس‌ها بدون ریدایرکت ۳۰۱: معماری تازه‌ای که ساختار آدرس را عوض میکند و مسیرهای قدیمی را رها میکند، اعتبار لینک‌های قبلی را می‌سوزاند.
اشتباه سوم، اعمال یک نسخه برای همه: همان صفحه‌ای که برای لندینگ کمپین خوب است، برای صفحهٔ دستهٔ فروشگاه پاسخ نیست؛ این تصمیم صفحه‌به‌صفحه گرفته می‌شود، نه سایت‌به‌سایت. به این فهرست یک آزمون ساده هم اضافه کنید: پیش از امضای هر پروژهٔ تعویض مسیر، از تیم بخواهید در یک برگه بنویسد چه چیزی اندازه‌گیری می‌شود، چه زمانی برگشت انجام می‌شود و چه چیزی علامت شکست است. سه اشتباه را که کنار بگذارید، تعویض مسیر از یک ریسک به یک پروژهٔ قابل‌اندازه‌گیری تبدیل می‌شود.
نقشهٔ اجرای امن؛ از آزمون تا انتشار
اجرای امن مرحله‌ای می‌شود: اول فهرست صفحه‌های عمومی و تصمیم هر گروه؛ بعد نسخهٔ آزمایشی روی آدرس موقت؛ سپس آزمون زندهٔ سرچکنسول برای دیدن HTML دیده‌شده؛ بعد مقایسهٔ سه سنجه قبل و بعد؛ و در پایان هدایت آدرس‌های قدیمی با ریدایرکت ۳۰۱. کارت این بخش همین نقشه را مرحله‌به‌مرحله آورده است.
یک نکتهٔ واقع‌بینانه: تعویض مسیر نمایش یک پروژهٔ زیرساختی است، نه یک کلیک؛ برای فروشگاه‌های کوچک معمولاً اصلاح قالب و کش، سود بیشتری از تعویض کامل می‌دهد. تقسیم کار هم روشن باشد: توسعه‌دهنده مسئول HTML دیده‌شده و سرعت، تیم محتوا مسئول زبان مشتری، و پایش هفتگی سه سنجه در سرچکنسول به یک نفر مشخص سپرده شود؛ بی‌صاحب‌بودنِ پایش، رایج‌ترین دلیل فراموش‌شدن پروژه‌های زیرساختی است. اگر مطمئن نیستید صفحه‌های شما چه نسخه‌ای به گوگل می‌دهند، ممیزی رایگان دامنه نقطهٔ شروع کم‌ریسکی است.
جمع‌بندی؛ سه جمله‌ای که با خود ببرید
سه جمله را با خود ببرید: گوگل جاوااسکریپت را در فازی جدا از کراول اجرا میکند، پس HTML کامل مسیر کوتاه‌تر دیده‌شدن است؛ برای وردپرس و فروشگاه فارسی، پیشفرض با کش انتخاب امنتری است و مسیر تعاملی را به بخشهای بدون نیاز به ایندکس بسپارید؛ و هر تغییر را با سه سنجهٔ رسمی قبل و بعد بسنجید.
اثر دیده‌شدن درست را اعداد هم می‌گویند: در مطالعهٔ نرخ کلیک ارگانیک Backlinko، جایگاه اول حدود ۲۷٪ کلیک‌ها را می‌برد (تاریخ گردآوری: آبان ۱۴۰۵)؛ سهمی که فقط وقتی معنا دارد صفحه در نسخهٔ نهایی گوگل کامل دیده شود. در یک کیس ثبت‌شدهٔ سوئیت، صفحه‌ای که زنجیرهٔ نمایش و توضیحات متایش درست شد، در بازهٔ ۹۰روزه تا آبان ۱۴۰۵ از ۱۱٬۰۰۰ نمایش ۸۵۸ کلیک گرفت؛ CTR ۷٫۸٪ در برابر حدود ۳٪ میانگین بازار. جزئیات این کیس و بقیهٔ شواهد در صفحهٔ مطالعات موردی آمده است.
رصد ما، رشد شما.
سؤالات پرتکرار
SSR دقیقاً چه تفاوتی با CSR دارد؟
در SSR فایل HTML کامل از میزبان میآید؛ در CSR مرورگر باید کد جاوااسکریپت را اجرا کند تا صفحه ساخته شود. همین تفاوت، سرعت دیدن محتوا و کار خزنده را عوض میکند.
وردپرس بهصورت پیشفرض کدام مسیر است؟
مسیر HTML کامل؛ فقط اگر قالب یا صفحهساز همهٔ صفحه را با جاوااسکریپت بکشد، نسخهٔ اولیه خالی میماند و صفحه عملاً به مسیر کلاینت میرود.
گوگل جاوااسکریپت را اجرا میکند یا نه؟
بله؛ طبق مستندات Google Search Central، اجرای جاوااسکریپت در فازی جداگانه پس از کراول انجام می‌شود و همین فاز اضافه، دیده‌شدن محتوا را کندتر میکند (تاریخ گردآوری: آبان ۱۴۰۵).
برای فروشگاه وردپرسی فارسی چه توصیهای دارید؟
به تجربهٔ ما پیشفرض HTML کامل با کش درست انتخاب امنتری است، چون قالبها و افزونههای فروشگاهی برای همین مسیر ساخته شدهاند؛ مسیر تعاملی را به بخشهای وروددار بسپارید که ایندکس نمیخواهند.
سنجههای رسمی گوگل برای کیفیت صفحه کداماند؟
LCP تا ۲٫۵ ثانیه، INP تا ۲۰۰ میلیثانیه و CLS تا ۰٫۱؛ آستانههای Core Web Vitals در مستندات Google Search Central (تاریخ گردآوری: آبان ۱۴۰۵). قبل و بعدِ هر تغییر را در سرچکنسول ثبت کنید.
