سئو سایت‌های Next.js: متادیتا، نقشه‌ی سایت و رندر

Next.js کنترل بیشتری روی سئو نسبت به تقریباً هر فریم‌ورک دیگری به شما می‌دهد و دقیقاً به همین دلیل اشتباه کردن در آن ساده است. هیچ چیزی جلوی شما را نمی‌گیرد که صفحه‌ای بدون متادیتا بنویسید، یک تگ canonical که همه‌جا را با هم اشاره می‌کند، یا یک نقشه‌ی سایت که آدرس‌های خراب را فهرست کرده است. برخلاف پلتفرمی مثل وردپرس، اینجا افزونه‌ای بی‌سروصدا از شما محافظت نمی‌کند. این راهنما بخش‌هایی از پروژه‌ی Next.js را مرور می‌کند که واقعاً عملکرد سایت در جستجو را تعیین می‌کنند، به همان ترتیبی که روی پروژه‌های واقعی بررسی می‌کنیم، همراه با چند اشتباهی که خودمان روی سایت خودمان داشتیم و بعد رفعشان کردیم.

اگر هنوز بین Next.js و پلتفرم دیگری در حال انتخاب هستید، مقایسه‌ی Next.js و وردپرس به آن تصمیم می‌پردازد. این مقاله فرض می‌کند Next.js را انتخاب کرده‌اید و می‌خواهید درست از آن استفاده کنید.

رندر: مطمئن شوید محتوا بدون جاوااسکریپت هم وجود دارد

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

Next.js از تولید ایستا، رندر سمت سرور و بازتولید تدریجی پشتیبانی می‌کند و انتخاب درست به نوع صفحه بستگی دارد. صفحه‌های معرفی، صفحه‌های خدمات و مقاله‌های وبلاگ کم تغییر می‌کنند و برای همه‌ی بازدیدکننده‌ها یکسان‌اند، پس تولید ایستا معمولاً درست است: HTML یک بار ساخته می‌شود و فوری ارائه می‌شود، از قبل شامل عنوان‌ها و متن شما. صفحه‌هایی با محتوای مخصوص هر کاربر به رندر سمت سرور نیاز دارند. وبلاگی که مرتب منتشر می‌کند می‌تواند از بازتولید تدریجی برای تازه کردن صفحه‌های ایستا در یک بازه‌ی زمانی، بدون build کامل، استفاده کند. هرکدام را انتخاب کنید، آزمونش ساده است: سورس صفحه را ببینید، یا آدرس را بدون مرورگر fetch کنید و مطمئن شوید محتوای واقعی‌تان آنجاست.

Metadata API: عنوان، توضیح و canonical برای هر صفحه

Next.js اجازه می‌دهد هر مسیر متادیتای خودش را از طریق generateMetadata یا یک شیء ثابت metadata صادر کند و اینجا همان جایی است که بیشتر کار واقعی سئو انجام می‌شود. هر صفحه‌ی قابل ایندکس باید عنوان و توضیح خودش را تعریف کند، نه این‌که از layout به ارث ببرد، چون عنوان سطح layout همان لحظه‌ای کلی می‌شود که دو صفحه باید چیز متفاوتی بگویند. ما خودمان بعد از این‌که متوجه شدیم canonical سطح layout بی‌سروصدا هر صفحه‌ی بدون canonical خودش را به صفحه‌ی اصلی می‌فرستاد، الگوی متادیتای سایت‌مان را بازنویسی کردیم. نوشتن یک‌بار و فراموش کردنش ساده است و تا وقتی یک صفحه برای هیچ چیزی رتبه نگیرد، متوجهش نمی‌شوید.

یک الگوی کاربردی برای کامپوننت یک صفحه:

export async function generateMetadata({ params }): Promise<Metadata> {
  const { locale, slug } = await params;
  return {
    title: pageTitle,
    description: pageDescription,
    alternates: {
      canonical: `https://example.com/${locale}/path/${slug}`,
      languages: { en: enUrl, fa: faUrl, "x-default": faUrl },
    },
    openGraph: { title: pageTitle, description: pageDescription, url: canonicalUrl, images: [ogImage] },
  };
}

دو عادت جلوی بیشتر مشکل‌های عنوان را می‌گیرد. اول، از یک قالب عنوان در سطح ریشه که نام برند را به عنوانی که از قبل آن را دارد اضافه می‌کند پرهیز کنید، چون نتیجه‌اش «عنوان صفحه | برند | برند» روی هر صفحه‌ای می‌شود که عنوان کامل خودش را تنظیم کرده. دوم، بعد از build خروجی رندرشده را بررسی کنید، نه فقط کد را، چون قالبی که در سطح اشتباه اعمال شده تا وقتی HTML واقعی را نبینید نامرئی می‌ماند.

نقشه‌ی سایت و robots به‌شکل کد

فایل‌های app/sitemap.ts و app/robots.ts اجازه می‌دهند این‌ها را از محتوای واقعی‌تان تولید کنید، به‌جای نگهداری دستی. این بیشتر از آن‌چه به نظر می‌رسد اهمیت دارد: نقشه‌ی سایت دستی همین که یک نفر فراموش کند صفحه‌ی جدید را اضافه کند، بی‌صدا قدیمی می‌شود، در حالی که نقشه‌ی تولیدشده تا وقتی از همان منبعی بخواند که صفحه‌هایتان از آن ساخته می‌شوند، مثل فهرست خدمات یا فایل‌سیستم وبلاگ، همیشه درست است.

برای یک سایت دوزبانه، نقشه‌ی سایت را طوری بسازید که هر آدرس نسخه‌های زبانی جایگزین خودش را، از جمله یک مورد x-default، اعلام کند. همین است که به گوگل می‌فهماند صفحه‌های فارسی و انگلیسی شما نسخه‌های یک محتوا هستند نه تکرارهای بی‌ربط، و جزئیه‌ای است که در کد اضافه کردنش پیش‌پاافتاده است و در نوشتن دستی فایل راحت جا می‌افتد.

