لوگوی اپ نگار اپ نگارمهندسی نرم‌افزار و هوش مصنوعی
نمودار مقایسه رندر سمت سرور، تولید ایستا و رندر سمت کاربر برای سئوی سایت React

سئو تکنیکال

راهنمای کامل سئو سایت‌های React و تک‌صفحه‌ای

مرداد ۱۴۰۵ · تیم فنی اپ نگار

مشکل رندر سمت کاربر، انتخاب بین SSR و SSG و پیش‌رندر، و چک‌لیست عملی بررسی سئوی فنی سایت‌های تک‌صفحه‌ای.

سایت‌هایی که با React، Vue یا سایر کتابخانه‌های سمت کاربر ساخته می‌شوند، اگر بدون در نظر گرفتن الزامات موتور جست‌وجو پیاده‌سازی شوند، ممکن است بخش بزرگی از محتوایشان هرگز به‌درستی ایندکس نشود. این راهنما مسئله و راه‌حل‌های عملی را توضیح می‌دهد.

ریشه مشکل: رندر سمت کاربر

در یک سایت سنتی، سرور HTML کامل را تحویل می‌دهد. در یک اپلیکیشن تک‌صفحه‌ای، سرور یک HTML تقریباً خالی می‌فرستد و محتوا پس از اجرای جاوااسکریپت در مرورگر ساخته می‌شود.

گوگل جاوااسکریپت را اجرا می‌کند، اما این کار در صفی جداگانه و با تأخیر انجام می‌شود. سایر موتورهای جست‌وجو و ربات‌های شبکه‌های اجتماعی معمولاً اصلاً جاوااسکریپت اجرا نمی‌کنند. نتیجه این است که پیش‌نمایش لینک شما در پیام‌رسان‌ها خالی می‌ماند و ایندکس شدن صفحات کند می‌شود.

سه راه‌حل و شرایط انتخاب هرکدام

  • رندر سمت سرور (SSR): HTML کامل در هر درخواست ساخته می‌شود. بهترین گزینه برای محتوای پویا و شخصی‌سازی‌شده، اما پیچیدگی زیرساخت را بالا می‌برد.
  • تولید ایستا (SSG): صفحات از پیش ساخته و به‌صورت فایل ذخیره می‌شوند. سریع‌ترین و ارزان‌ترین گزینه برای محتوایی که مدام تغییر نمی‌کند، مانند مقالات و صفحات خدمات.
  • پیش‌رندر (Pre-rendering): فقط برای ربات‌ها نسخه HTML آماده سرو می‌شود. راه‌حل میانی و مناسب پروژه‌هایی که بازنویسی کامل ندارند، به شرط اینکه محتوای نسخه ربات با نسخه کاربر یکسان باشد.

نکته مهم: اگر به ربات محتوایی متفاوت از کاربر نشان دهید، این کار مصداق پنهان‌سازی است و می‌تواند جریمه در پی داشته باشد.

متاتگ‌ها باید سمت سرور تولید شوند

اگر عنوان صفحه، توضیحات متا و تگ‌های Open Graph با جاوااسکریپت تزریق شوند، ربات‌های شبکه‌های اجتماعی آن‌ها را نمی‌بینند. این تگ‌ها باید در همان HTML اولیه‌ای باشند که سرور برمی‌گرداند.

همین موضوع درباره داده ساختاریافته JSON-LD هم صدق می‌کند.

لینک‌ها باید قابل خزش باشند

خزنده فقط تگ `<a href>` را دنبال می‌کند. اگر ناوبری شما با رویداد کلیک روی `<div>` پیاده‌سازی شده باشد، خزنده هیچ مسیری برای رسیدن به صفحات داخلی پیدا نمی‌کند.

هر صفحه باید آدرس یکتای خودش را داشته باشد و با باز کردن مستقیم آن آدرس، همان محتوا نمایش داده شود. استفاده از History API برای این کار درست است؛ استفاده از قطعه هش برای مسیریابی، توصیه نمی‌شود.

کدهای وضعیت واقعی

یک صفحه ناموجود باید کد ۴۰۴ برگرداند، نه ۲۰۰ به‌همراه پیام «یافت نشد» در متن. صفحه‌ای که کد ۲۰۰ می‌دهد ولی محتوای خطا دارد، به‌عنوان «صفحه نرم ۴۰۴» شناسایی می‌شود و اعتبار سایت را کاهش می‌دهد.

انتقال‌ها هم باید با کد ۳۰۱ یا ۳۰۸ انجام شوند، نه با تغییر مسیر جاوااسکریپتی.

Core Web Vitals در سایت‌های جاوااسکریپتی

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

  • LCP حداکثر ۲.۵ ثانیه: بزرگ‌ترین عنصر محتوایی چه زمانی نمایش داده می‌شود
  • INP حداکثر ۲۰۰ میلی‌ثانیه: پاسخ‌گویی صفحه به تعامل کاربر
  • CLS حداکثر ۰.۱: میزان جابه‌جایی ناخواسته چیدمان

بزرگ‌ترین دشمن این شاخص‌ها در سایت‌های تک‌صفحه‌ای، حجم باندل جاوااسکریپت است. تقسیم کد بر اساس مسیر، بارگذاری تنبل بخش‌های سنگین و حذف کتابخانه‌های بلااستفاده، بیشترین اثر را دارند.

برای CLS، تعیین صریح `width` و `height` تصاویر و رزرو فضای عناصری که با تأخیر می‌آیند، ضروری است.

چک‌لیست عملی بررسی

  1. با ابزار بررسی URL در سرچ کنسول، HTML رندرشده را ببینید و مطمئن شوید متن اصلی در آن وجود دارد
  2. جاوااسکریپت مرورگر را غیرفعال کنید و صفحه را باز کنید؛ محتوای اصلی باید همچنان قابل خواندن باشد
  3. مطمئن شوید فایل‌های جاوااسکریپت و CSS در robots.txt مسدود نشده‌اند
  4. تگ canonical هر صفحه را بررسی کنید
  5. نقشه سایت را تفکیک کنید و فقط آدرس‌های ۲۰۰ را در آن بگذارید
  6. داده ساختاریافته را با ابزار تست نتایج غنی بررسی کنید
  7. شاخص‌های Core Web Vitals را در داده میدانی، نه فقط آزمایشگاهی، اندازه بگیرید

توضیحات رسمی گوگل درباره این موضوع در راهنمای سئوی جاوااسکریپت در دسترس است.

اگر سایت فعلی شما با React ساخته شده و در ایندکس شدن مشکل دارد، درخواست بررسی فنی ثبت کنید. نمونه‌کارهای ما هم نشان می‌دهد این الزامات در پروژه‌های واقعی چطور پیاده شده‌اند.