سئو تکنیکال در Next.js؛ راهنمای عملی برای محصول‌ها و وب‌سایت‌های مدرن

سئو Next.js را نمی‌شود به یک فایل robots.txt تقلیل داد. موتور جست‌وجو باید HTML معنادار ببیند، عنوان و نشانی ترجیحی را بفهمد، تصویر را از نسخهٔ درست بخواند، و صفحه را در زمانی معقول به ایندکس برساند. App Router این کارها را ممکن می‌کند؛ خودکار و بی‌نقص انجام نمی‌دهد. سئو تکنیکال اینجا یعنی تصمیم رندر، قرارداد metadata، و کنترل URL تکراری را در همان معماری محصول بگذارید.

این راهنما برای تیم محصول و مهندسی است که سایت یا SaaS را روی Next.js می‌سازند. رتبهٔ ساختگی و امتیاز آزمایشگاهی جعلی ندارد. به مستندات Metadata و Open Graph در Next.js و راهنماهای ایندکس Google Search Central ارجاع می‌دهد تا تصمیم‌ها قابل‌پیگیری باشند.

رندر: آنچه خزنده می‌بیند باید همان ارزش صفحه باشد

گوگل جاوااسکریپت را اجرا می‌کند، اما ایندکس مبتنی بر جاوااسکریپت دو موج دارد: ابتدا HTML اولیه، بعد در صورت نیاز رندر. اگر محتوای اصلی—عنوان محصول، قیمت، بدنهٔ مقاله—فقط بعد از fetch کلاینت ظاهر شود، شما به موج دوم و به شکنندگی آن وابسته‌اید. برای صفحهٔ بازاریابی، مقاله و کاتالوگ عمومی، HTML اولیه باید همان محتوا را داشته باشد.

در App Router این یعنی صفحهٔ عمومی را با Server Component و دادهٔ سرور بسازید. "use client" را به جزیرهٔ تعامل محدود کنید. اگر لیست محصول در کلاینت با یک API خالی از SEO لود می‌شود، اسلاگ ایندکس می‌شود و بدنه خالی یا اسکلتون می‌ماند. این با «اسپا بودن» توجیه نمی‌شود؛ با تصمیم اشتباه مرز سرور و کلاینت توجیه می‌شود.

وضعیت HTTP را جدی بگیرید. صفحهٔ حذف‌شده باید ۴۰۴ واقعی باشد نه صفحهٔ نرم با پیام «پیدا نشد» و وضعیت ۲۰۰. نرم‌۴۰۴ بودجهٔ خزش را تلف می‌کند و ایندکس را آلوده می‌کند. برای احراز هویت، صفحهٔ عمومی را با شل خالی که بعداً در کلاینت ریدایرکت می‌شود ایندکس نکنید؛ ریدایرکت و robots را در سرور تعیین کنید.

پیش‌فرض SSG یا SSR را صفحه به صفحه انتخاب کنید. کاتالوگ بزرگ با تغییر موجودی ممکن است SSR یا ISR بخواهد. مقالهٔ پایدار می‌تواند استاتیک باشد. مهم این است که خروجی HTML برای نیت همان صفحه کامل باشد، نه اینکه کل سایت یک استراتژی رندر داشته باشد چون در بویلرپلیت همین بوده.

Metadata API: عنوان، توضیح، Open Graph و robots در یک قرارداد

Next.js در App Router فیلدهای title، description، openGraph، twitter، robots و alternates را از طریق metadata یا generateMetadata می‌سازد. این قرارداد را در مستندات metadata و تصویر OG دنبال کنید؛ تگ دستی پراکنده در چند لایهٔ layout معمولاً تداخل می‌سازد.

الگوی عنوان را ثابت کنید: نام صفحه، سپس نام محصول یا برند. در generateMetadata داده را از همان منبعی بخوانید که خود صفحه می‌خواند تا عنوان با H1 یکی بماند. عنوان قالب خالی مثل «محصول | سایت» وقتی fetch شکست می‌خورد، بدتر از یک ۴۰۴ تمیز است. در خطای داده، metadata را هم به حالت خطا ببرید.

