سئوی JavaScript؛ رندر، خزش و ایندکس React و Vue

صفحه محصول در مرورگر مدیر فروشگاه بی‌نقص است؛ اما پاسخ اولیه سرور فقط یک <div id="app"> دارد، قیمت بعد از یک API خارجی می‌آید، لینک دسته با onClick ساخته شده و محصول حذف‌شده هنوز 200 برمی‌گرداند. مشکل این صفحه «React» یا «Vue» نیست؛ مشکل این است که قرارداد قابل‌مشاهده برای Crawler، کاربر و سیستم اندازه‌گیری یکسان و قابل‌اثبات نیست.

سئوی JavaScript با نصب یک Plugin یا انتخاب همیشگی SSR حل نمی‌شود. باید برای هر Route مشخص کنید URL چگونه کشف می‌شود، در پاسخ HTTP چه چیزی وجود دارد، پس از اجرا چه تغییری می‌کند، خطا چه Statusی دارد و آیا Title، Canonical، Robots، Schema و محتوای اصلی با واقعیت صفحه هم‌خوان‌اند. این راهنما یک روش اجرایی برای React، Vue، SPA، سایت‌سازهای JavaScript و معماری‌های Hybrid ارائه می‌کند.

سئوی JavaScript دقیقاً چه مسئله‌ای را حل می‌کند؟

JavaScript SEO یعنی کاهش فاصله میان چیزی که سرور تحویل می‌دهد، چیزی که مرورگر پس از اجرا می‌سازد و چیزی که موتور جستجو نهایتاً پردازش می‌کند. برای هر URL چهار سطح را جدا ببینید:

گوگل فرایند را در سه فاز Crawl، Render و Index توضیح می‌دهد. URL ممکن است برای رندر در صف بماند؛ این زمان لزوماً «دو موج» یا «چند هفته» نیست و نباید عدد ثابت برای آن ساخت. صفحه‌ای که در HTML اولیه محتوای مفید دارد، وابستگی کمتری به موفقیت مرحله Render دارد.

React و Vue ذاتاً برای سئو بد نیستند

Framework نام محصول است، نه نتیجه سئو. یک پروژه React می‌تواند Static HTML عالی تحویل دهد و یک سایت سنتی می‌تواند Canonical و Status اشتباه داشته باشد. برعکس، SSR هم اگر برای تمام Routeها یک Shell یکسان، Metadata تکراری یا Hydration سنگین بفرستد، راه‌حل نیست.

برای ارزیابی، سؤال «با چه Frameworkی ساخته شده؟» را به این پرسش‌ها تبدیل کنید:

• آیا محتوای تصمیم‌ساز صفحه در پاسخ اولیه وجود دارد؟
• آیا هر Entity و Intent قابل‌ایندکس URL مستقل و Canonical درست دارد؟
• آیا خطا، انتقال و حذف در لایه HTTP هم معنا دارند؟
• آیا Hydration یا Bundle اصلی تعامل کاربر را مسدود می‌کند؟
• آیا تیم می‌تواند خروجی را در Build، Release و Production آزمایش کند؟

قرارداد هر Route را پیش از انتخاب Rendering بنویسید

یک Route Contract مانع تصمیم‌های سلیقه‌ای «همه SSR» یا «همه SPA» می‌شود. برای هر Page type—خانه، دسته، محصول، مقاله، جست‌وجوی داخلی، حساب کاربری—این فیلدها را ثبت کنید:

Route: /products/:slug
Audience: public | authenticated
Search intent/entity: product detail
Index policy: index | noindex | conditional
Freshness: price/stock minutes; description hours
Required initial HTML: title, name, price state, description, links
HTTP states: 200 | 301 | 404 | 410 | 503
Canonical rule: absolute self-canonical unless approved variant
Render mode: static | revalidated | SSR | CSR | hybrid
Dependencies: CMS, inventory, pricing, media, consent
Fallback: last-known-safe | unavailable state | retry
Owner/SLO: team + render/freshness/error target

صفحه حساب کاربر معمولاً نیازی به ایندکس ندارد و CSR می‌تواند انتخاب خوبی باشد. صفحه مقاله پایدار می‌تواند Static باشد. محصولی با موجودی سریع‌التغییر شاید HTML قابل‌کش به‌همراه Revalidation یا SSR کنترل‌شده بخواهد. تصمیم باید از Intent، تازگی، شخصی‌سازی، هزینه و Failure mode بیاید.

مدل‌های رندر: مزیت، هزینه و نقطه شکست

