تگ کنونیکال چیست؟ آموزش Canonical و مدیریت URL اصلی
وقتی یک محصول، مقاله یا صفحه دسته‌بندی با چند آدرس در دسترس باشد، موتور جستجو باید تصمیم بگیرد کدام URL را در نتایج نگه دارد. تگ کنونیکال یا rel="canonical" راهی است که نسخه ترجیحی را به گوگل معرفی می‌کند تا سیگنال‌های صفحات تکراری یا بسیار مشابه روی یک آدرس متمرکز شوند. این تگ برای مدیریت محتوای تکراری، پارامترهای فیلتر، نسخه‌های چاپی، آدرس‌های کمپین و اختلاف HTTP/HTTPS کاربرد دارد، اما دستور قطعی برای گوگل نیست.
در این آموزش canonical از تعریف و کدنویسی تا عیب‌یابی در Search Console را قدم‌به‌قدم بررسی می‌کنیم. مثال‌های HTML، هدر HTTP، وردپرس و Next.js نشان می‌دهند هر روش کجا مناسب است؛ سپس به فروشگاه، صفحه‌بندی، hreflang و کنونیکال بین‌دامنه‌ای می‌رسیم. اگر سیاست ایندکس سایت هنوز مشخص نیست، اجرای آن را در کنار خدمات سئو و تولید محتوا روبینش و یک ممیزی کامل سئو تکنیکال پیش ببرید تا canonical به وصله‌ای جدا از معماری سایت تبدیل نشود.
“You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.”
تگ کنونیکال چیست و canonical چیست؟
Canonicalization فرایندی است که در آن گوگل از میان URLهای تکراری یا بسیار شبیه، یک URL نماینده انتخاب می‌کند. تگ canonical یک عنصر link در بخش head سند HTML است که ترجیح مالک سایت را برای این انتخاب اعلام می‌کند. در زبان ساده، صفحه دارای تگ می‌گوید «نسخه اصلی این محتوا در این آدرس است»، اما گوگل همه سیگنال‌ها را کنار هم میگذارد و ممکن است URL دیگری را کامل‌تر یا مفیدتر تشخیص دهد.
وجود چند URL همیشه به معنی تخلف یا جریمه محتوای تکراری نیست؛ فروشگاه‌ها، نسخه‌های زبانی و سیستم‌های مدیریت محتوا به‌طور طبیعی آدرس‌های نزدیک به هم تولید می‌کنند. مسئله اصلی، پراکنده‌شدن سیگنال لینک‌ها، گزارش‌های تحلیلی نامنظم و مصرف زمان خزش برای نسخه‌هایی است که ارزش مستقلی ندارند. کنونیکال درست کمک می‌کند معیارها روی URL ترجیحی جمع شوند و گوگل نسخه‌های تکراری را کمتر بخزد، ولی جای کیفیت محتوا یا معماری اصولی لینکهای داخلی را نمی‌گیرد.
تگ canonical در سئو چه کاری انجام میدهد؟
کار اصلی canonical جلوگیری از «رقابت دو صفحه متفاوت» نیست، بلکه خوشه‌بندی URLهایی است که محتوای اصلی یکسان یا بسیار مشابه دارند. اگر دو صفحه برای دو نیت مستقل ساخته شده‌اند، کنونیکال‌کردن یکی به دیگری راه‌حل هم‌نوع‌خواری نیست؛ باید محتوا، هدف و ساختار آن‌ها را اصلاح یا در صورت ادغام واقعی از ۳۰۱ استفاده کرد. هرگز صفحه‌ای درباره کفش را به صفحه کیف canonical نکنید، چون صفحات نامرتبط عضو یک خوشه تکراری معتبر نیستند و گوگل احتمالاً سیگنال را نادیده می‌گیرد.
مزیت عملی دیگر، انتخاب یک URL تمیز برای نمایش در نتایج و گزارش‌گیری است. برای نمونه، لینکهای ورودی به نسخه دارای ?utm_source=newsletter می‌توانند همراه نسخه بدون پارامتر در یک خوشه تجمیع شوند. در کنار آن، title، محتوای اصلی و ساختار صفحه باید با هدف URL هماهنگ باشند؛ راهنمای فاکتورهای سئو داخلی صفحه این لایه را تکمیل می‌کند.
آیا canonical دستور قطعی است یا یک سیگنال قوی؟
طبق مستندات Google Search Central، canonical یک hint قوی است، نه directive قطعی. گوگل برای انتخاب URL نماینده به شباهت محتوای اصلی، HTTPS، ریدایرکت‌ها، تگ canonical، حضور در sitemap، لینکهای داخلی و سیگنال‌های دیگر نگاه می‌کند. اگر این پیام‌ها با هم تعارض داشته باشند، ممکن است «Google-selected canonical» با انتخاب شما متفاوت شود.
گوگل ریدایرکت را سیگنالی قوی می‌داند، تگ rel="canonical" نیز سیگنال قوی است و حضور در sitemap را سیگنال ضعیف توصیف می‌کند. ترکیب سیگنال‌های هم‌جهت احتمال پذیرش URL ترجیحی را بیشتر می‌کند؛ مثلاً لینکهای داخلی، نقشه سایت و self-canonical همگی باید به نسخه HTTPS تمیز اشاره کنند. برای تنظیم فایل XML بر همین مبنا، راهنمای نقشه سایت XML را بخوانید و URLهای redirect، noindex یا پارامتری را از آن بیرون نگه دارید.
آموزش canonical در HTML با URL مطلق
برای صفحه HTML، یک عنصر canonical داخل <head> قرار دهید و مقصد را با URL مطلق بنویسید. گوگل مسیر نسبی را پشتیبانی می‌کند، اما URL کامل توصیه می‌شود؛ زیرا خطای دامنه محیط آزمایشی، پروتکل یا زیردامنه را کاهش میدهد. مقصد بهتر است صفحه‌ای قابل ایندکس با پاسخ مستقیم 200 OK باشد، نه URL دارای 404، noindex یا زنجیره ریدایرکت.
<!doctype html>
<html lang="fa" dir="rtl">
<head>
<meta charset="utf-8" />
<title>راهنمای انتخاب کفش ورزشی</title>
<link rel="canonical" href="https://example.com/blog/running-shoes" />
</head>
<body>...</body>
</html>در هر صفحه فقط یک canonical روشن داشته باشید. قراردادن چند تگ با مقصدهای مختلف، یا اعلام یک مقصد در HTML و مقصدی دیگر در هدر HTTP، ابهام می‌سازد و ممکن است باعث نادیده‌گرفتن همه اعلان‌ها شود. canonical باید در head معتبر باشد؛ نسخه‌ای که اشتباهی در body قرار گرفته، برای این هدف قابل اتکا نیست.
Self-referencing canonical چیست و چرا لازم است؟
Self-referencing canonical یعنی URL اصلی در تگ canonical به خودش اشاره کند. برای مثال، صفحه https://example.com/blog/running-shoes همین آدرس را بهعنوان canonical اعلام می‌کند؛ نسخه‌های UTM، پارامتر چاپ یا مرتب‌سازی نیز به همان URL تمیز اشاره می‌کنند. گوگل استفاده از self-canonical را توصیه می‌کند، چون ترجیح صفحه اصلی را صریح می‌سازد و پارامترهای ناخواسته‌ای را که بعدها ایجاد می‌شوند بهتر کنترل می‌کند.
این الگو نباید به «همه صفحات به صفحه اصلی سایت» تبدیل شود. هر صفحه ایندکسپذیر و منحصربه‌فرد معمولاً self-canonical خودش را می‌خواهد؛ canonical کردن تمام محصولات، مقالات و دسته‌ها به homepage به گوگل پیام میدهد که محتواها تکراری‌اند، درحالی‌که چنین نیست. نتیجه معمولاً نادیده‌گرفتن تگ، حذف نامناسب URLها از خوشه یا بی‌ثباتی گزارش ایندکس است.
canonical در هدر HTTP برای PDF و فایل‌های غیر HTML
فایل PDF یا سندی که بخش HTML head ندارد، می‌تواند canonical را در هدر پاسخ HTTP اعلام کند. این روش برای نسخه‌های PDF، DOCX یا محتوای قابل دانلود مناسب است و بهتر است فقط یکی از روش‌های HTML یا HTTP را برای یک منبع انتخاب کنید تا نگهداری ساده بماند. مانند تگ HTML، مقصد را مطلق و بدون ریدایرکت بنویسید.
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://example.com/guides/seo-report>; rel="canonical"اگر PDF قرار است خودش در نتایج دیده شود، canonical آن را بی‌دلیل به صفحه HTML دیگری نفرستید. ابتدا مشخص کنید کدام نسخه برای کاربر کامل‌تر است و آیا محتوای دو نسخه واقعاً یکسان یا بسیار مشابه است. پاسخ سرور را با ابزارهای بررسی header کنترل کنید؛ دیدن کد در قالب HTML چیزی درباره هدر فایل دانلودی ثابت نمی‌کند.
تفاوت canonical و redirect 301 و noindex
این سه ابزار هدف یکسانی ندارند. canonical نسخه تکراری را برای کاربر قابل دسترس نگه می‌دارد و فقط نسخه ترجیحی را به موتور جستجو پیشنهاد می‌کند؛ ۳۰۱ کاربر و ربات را دائماً به URL جدید می‌فرستد؛ noindex نیز درخواست می‌کند همان صفحه در نتایج قرار نگیرد. انتخاب اشتباه می‌تواند UX را خراب کند یا سیگنال‌های متناقض بسازد.
| روش | رفتار برای کاربر | هدف سئویی | نمونه کاربرد مناسب | نکته مهم |
|---|---|---|---|---|
rel="canonical" |
URL فعلی باز می‌ماند | تجمیع نسخه‌های تکراری یا بسیار مشابه | پارامتر مرتب‌سازی یا نسخه چاپ | سیگنال قوی است، نه دستور قطعی |
| Redirect 301 | به URL مقصد منتقل می‌شود | جایگزینی دائمی URL قدیمی | مهاجرت دامنه یا ادغام صفحه حذف‌شده | برای کنارگذاشتن نسخه قدیمی، روشن‌ترین انتخاب است |
noindex |
صفحه همچنان باز می‌شود | حذف همان URL از نتایج | جستجوی داخلی یا صفحه تشکر | ابزار تجمیع سیگنال صفحات تکراری نیست |
اگر صفحه قدیمی دیگر برای هیچ کاربری لازم نیست، ۳۰۱ به مقصد مرتبط معمولاً از canonical منطقی‌تر است. اگر صفحه باید باز بماند ولی ارزش حضور در نتایج ندارد و معادل تکراری مشخصی هم ندارد، noindex مناسب‌تر است. گوگل استفاده از noindex برای وادارکردن انتخاب canonical در یک سایت را توصیه نمی‌کند؛ برای صفحات تکراری، تگ canonical راه ترجیحی است.
canonical در فروشگاه، فیلترها و پارامترهای URL
فروشگاه اینترنتی می‌تواند برای یک دسته، هزاران URL با پارامتر رنگ، سایز، قیمت، ترتیب نمایش و شناسه کمپین تولید کند. اگر یک فیلتر فقط چینش را عوض می‌کند و محتوای اصلی همان دسته است، canonical به URL تمیز دسته انتخاب رایجی است. اما اگر ترکیبی مثل «کفش کوهنوردی مردانه ضدآب» تقاضای جستجو، موجودی کافی و محتوای منحصربه‌فرد دارد، ممکن است سزاوار یک لندینگ ایندکسپذیر با self-canonical باشد.
قانون ثابت «همه پارامترها canonical به دسته مادر» خطرناک است، چون بعضی فیلترها نیت واقعی و ارزش مستقل دارند. ابتدا الگوی تقاضا، تعداد محصولات، کیفیت متن و امکان لینک‌سازی داخلی را بررسی کنید، سپس برای هر گروه از پارامترها سیاست crawl و index بسازید. URL canonical باید پاسخ ۲۰۰، محتوای قابل مشاهده و مسیر داخلی قابل اتکا داشته باشد؛ canonical به صفحه محصول ناموجود، noindex یا ریدایرکت‌شده انتخاب پایداری نیست.
پارامترهای رهگیری مانند UTM معمولاً نباید داخل canonical نهایی یا فهرست URLهای اصلی در sitemap باشند. لینکهای داخلی نیز بهتر است مستقیماً نسخه تمیز را صدا بزنند تا خزنده مجبور نباشد هر بار از پارامتر یا ریدایرکت عبور کند. این هماهنگی به‌خصوص در فروشگاه‌های بزرگ از crawl trap و گزارش‌های پراکنده جلوگیری می‌کند.
canonical برای صفحه‌بندی چگونه تنظیم می‌شود؟
صفحات دوم، سوم و بعدی یک آرشیو معمولاً همان محتوای صفحه اول را تکرار نمی‌کنند؛ هرکدام مجموعه متفاوتی از محصولات یا نوشته‌ها دارند. بنابراین canonical کردن همه صفحات pagination به صفحه اول در اغلب سناریوها اشتباه است و می‌تواند کشف آیتم‌های عمیق‌تر را دشوار کند. راه امن عمومی این است که هر صفحه مفید و قابل ایندکس، self-canonical مستقل داشته باشد.
اگر یک صفحه «مشاهده همه» سریع، کامل و واقعاً معادل مجموعه صفحه‌بندی‌شده دارید، ارزیابی جداگانه ممکن است به استراتژی دیگری برسد؛ اما چنین تصمیمی نباید بدون بررسی عملکرد و حجم محتوا گرفته شود. گوگل دیگر از rel="next" و rel="prev" بهعنوان سیگنال ایندکس خود استفاده نمی‌کند، هرچند ساختار لینکهای next/previous برای کاربر و کشف URLها همچنان مفید است. عنوان، لینکهای داخلی و محتوای هر صفحه باید روشن کند که آن URL بخشی واقعی از توالی است.
رابطه hreflang و canonical در سایت چندزبانه
hreflang جای canonical را نمی‌گیرد و canonical نیز جای hreflang را پر نمی‌کند. در حالت معمول، نسخه فارسی باید به خودش canonical بدهد و با hreflang به نسخه انگلیسی اشاره کند؛ نسخه انگلیسی هم self-canonical و اشاره متقابل داشته باشد. گوگل توصیه می‌کند مقصد canonical در همان زبان باشد یا در نبود آن، نزدیک‌ترین جایگزین زبانی انتخاب شود.
<link rel="canonical" href="https://example.com/fa/services/seo" />
<link rel="alternate" hreflang="fa" href="https://example.com/fa/services/seo" />
<link rel="alternate" hreflang="en" href="https://example.com/en/services/seo" />
<link rel="alternate" hreflang="x-default" href="https://example.com/services/seo" />canonical کردن نسخه فارسی به انگلیسی، وقتی متن اصلی واقعاً ترجمه شده است، معمولاً نسخه فارسی را از ایفای نقش مستقل بازمی‌دارد و خوشه hreflang را آشفته می‌کند. فقط وقتی بدنه اصلی دو URL در یک زبان یکسان یا بسیار مشابه است، آن‌ها نامزد خوشه تکراری‌اند. در ممیزی، canonical و hreflang را با هم بخوانید و مطمئن شوید URLهای اشاره‌شده پاسخ ۲۰۰ و اشاره‌های متقابل معتبر دارند.
کنونیکال بین‌دامنه‌ای یا cross-domain canonical
گوگل می‌تواند canonical را از دامنه‌ای به دامنه دیگر بپذیرد؛ این قابلیت برای بازنشر قانونی یک مقاله در سایت شریک کاربرد دارد. نسخه منتشرشده در دامنه دوم می‌تواند به مقاله اصلی در دامنه منبع اشاره کند تا ترجیح و تجمیع سیگنال را اعلام کند. بااین‌حال، cross-domain canonical نیز تضمین حذف نسخه بازنشرشده از نتایج نیست و مالک دامنه مقصد باید تگ را درست نگه دارد.
برای انتقال کامل سایت یا تغییر دائمی دامنه، به cross-domain canonical تنها تکیه نکنید؛ ۳۰۱ صفحه‌به‌صفحه ابزار اصلی مهاجرت است و باید با sitemap، لینک داخلی و تنظیمات Search Console هماهنگ شود. canonical بین دو مطلب نامرتبط یا بین صفحه‌ای کم‌محتوا و صفحه‌ای با موضوع دیگر قابل دفاع نیست. اگر سندیکیشن بخشی از برنامه محتواست، قرارداد انتشار، زمان انتشار نسخه اصلی و امکان کنترل تگ را پیش از بازنشر مشخص کنید.
canonical وردپرس را چگونه تنظیم و بررسی کنیم؟
وردپرس هسته‌ای و افزونه‌های رایج سئو معمولاً canonical را به‌صورت خودکار در head تولید می‌کنند. در افزونه‌هایی مانند Yoast SEO یا Rank Math، فیلد canonical پیشرفته زمانی لازم است که مقصد با URL خود صفحه تفاوت دارد؛ برای صفحات عادی بهتر است تولید خودکار self-canonical حفظ شود. واردکردن دستی یک مقصد ثابت در قالب، به‌خصوص homepage، می‌تواند همان canonical را روی صدها نوشته و محصول تکثیر کند.
<!-- نمونه خروجی مورد انتظار در source صفحه وردپرس -->
<link rel="canonical" href="https://example.com/blog/canonical-guide/" />پس از تغییر، فقط به پنل افزونه اعتماد نکنید؛ View Source را باز کنید و عبارت canonical را جستجو کنید. تداخل دو افزونه سئو، کد قالب، افزونه چندزبانه، کش CDN و نسخه staging می‌تواند دو تگ یا دامنه اشتباه بسازد. آرشیو برچسب، دسته، صفحه نویسنده و محصولات متغیر را نمونه‌برداری کنید، زیرا سیاست درست آن‌ها لزوماً با نوشته ساده یکسان نیست.
canonical در Next.js و App Router
در Next.js App Router می‌توان canonical را با Metadata API ساخت. بهتر است metadataBase در layout ریشه دامنه اصلی را تعریف کند و هر route ایندکسپذیر canonical مختص خودش را در alternates بدهد. هرگز canonical صفحه اصلی را به شکلی در root layout نگذارید که همه صفحات فرزند آن را به ارث ببرند.
// app/layout.tsx
import type { Metadata } from "next";
export const metadata: Metadata = {
metadataBase: new URL("https://example.com"),
};
// app/blog/canonical-guide/page.tsx
export const metadata: Metadata = {
title: "تگ کنونیکال چیست؟",
alternates: {
canonical: "/blog/canonical-guide",
},
};اگر route داینامیک است، همان مقدار را در generateMetadata از slug معتبر بسازید و پارامترهای رهگیری را وارد مسیر canonical نکنید. هرچند Metadata API با metadataBase URL نهایی مطلق می‌سازد، خروجی رندرشده را در source یا ابزار inspection کنترل کنید تا دقیقاً یک تگ وجود داشته باشد. همچنین canonical را فقط در client component و پس از hydration تزریق نکنید؛ گوگل توصیه می‌کند سیگنال تا حد امکان در HTML منبع روشن باشد و JavaScript آن را تغییر ندهد.
canonical در سرچ کنسول: User-declared و Google-selected
در ابزار URL Inspection سرچ کنسول، بخش Page indexing می‌تواند دو مقدار مهم نشان دهد. User-declared canonical همان URLی است که شما با تگ یا روش‌های دیگر اعلام کرده‌اید و Google-selected canonical نسخه‌ای است که سامانه گوگل در عمل انتخاب کرده است. برابر بودن این دو نشانه هماهنگی است، اما متفاوت بودنشان به‌تنهایی دلیل جریمه نیست؛ باید علت تعارض سیگنال‌ها را پیدا کرد.
برای عیب‌یابی، ابتدا URL بررسی‌شده و مقصد canonical را هر دو inspect کنید. وضعیت پاسخ ۲۰۰، امکان ایندکس، robots، noindex، محتوای رندرشده، HTTPS، لینکهای داخلی، sitemap و canonical مقصد را کنار هم بگذارید. «Test Live URL» وضعیت فعلی قابل دسترسی را نشان میدهد، درحالی‌که داده ایندکس‌شده ممکن است مربوط به آخرین خزش باشد؛ بنابراین پس از اصلاح باید برای بازخزش زمان منطقی در نظر گرفت.
گزارش «Alternate page with proper canonical tag» معمولاً خطا نیست و می‌گوید URL جایگزین به‌درستی زیر canonical دیگری قرار گرفته است. پیام «Duplicate, Google chose different canonical than user» یعنی گوگل ترجیح شما را نپذیرفته و نسخه دیگری را نماینده دانسته؛ پیام «Duplicate without user-selected canonical» نیز نبود انتخاب صریح را نشان میدهد. تحلیل این گزارش‌ها بخشی از چک‌لیست سلامت خزش و ایندکس است، نه کاری که با تغییر کورکورانه همه تگ‌ها حل شود.
خطای canonical چرا رخ میدهد؟
رایج‌ترین علت، تعارض مستقیم است: صفحه A به B canonical میدهد، اما sitemap و لینکهای داخلی همچنان A را نسخه اصلی معرفی می‌کنند. گاهی B به C ریدایرکت می‌شود، noindex دارد، با robots مسدود است یا پاسخ ۴۰۴/۵۰۰ میدهد؛ در این حالت مقصد انتخاب مناسبی برای نمایندگی خوشه نیست. تفاوت چشمگیر محتوای A و B نیز به گوگل می‌گوید این دو اساساً تکراری نیستند.
خطاهای پیاده‌سازی شامل URL نسبی ناخواسته، پروتکل HTTP، دامنه staging، اسلش انتهایی ناسازگار، canonical chain، چند تگ و تزریق متناقض JavaScript است. مقصد canonical بهتر است URL نهایی مطلق، indexable و دارای پاسخ مستقیم ۲۰۰ باشد. خود تگ هم باید فقط یک بار و در head معتبر قرار گیرد.
یک خطای جدی دیگر، canonical کردن همه صفحات سایت به خانه یا یک دسته عمومی است. این کار برای حل duplicate گسترده میان صفحات نامرتبط طراحی نشده و اطلاعات معماری را مخدوش می‌کند. اگر محتواها واقعاً زائدند، ادغام و ۳۰۱ را بررسی کنید؛ اگر منحصربه‌فردند، self-canonical و بهبود مسیرهای لینک‌سازی داخلی راه منطقی‌تری است.
هماهنگی canonical با sitemap، لینک داخلی و Schema
canonical زمانی قابل اعتمادتر است که بقیه سایت همان URL را تقویت کنند. فقط URLهای canonical و indexable را در sitemap قرار دهید، breadcrumb و لینکهای متنی را مستقیماً به آن‌ها وصل کنید و نسخه‌های HTTP، پارامتری یا ریدایرکت‌شده را از مسیرهای داخلی حذف کنید. حضور در sitemap به‌تنهایی سیگنال ضعیفی است و نمی‌تواند canonical اشتباه یا محتوای متفاوت را جبران کند.
در داده ساختاریافته نیز فیلدهایی مانند url، mainEntityOfPage و شناسه‌های موجودیت باید با URL اصلی هماهنگ باشند. Schema ابزار canonicalization نیست، اما اختلاف آدرس‌ها کیفیت پیاده‌سازی و فهم موجودیت را پایین می‌آورد. برای کنترل این بخش، آموزش پیاده‌سازی Schema Markup را همراه تست Rich Results و بررسی source اجرا کنید.
چک‌لیست ممیزی و رفع خطای canonical
ممیزی را از URLهای درآمدزا، صفحات دارای افت ورودی و وضعیت‌های duplicate در Search Console شروع کنید. یک crawl کامل بگیرید و برای هر URL ستون‌های status code، indexability، canonical اعلام‌شده، canonical مقصد، canonical انتخابی گوگل، sitemap و تعداد لینک داخلی بسازید. سپس خطاها را بر اساس اثر کسب‌وکار و گستردگی template اولویت‌بندی کنید، نه فقط تعداد هشدار ابزار.
- هدف URL را مشخص کنید: آیا صفحه باید مستقل ایندکس شود، نسخه تکراری بماند یا کاملاً به URL دیگری منتقل شود؟
- تنها یک canonical پیدا کنید: source HTML و هدر HTTP را برای تگ‌های تکراری یا متناقض بررسی کنید.
- مقصد را تست کنید: URL مطلق باشد، پاسخ مستقیم ۲۰۰ بدهد، indexable باشد و به URL دیگری canonical نشود.
- شباهت محتوا را بسنجید: فقط صفحات یکسان یا بسیار مشابه را در یک خوشه قرار دهید و صفحات نامرتبط را جدا نگه دارید.
- self-canonical را کنترل کنید: هر صفحه منحصربه‌فرد قابل ایندکس باید ترجیح خودش را روشن اعلام کند.
- سیگنال‌ها را هم‌جهت کنید: لینک داخلی، sitemap، hreflang، HTTPS و structured data به URL اصلی اشاره کنند.
- پارامتر و pagination را نمونه‌برداری کنید: فیلترها را گروه‌بندی کنید و همه صفحات صفحه‌بندی را کورکورانه به صفحه اول نفرستید.
- قالب‌ها را بررسی کنید: صفحه محصول، دسته، مقاله، آرشیو، نسخه زبان و فایل PDF هر کدام نمونه تست داشته باشند.
- Search Console را تطبیق دهید: User-declared و Google-selected canonical را برای چند URL مهم مقایسه کنید.
- پس از اصلاح پایش کنید: crawl مجدد، درخواست ایندکس محدود برای URLهای کلیدی و بازبینی گزارش Pages را در برنامه قرار دهید.
در سایت بزرگ، رفع یک خطای template می‌تواند هزاران URL را اصلاح کند؛ بنابراین قبل از ویرایش تک‌صفحه‌ای، الگوی تولید canonical را پیدا کنید. در سایت کوچک نیز یک جدول ساده ماهانه از URLهای اصلی برای جلوگیری از regression کافی است. اگر تغییر شامل مهاجرت یا ادغام گسترده است، نگاشت ۳۰۱ را جداگانه مستند کنید و canonical را جایگزین redirect map ندانید.
اشتباهات رایج در آموزش canonical که باید کنار گذاشت
- تعریف canonical بهعنوان «دستور قطعی ایندکس»؛ درحالی‌که گوگل آن را hint می‌داند.
- اشاره همه صفحات به homepage یا یک صفحه عمومی، حتی وقتی محتواها متفاوت‌اند.
- استفاده از canonical برای صفحات نامرتبط یا برای حل هم‌نوع‌خواری واقعی کلمات کلیدی.
- انتخاب مقصد 404، noindex، blocked، ریدایرکت‌شده یا دارای canonical دیگر.
- قرار دادن بیش از یک canonical یا اعلام مقصدهای متفاوت در HTML و HTTP.
- وابستگی کامل به sitemap؛ با اینکه گوگل آن را سیگنال ضعیف canonicalization می‌داند.
- استفاده از URL نسبی، دامنه آزمایشی یا نسخه HTTP به‌جای URL مطلق HTTPS.
- canonical کردن تمام صفحه‌های pagination به صفحه اول بدون بررسی تفاوت آیتم‌ها.
- canonical یکسان میان زبان‌های واقعاً ترجمه‌شده به‌جای self-canonical و hreflang.
- بستن URL تکراری در robots.txt و انتظار اینکه گوگل canonical داخل آن را بخواند.
robots.txt ابزار canonicalization نیست؛ اگر خزنده نتواند محتوای صفحه و تگ آن را ببیند، ارزیابی خوشه دشوارتر می‌شود و حتی URL مسدودشده ممکن است بدون محتوای قابل خزش در نتایج ظاهر شود. ابزار حذف URL در Search Console هم راه انتخاب canonical نیست و می‌تواند نسخه‌ها را موقتاً از جستجو پنهان کند. تصمیم باید از هدف صفحه شروع شود: نگهداری نسخه مشابه، انتقال دائمی، یا خروج مستقل از ایندکس.
برنامه اجرایی canonical برای سایت‌های فارسی
ابتدا الگوهای URL را فهرست کنید: پروتکل و www، اسلش انتهایی، UTM، جستجوی داخلی، فیلتر فروشگاه، pagination، آرشیو وردپرس و نسخه‌های زبان. برای هر الگو تصمیم واحد بنویسید و آن را در template پیاده کنید؛ تصمیم‌های موردی پراکنده خیلی زود با هم تعارض پیدا می‌کنند. سپس URLهای اصلی را در sitemap و لینک داخلی تثبیت و خروجی واقعی production را crawl کنید.
در مرحله دوم، گزارش Pages و URL Inspection را با crawl داخلی تطبیق دهید و اختلاف انتخاب گوگل را بر اساس template دسته‌بندی کنید. اصلاح را از خطاهایی شروع کنید که صفحه پول‌ساز را از ایندکس بیرون برده‌اند یا هزاران URL تکراری می‌سازند. برای طراحی این فرایند در کنار محتوا و ساختار سایت، راهکار سئو فنی و محتوایی روبینش مسیر یکپارچه‌تری از نصب صرف یک افزونه ارائه میدهد.
جمع‌بندی: canonical درست یعنی سیگنال‌های هم‌جهت
تگ کنونیکال نسخه ترجیحی میان صفحات تکراری یا بسیار مشابه را معرفی می‌کند و به تجمیع سیگنال‌ها، نظم گزارش‌گیری و مدیریت خزش کمک می‌کند. این تگ سیگنالی قوی است اما دستور قطعی نیست؛ ریدایرکت‌ها قوی‌ترین راه برای کنارگذاشتن دائمی URL قدیمی‌اند و sitemap فقط یک سیگنال ضعیف کمکی است. مقصد canonical را مطلق، indexable، دارای پاسخ ۲۰۰ و مرتبط انتخاب کنید، در هر صفحه فقط یک تگ بگذارید و برای URLهای اصلی از self-referencing canonical استفاده کنید.
در فروشگاه و pagination نسخه‌ها را کورکورانه به صفحه مادر نفرستید، در سایت چندزبانه canonical را با hreflang اشتباه نگیرید و در WordPress یا Next.js خروجی واقعی source را بعد از deploy بررسی کنید. موفقیت زمانی بیشتر می‌شود که canonical، لینک داخلی، sitemap، schema، HTTPS و ریدایرکت‌ها یک URL واحد را تأیید کنند. اگر در Search Console انتخاب گوگل با انتخاب شما متفاوت است یا مهاجرت بزرگی در پیش دارید، از فرم مشاوره روبینش برای بررسی فنی و تدوین نقشه اصلاح شروع کنید.
سؤالات متداول
تگ کنونیکال چیست؟
یک سیگنال HTML یا HTTP است که URL نماینده و اصلی را در میان صفحات تکراری یا بسیار شبیه اعلام می‌کند تا اعتبار ایندکس روی همان نسخه متمرکز شود.
تفاوت canonical و ریدایرکت ۳۰۱ چیست؟
ریدایرکت کاربر و ربات را به مقصد جدید میبرد؛ canonical صفحه را باز میگذارد ولی نسخه دیگری را بهعنوان اصلی پیشنهاد میدهد.
چرا Google-selected canonical فرق دارد؟
معمولاً بهخاطر مقصد معیوب، شباهت ناکافی محتوا، لینکهای قویتر به URL دیگر یا تعارض سیگنالهایی مثل redirect و sitemap است.
آیا همه صفحات باید self-canonical داشته باشند؟
صفحات ایندکسپذیر بهتر است canonical مشخص داشته باشند؛ اگر خودشان نسخه اصلیاند به خودشان و اگر کپیاند به صفحه اصلی اشاره کنند.
canonical را در Next.js کجا بگذاریم؟
در metadata یا generateMetadata با alternates.canonical تا در HTML اولیه حاضر باشد و با metadataBase به URL مطلق تبدیل شود.