description را از روی چکیدهٔ واقعی بسازید نه از یک جملهٔ ثابت قالب. Open Graph را برای اشتراک و برای برخی ربات‌ها کامل کنید: title، description، url مطلق، تصویر با اندازهٔ مشخص. تصویر OG را برای هر نوع صفحه پیش‌فرض بگذارید و برای مقاله یا محصول مهم، اختصاصی کنید. مسیر نسبی را در OG رها نکنید؛ خزنده و پیام‌رسان URL مطلق می‌خواهند.

robots را در metadata برای صفحات خصوصی، فیلتر بی‌ارزش و نتیجهٔ جست‌وجوی داخلی روی noindex بگذارید. این را با فایل robots یکی نگیرید. فایل، خزش را در سطح مسیر محدود می‌کند؛ تگ، ایندکس یک URL را. صفحهٔ لاگین نباید ایندکس شود حتی اگر در sitemap نیست.

Canonical و نسخه‌های تکراری را در مسیر، نه در محتوا، حل کنید

هر صفحهٔ ایندکس‌شونده باید alternates.canonical به نسخهٔ ترجیحی خودش داشته باشد. نسخهٔ ترجیحی یعنی همان قراردادی که ریدایرکت دامنه، اسلش پایانی و حروف اسلاگ را یکسان کرده است. اگر canonical به URL دیگری اشاره کند که خودش ریدایرکت است، سیگنال را دو تکه کرده‌اید. منطق ادغام را با راهنمای گوگل دربارهٔ یکپارچه‌سازی URLهای تکراری هم‌خط کنید.

تکراری‌های رایج Next.js: همان صفحه با و بدون www، http و https، پارامتر utm که به عمد ایندکس شده، و مسیر /page در برابر /page/ اگر هر دو ۲۰۰ بدهند. یکی را در middleware یا هاست ریدایرکت کنید. Canonical مکمل ریدایرکت است نه جایگزین آن.

مسیرهای موازی App Router مثل گروه‌های (marketing) در URL ظاهر نمی‌شوند؛ این خوب است. اما اگر همان محتوا را در /blog/x و /articles/x منتشر کردید، خودتان duplicate ساخته‌اید. یک مسیر عمومی انتخاب کنید و بقیه را ۳۰۱ کنید. جزئیات جابه‌جایی مسیر را در چک‌لیست مهاجرت بدون افت سیگنال ایندکس ببینید؛ اینجا فقط این را ببندید که دو route زنده برای یک محتوا نداشته باشید.

Preview و محیط stage باید noindex و در صورت امکان مسدود در robots باشند. ایندکس شدن دامنهٔ پیش‌نمایش با عنوان مشابه، cannibalization خارجی برای خودتان است.

Structured data: Schema.org را به موجودیت واقعی صفحه وصل کنید

دادهٔ ساختاریافته حدس گوگل را کم می‌کند اگر با محتوا یکی باشد. نوع را از Schema.org انتخاب کنید: WebSite و Organization در سطح دامنه، Article برای مقاله، Product و Offer برای کاتالوگ، BreadcrumbList برای مسیر، FAQPage فقط وقتی پرسش و پاسخ واقعاً در HTML هست. JSON-LD را در سرور کنار همان داده‌ای بسازید که صفحه رندر می‌کند.

url و @id باید نسخهٔ canonical باشند. قیمت و موجودی در Offer باید با آنچه کاربر می‌بیند یکی باشد. ستارهٔ ساختگی و AggregateRating بدون مرور واقعی، هم سیاست گوگل را نقض می‌کند هم اعتماد را. اگر داده ندارید، نوع را حذف کنید؛ نوع ناقص بهتر از نوع دروغین نیست.

برای چند زبان، inLanguage و اگر لازم است hreflang را جدا از JSON-LD در metadata بگذارید. قاطی کردن زبان در یک URL بدون اشاره، هم ایندکس را گیج می‌کند هم UX را. در محصول فارسی RTL، جهت صفحه را در HTML مشخص کنید؛ این سئو محض نیست اما به رندر و اسنیپت کمک می‌کند.