گوگل Dynamic Rendering را workaround می‌داند، نه راه‌حل پیشنهادی بلندمدت؛ SSR، Static rendering یا Hydration ترجیح دارند. اگر Legacy شما ناچار به استفاده موقت است، خروجی Bot و User باید هم‌معنا باشد، اختلاف‌ها پایش شوند و تاریخ خروج از این معماری ثبت شود. محتوای متفاوت برای کسب رتبه می‌تواند Cloaking تلقی شود.

HTML اولیه را به Minimum Viable Document تبدیل کنید

هدف این نیست که همه تعامل‌ها بدون JavaScript کار کنند؛ هدف این است که هویت و محتوای اصلی صفحه به یک Fetch شکننده وابسته نباشد. برای URL عمومی، پاسخ اولیه بهتر است دست‌کم شامل این موارد باشد:

• title و Meta description یکتا؛
• Canonical و Robots قطعی؛
• H1، محتوای اصلی و لینک‌های ضروری؛
• داده ساختاریافته معتبر و هم‌خوان با محتوای قابل‌مشاهده؛
• Status واقعی و Headerهای Cache/Redirect لازم؛
• State واضح برای unavailable، empty و error.

این سند حداقل را با curl یا View Source ببینید؛ Elements در DevTools فقط DOM پس از اجرا را نشان می‌دهد. هر دو لازم‌اند، اما یک مسئله را اندازه نمی‌گیرند.

کشف URL: Link واقعی، History API و Sitemap

Googlebot URLها را از <a href="..."> استخراج می‌کند. دکمه، div و Listener کلیک جایگزین Link نیستند. Router React/Vue می‌تواند Navigation را Client-side انجام دهد، اما خروجی نهایی Component باید Anchor با href معتبر باشد.

<a href="/products/کفش-پیاده-روی">کفش پیاده‌روی</a>

// ضعیف برای کشف و دسترس‌پذیری
<div onclick="go('/products/123')">محصول</div>

برای SPA از History API و Path واقعی استفاده کنید، نه Hash routeهایی مانند #/product. هر View قابل‌اشتراک باید با Refresh مستقیم هم پاسخ درست بگیرد. Sitemap URLهای Canonical و Indexable را پشتیبانی می‌کند، اما جای لینک داخلی را نمی‌گیرد. برای معماری PWA و جزئیات Service Worker، راهنمای سئوی فنی PWA را ببینید.

HTTP Status باید قبل از اجرای JavaScript درست باشد

اگر همه Routeها از CDN یک 200 app shell بگیرند و نبود محصول فقط با پیام Client مشخص شود، Soft ۴۰۴ می‌سازید. Redirectهای جاوااسکریپتی نیز جای ۳۰۱/۳۰۸ سمت سرور را نمی‌گیرند. قرارداد پیشنهادی:

اگر محدودیت معماری CSR اجازه Status درست نمی‌دهد، راهکارهای fallback گوگل برای Soft ۴۰۴ وجود دارد؛ اما اصلاح Routing در Edge/Server پایدارتر است. معنا و کاربرد Statusها در راهنمای کدهای HTTP تفکیک شده است.

Title، Canonical و Robots را به Race Condition نسپارید

تغییر Metadata با JavaScript ممکن است پردازش شود، اما برای صفحات عمومی بهتر است مقدار قطعی در HTML اولیه باشد. چند خطر مهم:

• Template اولیه برای همه صفحات Title یکسان تولید کند؛
• Canonical اولیه به خانه و Canonical پس از Hydration به خود صفحه اشاره کند؛
• دو Canonical ساخته شود؛
• صفحه با noindex اولیه بیاید و کد تلاش کند آن را حذف کند؛ گوگل ممکن است اصلاً Render را ادامه ندهد؛
• Query/filterهای بی‌نهایت بدون سیاست Canonical/Index تولید شوند.

برای هر Route یک Metadata function واحد داشته باشید که Server و Client از همان Data contract استفاده کنند. سپس Source، Rendered DOM و HTML عمومی را با Fixture ثابت مقایسه کنید.

Robots.txt و Resource Fetch را جدا از Index policy مدیریت کنید

مسدودکردن فایل JavaScript یا API ضروری در robots.txt می‌تواند مانع ساخت DOM کامل شود. در مقابل، Robots.txt ابزار مطمئن حذف URL از Index نیست. این سه مفهوم را قاطی نکنید:

• Crawl allow/disallow: آیا Bot می‌تواند URL یا Resource را Fetch کند؟
• Index/noindex: آیا صفحه واجد حضور در Index است؟
• Access control: آیا داده واقعاً خصوصی است و به Authentication نیاز دارد؟

برای هر Resource حیاتی، دسترسی ناشناس، Status، MIME type، CORS لازم، timeout و پاسخ در شبکه‌های متفاوت را تست کنید. Token موقت کاربر یا Cookie مدیر نباید شرط نمایش محتوای عمومی باشد.

محتوای Lazy و Infinite Scroll باید URL و مسیر جایگزین داشته باشد

محتوایی که فقط پس از Click، Swipe یا Scroll بسیار طولانی می‌آید ممکن است کشف نشود. Lazy loading تصاویر نزدیک Viewport مفید است، اما محتوای اصلی را پشت تعامل اجباری پنهان نکنید. Infinite scroll باید مجموعه‌ای از Pageهای قابل‌دسترسی و لینک‌پذیر داشته باشد:

/articles?page=1  → self canonical
/articles?page=2  → self canonical + unique items
UI infinite scroll → progressive enhancement over page URLs

فیلترها را نیز براساس تقاضای جستجو و ارزش صفحه طبقه‌بندی کنید: Indexable landing، Crawlable-but-noindex برای نیاز محصول، یا non-crawlable UI state. تولید میلیون‌ها ترکیب رنگ/مرتب‌سازی بدون محتوای یکتا، مسئله Render را به Inventory بی‌کیفیت تبدیل می‌کند.

Schema باید با Product truth و DOM هم‌خوان باشد

گوگل JSON-LD تولیدشده با JavaScript را می‌تواند پردازش کند، اما برای داده سریع‌التغییر مثل قیمت و موجودی، وابستگی به Render می‌تواند تازگی را کم‌اعتمادتر کند. Server-rendered Schema یا داده‌ای که از همان Source of truth ساخته می‌شود، اختلاف را کاهش می‌دهد.

سه تطابق را در CI بررسی کنید:

1. مقدار قابل‌مشاهده در صفحه؛
2. JSON-LD؛
3. Feed یا API تجاری، اگر وجود دارد.

قیمت ۲٬۴۹۰٬۰۰۰ تومان در UI، مقدار IRR متفاوت در Schema و موجودی قدیمی در Feed خطای JavaScript نیست؛ خطای Governance داده است. برای طراحی Entity graph و کنترل کیفیت، راهنمای Schema و JSON-LD را بخوانید.

Performance: SSR می‌تواند Paint را بهتر و INP را بدتر کند

HTML سریع فقط نیمه اول تجربه است. Hydration سنگین ممکن است صفحه را قابل‌مشاهده اما موقتاً غیرقابل‌تعامل کند. Core Web Vitals فعلی شامل LCP، INP و CLS است؛ FID دیگر Metric اصلی نیست. مرزهای راهنمای عمومی در داده میدانی و صدک ۷۵، جدا برای Mobile و Desktop، عبارت‌اند از LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱.

Lab برای تشخیص و Field/RUM برای تجربه واقعی است. تصمیم را فقط با Lighthouse لپ‌تاپ تیم نگیرید؛ راهنمای Core Web Vitals و RUM روش تفکیک داده را توضیح می‌دهد. برای CPU، Memory، Bundle، XSS و Supply chain نیز بهینه‌سازی اپلیکیشن JavaScript مکمل این صفحه است.

JavaScript Budget را به Route و Device متصل کنید

Budget واحد برای همه صفحه‌ها عملی نیست. برای هر Page type و کلاس دستگاه، سقف تعریف کنید:

Product / mid-range Android / cold cache
Initial JS compressed: ≤ agreed KB
Main-thread long tasks: 0 above release threshold
Hydration completion: measured, not guessed
LCP / INP / CLS: p75 field guardrails
Third-party CPU/network: owner + purpose + expiry
Rollback: previous asset manifest

Tree shaking، route-level code splitting، حذف Polyfill غیرلازم، defer، Web Worker و Partial hydration ابزارند، نه هدف. نتیجه باید با Task completion، Error rate و RUM ثابت شود. حذف JSی که Analytics یا Accessibility را می‌شکند بهینه‌سازی نیست.

Client-side Error را صفحه خالی رها نکنید

Boundary خطا باید میان Data unavailable، Authorization، Not found و Runtime crash فرق بگذارد. یک Spinner بی‌انتها هم برای کاربر بد است و هم Render را مبهم می‌کند.