داده‌ساختاریافته به‌شکل JSON-LD

داده‌ساختاریافته باید درون خود صفحه و از همان داده‌ای که محتوای قابل‌دیدن را می‌سازد تولید شود، تا این دو هیچ‌وقت از هم فاصله نگیرند. برای سایت کسب‌وکاری، مجموعه‌ی شروع کاربردی این است: Organization روی layout، WebSite با یک عمل جستجو در صورت لزوم، BreadcrumbList روی صفحه‌های تودرتو، Article روی مقاله‌های وبلاگ و Service یا Product هر جا مناسب باشد. Next.js این کار را ساده می‌کند: یک شیء جاوااسکریپت معمولی بسازید و آن را داخل یک تگ اسکریپت با type="application/ld+json" رندر کنید. تنها قاعده‌ای که اهمیت دارد این است که نشانه‌گذاری باید با چیزی که بازدیدکننده واقعاً می‌بیند یکی باشد؛ محتوایی را که واقعاً در صفحه نیست توصیف نکنید.

اشتباه‌های رایج مخصوص Next.js

چند مشکل مشخصاً روی پروژه‌های Next.js تکرار می‌شوند، چون از ساختار خود فریم‌ورک می‌آیند نه از ناآگاهی کلی درباره‌ی سئو.

canonical یا عنوان سطح layout که همه‌ی صفحه‌ها را بازنویسی می‌کند. متادیتای تعریف‌شده در یک layout والد، بسته به این‌که کدام فیلد را کجا تنظیم کرده‌اید، با متادیتای صفحه ترکیب می‌شود یا گاهی آن را بازنویسی می‌کند. این را با بازرسی دو نوع صفحه‌ی مختلف بعد از build آزمایش کنید، نه با خواندن کد و فرض درست بودنش.

مسیرهای پویا بدون generateStaticParams درست. اگر مسیر پویایی مثل [slug] مسیرهای شناخته‌شده‌اش را از قبل تولید نکند، صفحه‌ها ممکن است طوری در لحظه‌ی درخواست رندر شوند که برای اولین خزش کندتر باشد یا، بسته به تنظیمات، اصلاً به‌صورت ایستا در دسترس نباشد.

استفاده از کامپوننت کلاینت جایی که کامپوننت سرور کافی است. علامت‌گذاری غیرضروری یک کامپوننت با "use client" جاوااسکریپت بیشتری به مرورگر می‌کشد و می‌تواند محتوایی را که آن کامپوننت رندر می‌کند به تأخیر بیندازد. واکشی داده و رندر محتوا را هر جا صفحه به تعامل نیاز ندارد در کامپوننت‌های سرور نگه دارید.

تصاویر بدون کامپوننت next/image. کامپوننت تصویر داخلی، اندازه‌ی ریسپانسیو، بارگذاری تنبل زیر خط دید و بهینه‌سازی قالب را خودکار مدیریت می‌کند. رد کردنش برای تصویر اصلی بزرگ یکی از رایج‌ترین دلیل‌های امتیاز ضعیف LCP است که در راهنمای Core Web Vitals با جزئیات پوشش داده‌ایم.

فراموش کردن robots روی مسیرهای عمداً خصوصی. مسیرهای پیش‌نمایش، ابزارهای داخلی یا محتوای پیش‌نویس که در همان اپلیکیشن Next.js ساخته شده‌اند به noindex صریح یا حذف از نقشه‌ی سایت نیاز دارند، چون هیچ چیزی جلوی Next.js را نمی‌گیرد که با خوشحالی آن‌ها را رندر و به یک خزنده تحویل دهد.

بعد از هر انتشار بررسی کنید

اشتباه‌های پیکربندی در کد تا وقتی خروجی build را نبینید نامرئی می‌مانند. بعد از هر انتشار، HTML رندرشده‌ی چند نوع صفحه‌ی مختلف را نمونه‌برداری کنید: آدرس را مستقیم fetch کنید و دنبال تگ عنوان، لینک canonical و بلوک JSON-LD خودتان بگردید. صفحه‌ها را از Rich Results Test گوگل و PageSpeed Insights رد کنید. و گزارش ایندکس Search Console را در هفته‌های بعد زیر نظر داشته باشید؛ اگر دسته‌ای از صفحه‌ها کنار گذاشته شدند یا یک canonical به جای غیرمنتظره‌ای اشاره می‌کند، همان‌جایی است که پیکربندی خود فریم‌ورک معمولاً ارزش نگاه دوباره دارد. دقیقاً همین نوع بررسی را، روی سایت خودمان، در مطالعه‌ی موردی صفحه‌هایی که ایندکس نشدند توضیح داده‌ایم.

Next.js سئو را برایتان انجام نمی‌دهد، ولی تقریباً هر بهانه‌ی فنی برای اشتباه کردن را از بین می‌برد. باقی‌اش همان انضباطی است که هر سایتی لازم دارد: متادیتای یکتا برای هر صفحه، نقشه‌ی سایتی که واقعیت را نشان می‌دهد، داده‌ساختاریافته‌ای که با محتوا یکی است و محتوایی که به‌اندازه‌ی کافی برای جایی در ایندکس ارزش دارد. اگر بررسی بیرونی روی تنظیمات خودتان می‌خواهید، خدمات سئو ما یک ممیزی فنی کامل برای پروژه‌های Next.js را شامل می‌شود و خدمات طراحی سایت و توسعه وب ما این پایه‌ها را از همان ابتدا در پروژه می‌سازد.