بعد از استقرار، یک نمونه از هر نوع صفحه را در مستندات تست گوگل برای structured data چک کنید. خطا را مثل تست واحد ببندید. هشدار فیلد توصیه‌شده را با فیلد اجباری یکی نکنید؛ اول صحت، بعد کامل بودن.

تصویر و Core Web Vitals: سرعت بخشی از ایندکس کیفیت است

next/image را برای تصاویر محتوایی جدی بگیرید: اندازهٔ مناسب، alt توصیفی، و پرهیز از تصویر غول‌پیکر در هیرو که LCP را می‌کشد. LCP معمولاً همان تصویر بزرگ یا بلوک عنوان است. اگر هیرو ویدیو یا اسلایدر سنگین است، برای خزش و برای کاربر هر دو هزینه دارد. مستندات گوگل دربارهٔ Core Web Vitals را به‌عنوان تعریف میدان ببینید، نه به‌عنوان امتیاز آزمایشگاهی که در CI جعل می‌شود.

CLS را با ابعاد مشخص تصویر و جا برای فونت و بنر ببندید. فونت فارسی با swap بی‌قید ممکن است پرش متن بسازد؛ وزن و زیرمجموعه را محدود کنید. INP را با کم کردن جاوااسکریپت سرصفحه و جدا کردن جزیره‌های کلاینت بهتر کنید. سئو تکنیکال Next.js یعنی باندل صفحهٔ مقاله نباید همان باندل داشبورد لاگین‌شده باشد.

تصاویر محصول را با نام فایل و alt واقعی بدهید. IMG_4032 و alt خالی، کشف تصویر را ضعیف می‌کند. اگر CDN جدا دارید، URL نهایی پایدار بماند تا بعد از هر بیلد ایندکس تصویر نشکند.

اندازه‌گیری را روی دادهٔ میدانی Search Console و نمونهٔ واقعی موبایل بگذارید. شبیه‌سازی لوکال فقط برای پیدا کردن رگرسیون است. عدد CWV را در مقالهٔ بازاریابی جعل نکنید؛ رگرسیون را در PR مثل تست ببینید.

Sitemap و robots: کشف را هدایت کنید، ایندکس را با کیفیت صفحه بخرید

app/sitemap.ts باید URLهای canonical با وضعیت ۲۰۰ را برگرداند. مقالهٔ پیش‌نویس، فیلتر، جست‌وجو و صفحهٔ کاربری را وارد نکنید. برای کاتالوگ بزرگ، sitemap را بخش‌بخش کنید و lastModified را از دادهٔ واقعی بگذارید تا خزنده اولویت را بفهمد. راهنمای گوگل برای نقشهٔ سایت را مبنای فیلدها بگیرید.

robots.txt را در app/robots.ts با اجازهٔ خزش صفحات عمومی و مسدود کردن /admin، پیش‌نمایش و APIهای بی‌فایده برای جست‌وجو بسازید. مسدود کردن CSS و JS لازم برای رندر را تکرار نکنید؛ مدل قدیمی «بستن همهٔ اسکریپت‌ها» با خزش جاوااسکریپت نمی‌خواند. آدرس sitemap را در robots اعلام کنید.

Sitemap جایگزین لینک داخلی برای کشف خوشه و صفحات پول‌ساز نیست. صفحهٔ یتیم ممکن است از sitemap کشف شود اما سیگنال رابطه نگیرد. هر دو لایه را با هم ببندید.

بعد از لانچ، sitemap را در Search Console ثبت کنید و پوشش را بخوانید. excluded به‌خاطر noindex عمدی خوب است؛ excluded به‌خاطر duplicate یا 404 بد است.

Pagination، فیلتر و پارامتر: کجا ایندکس، کجا noindex