Log باید Release، Route، Device/network class و Correlation ID داشته باشد؛ محتوای جستجوی کاربر، Token و اطلاعات پرداخت را خام ثبت نکنید.

روش ممیزی: Raw HTML را با Rendered DOM مقایسه کنید

یک URL نمونه کافی نیست. از هر Template و State نمونه بگیرید: محصول موجود/ناموجود، دسته خالی/پرحجم، مقاله، صفحه Pagination، Redirect، ۴۰۴ و API failure. سپس این ماتریس را بسازید:

از URL Inspection برای مشاهده اطلاعات Crawl/Index و Render استفاده کنید، اما نتیجه Live Test را با Indexing تضمینی اشتباه نگیرید. Search operatorها هم جای URL Inspection نیستند. اگر صفحه ایندکس نمی‌شود، Runbook تشخیصی حل مشکل ایندکس‌نشدن را اجرا کنید.

تست Release باید سه لایه داشته باشد

۱. Contract test در Build

• هر Fixture یک Title، H1، Canonical و Index policy موردانتظار دارد.
• Linkهای کلیدی Anchor واقعی و URL مطلق/قابل‌حل دارند.
• Schema parse و با Fixture داده تطبیق داده می‌شود.
• Bundle و Dependency budget از حد Release عبور نمی‌کند.

۲. Render test در Preview

• JavaScript روشن/خاموش، Mobile/desktop و Network/CPU ضعیف آزمایش می‌شود.
• Raw/Rendered diff برای متن، Metadata، Links و Schema ثبت می‌شود.
• Route مستقیم، Back/Forward، Refresh، ۴۰۴ و Redirect تست می‌شوند.
• API timeout، Chunk failure و Hydration mismatch تزریق می‌شوند.

۳. Synthetic و RUM در Production

• URLهای نماینده از چند شبکه و Region Fetch/Render می‌شوند.
• Status، content marker، Canonical، Render time و JS error Alert دارند.
• LCP/INP/CLS براساس Template، Device، release و percentile پایش می‌شوند.
• Index/Crawl داده Search Console با Deployment annotation تحلیل می‌شود.

SEO Definition of Done را وارد CI/CD کنید

Checklist جدا در انتهای پروژه معمولاً دیر است. Release gate پیشنهادی:

Block release if:
- public route has no meaningful initial content
- canonical/robots/title differ across source and rendered output
- internal navigation lacks <a href>
- missing entity returns 200
- schema conflicts with visible truth
- critical JS/API is blocked or unavailable
- representative journey exceeds agreed field/lab guardrail
- rollback artifact or owner is missing

چک‌لیست جامع‌تر Staging تا انتشار در راهنمای سئوی فنی طراحی سایت آمده است. هر Gate باید Owner، Evidence و Exception expiry داشته باشد؛ «بعداً درست می‌کنیم» بدون تاریخ، استثنا نیست.

سایت‌ساز JavaScript را با خروجی واقعی ارزیابی کنید

نام Wix، Webflow یا هر Vendor به‌تنهایی پاسخ نیست؛ قابلیت‌ها و محدودیت‌ها تغییر می‌کنند. یک Pilot روی Domain آزمایشی با Page type واقعی اجرا کنید و این موارد را بسنجید:

برای انتخاب خود پلتفرم و مرزبندی SEO capability، چارچوب سنجش SEO Fit سایت‌ساز را کنار این ممیزی فنی استفاده کنید.

سه سناریوی تصمیم‌گیری

فروشگاه ایرانی با قیمت و موجودی پویا

نام، توضیح، تصویر، Breadcrumb، قیمت/وضعیت صادقانه و لینک‌های دسته در HTML اولیه حاضرند. موجودی از Source واحد می‌آید و UI/Schema/Feed reconcile می‌شوند. اگر سامانه قیمت قطع شد، صفحه قیمت ساختگی نشان نمی‌دهد. محصول حذف‌شده ۴۰۴/۴۱۰ یا Redirect مرتبط دارد؛ Payment و Webhook شکست جداگانه پایش می‌شوند.

مجله محتوایی با انتشار روزانه

Static یا Revalidated output معمولاً از SSR per-request اقتصادی‌تر است. Publish event، صفحه و Sitemap را invalidate می‌کند؛ تاریخ و نویسنده واقعی، Canonical، Article schema و لینک‌های داخلی در Build تست می‌شوند. Related posts تعاملی می‌تواند Client-side باشد، اما بدنه و Navigation اصلی نه.

SaaS با Dashboard خصوصی و Landing عمومی

Landing، Pricing و Documentation خروجی Crawlable دارند؛ Dashboard پس از Login، CSR و Noindex/Access control مناسب دارد. تلاش برای SSR کل Dashboard فقط برای «سئو» هزینه بی‌فایده است. Boundary عمومی/خصوصی، Cache key و جلوگیری از نشت داده اولویت دارند.

شرایط ایران را در Test matrix وارد کنید

تست فقط روی اینترنت دفتر و گوشی پرچم‌دار، شکست کاربران واقعی را پنهان می‌کند. ماتریس ایران باید شامل Android میان‌رده/قدیمی، WebView، اینترنت ثابت و اپراتورهای موبایل، Cold cache، Packet loss و DNS/CDN متفاوت باشد.

• Dependency خارجی: CDN، Font، Analytics، CAPTCHA، Map یا API ممکن است کند یا غیرقابل‌دسترسی شود؛ fallback و timeout داشته باشید.
• فارسی و RTL: H1/Title، Slug، نیم‌فاصله، ی/ک، Bidi در Code/Price، فونت و Hydration locale را بررسی کنید.
• تجارت: تومان/ریال، موجودی Variant، درگاه و بازگشت بانک نباید میان HTML، Client state و Schema اختلاف بسازند.
• رصد: Synthetic probe داخلی و خارجی، Server log و RUM کمینه‌گرا را کنار هم بگذارید؛ نبود یک ابزار خارجی را نبود خطا فرض نکنید.

برنامه ۳۰ روزه اصلاح سئوی JavaScript

سؤال‌های متداول

آیا React و Vue برای سئو بد هستند؟

خیر. نتیجه به خروجی هر Route بستگی دارد: URL و Link قابل‌کشف، HTML و Metadata، Status، Render موفق، Performance و کیفیت محتوا. هر دو می‌توانند با Static، SSR، Hydration یا CSR استفاده شوند؛ مدل را براساس نوع صفحه انتخاب کنید.

آیا برای سئو باید همه صفحات SSR شوند؟

خیر. مقاله و Landing می‌توانند Static/Revalidated، صفحه پویا SSR/Hybrid و Dashboard خصوصی CSR باشند. SSR هزینه Server و Failure mode دارد و Hydration سنگین ممکن است INP را بدتر کند. Route contract معیار انتخاب است.

آیا گوگل JavaScript را اجرا می‌کند؟

بله، Google Search از Web Rendering Service مبتنی بر Chromium استفاده می‌کند؛ اما Render یک مرحله مستقل با محدودیت Resource و Failure است و همه Botها نیز JavaScript اجرا نمی‌کنند. محتوای ضروری در HTML اولیه، ریسک را کم می‌کند.

Dynamic Rendering هنوز راهکار توصیه‌شده است؟

خیر؛ گوگل آن را workaround و نه راه‌حل بلندمدت می‌داند و SSR، Static rendering یا Hydration را ترجیح می‌دهد. در Legacy ممکن است پل موقت باشد، مشروط به Parity، مانیتورینگ و برنامه خروج.

برای تشخیص مشکل اول View Source را ببینیم یا URL Inspection؟

هر دو، همراه با پاسخ HTTP و Rendered DOM. View Source/Fetch خروجی اولیه را نشان می‌دهد، DevTools نتیجه مرورگر را و URL Inspection شواهد گوگل را. اختلاف Title، متن، Link، Canonical، Robots، Schema و Status میان این سطوح، سرنخ اصلی است.

جمع‌بندی

سئوی JavaScript جنگ SSR و CSR نیست؛ مهندسی یک قرارداد قابل‌آزمون برای هر URL است. Route/Intent را تعریف کنید، Render mode متناسب برگزینید، HTML حداقل مفید، Link واقعی و Status درست تحویل دهید، Metadata و Schema را با حقیقت صفحه هم‌راستا نگه دارید و Raw/Rendered/Google evidence را در Release مقایسه کنید. سپس با JS budget، RUM، Synthetic و Rollback، این کیفیت را در دستگاه و شبکه واقعی ایران حفظ کنید.

منابع فنی منتخب

• Google Search Central — JavaScript SEO basics
• Google Search Central — Dynamic rendering as a workaround
• Google Search Central — Fix search-related JavaScript problems
• Google Search Central — Generate structured data with JavaScript
• web.dev — Rendering on the Web
• web.dev — Web Vitals