لیست‌های بلند را صفحه صفحه کنید با لینک واقعی به ?page=2 یا /page/2، نه دکمهٔ «بیشتر» که فقط کلاینت را صدا می‌زند و URL عوض نمی‌کند. اگر صفحهٔ دوم برای خزنده وجود ندارد، محتوای آن وجود ندارد. Canonical صفحهٔ ۲ را به صفحهٔ ۱ ندهید اگر محتوای صفحهٔ ۲ یکتاست؛ این الگوی قدیمی باعث می‌شود صفحهٔ ۲ ایندکس نشود و لینک‌هایش هدر برود. هر صفحهٔ فهرست، canonical خودش را داشته باشد مگر واقعاً تکرار کامل باشد.

فیلترها را به سه دسته تقسیم کنید: فیلتر با نیت جست‌وجوی واقعی (ایندکس و هاب)، فیلتر ترکیبی بی‌ارزش (noindex، follow محدود)، و مرتب‌سازی (معمولاً noindex). اگر همهٔ ترکیب‌ها ۲۰۰ و ایندکس باشند، کاتالوگ خودش را تکه‌تکه می‌کند.

پارامترهای ردیابی را در middleware به نسخهٔ تمیز ریدایرکت یا از ایندکس خارج کنید. کپی utm در ایندکس، duplicate است. جست‌وجوی داخلی را noindex کنید؛ رقابت با کاتالوگ خودتان ارزش ندارد.

ایندکس بعد از استقرار: از بیلد تا Search Console

بعد از دیپلوی، چند URL نمونه را با «View Source» و با ابزار بازرسی URL در Search Console ببینید. آنچه در React DevTools می‌بینید معیار خزنده نیست؛ HTML اولیه و رندر گوگل معیار است. درخواست ایندکس را برای خانه، یک هاب و چند صفحهٔ پول‌ساز بگذارید؛ برای کل کاتالوگ صبر و لینک داخلی کارآمدتر است.

اگر سایت از وردپرس آمده، لایهٔ تکنیکال Next را با لایهٔ نگاشت URL قاطی نکنید. مسیر تعویض پلتفرم در مهاجرت وردپرس به Next.js با حفظ قرارداد صفحه است. اینجا فقط بررسی کنید metadata، وضعیت HTTP و sitemap مقصد از روز اول درست‌اند؛ وگرنه مهاجرت تمیز روی بیلد اشتباه سوار می‌شود.

محیط تولید را با هدر کش اشتباه برای HTML ایندکس‌شونده خراب نکنید. HTML صفحهٔ محصول که قیمت را ۲۴ ساعت در CDN نگه می‌دارد، ممکن است با structured data و با کاربر نخواند. کش را روی دارایی استاتیک سنگین کنید، نه روی معنایی که باید تازه باشد.

نمونه‌های واقعی معماری فروشگاه، SaaS و سایت اختصاصی Next.js را در پروژه‌های NODE ببینید. هر کدام تصمیم رندر و URL متفاوتی دارند؛ الگوی مشترک این است که صفحهٔ عمومی برای انسان و خزنده یک سند کامل است، نه پوستهٔ خالی.

پرسش‌های متداول

آیا SPA بودن Next.js برای سئو کافی است اگر Googlebot جاوااسکریپت اجرا می‌کند؟

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

Canonical را در layout ریشه بگذاریم؟

canonical ریشه را برای همهٔ مسیرها کپی نکنید. هر route باید canonical خودش را بسازد. مقدار ثابت دامنه به‌اضافهٔ مسیر جاری معمولاً درست است؛ مقدار ثابت فقط روی / غلط است.

FAQPage را به هر مقاله اضافه کنیم؟

فقط اگر پرسش و پاسخ در صفحه هست و برای کاربر است. JSON-LD بدون HTML معادل، سیگنال ضعیف و در صورت سوءاستفاده، ریسک سیاست است.

سئو تکنیکال در Next.js یعنی رندر سرور برای صفحهٔ عمومی، metadata و canonical دقیق، Schema.org صادق، تصویر و CWV تحت کنترل، و sitemap/robots هم‌خط با کیفیت URL. قدم بعدی این است که یک نوع صفحهٔ پول‌ساز را انتخاب کنید و HTML اولیه، تگ‌ها و JSON-LD همان صفحه را در تولید با ابزار بازرسی URL ببندید؛ نه در لوکال تنها.