در نگاه اول، تگ کنونیکال (Canonical Tag) فقط یک خط ساده از کد HTML است؛ اما در سئوی فنی نقش مهمی در مشخص کردن URL ترجیحی، مدیریت صفحات مشابه و کمک به موتورهای جستجو برای درک رابطه میان URLهای مختلف دارد.
تصور کنید یک محصول، مقاله یا صفحه دسته‌بندی با چند URL مختلف در دسترس باشد. تفاوت این آدرس‌ها ممکن است به دلیل پارامترهای Tracking، فیلتر محصولات، مرتب‌سازی، نسخه‌های مختلف URL یا ساختار فنی سایت ایجاد شده باشد.
در این شرایط یک سؤال مهم مطرح می‌شود:
کدام URL باید نماینده اصلی این محتوا باشد؟
اینجاست که Canonical وارد عمل می‌شود. با استفاده از rel="canonical" می‌توان ترجیح سایت درباره URL نماینده یک محتوای تکراری یا بسیار مشابه را به موتورهای جستجو اعلام کرد.
البته یک نکته بسیار مهم را از همین ابتدا باید بدانید: Canonical فرمان قطعی به گوگل نیست. گوگل این تگ را در کنار سایر سیگنال‌ها بررسی می‌کند و ممکن است URL دیگری را به‌عنوان Canonical انتخاب کند.
در این راهنمای پرشیا وب، علاوه بر پاسخ به سؤال «تگ کنونیکال چیست؟»، نحوه استفاده از آن، Canonical در وردپرس، Self-referencing Canonical، صفحات فیلتر و پارامتری، تفاوت Canonical با 301 و Noindex، Pagination، JavaScript، PDF و روش عیب‌یابی Canonical در Google Search Console را بررسی می‌کنیم.
تگ کنونیکال چیست؟
تگ کنونیکال (Canonical Tag) یک عنصر link در HTML است که در بخش <head> صفحه قرار می‌گیرد و URL ترجیحی یک محتوا را به موتورهای جستجو معرفی می‌کند.
ساختار ساده آن به شکل زیر است:
<link rel="canonical" href="https://example.com/page/">برای مثال فرض کنید صفحه اصلی شما این URL باشد:
https://example.com/page/اما همان محتوا با یک پارامتر Tracking نیز قابل دسترسی باشد:
https://example.com/page/?utm_source=instagramاگر این پارامتر فقط برای Tracking باشد و محتوای اصلی صفحه را تغییر ندهد، می‌توان URL اصلی را به‌عنوان نسخه ترجیحی معرفی کرد:
<link rel="canonical" href="https://example.com/page/">به زبان ساده، Canonical به موتور جستجو می‌گوید:
«از میان URLهای مشابه، این آدرس را به‌عنوان نسخه ترجیحی محتوا در نظر بگیر.»
اما Canonical صفحه دیگر را حذف نمی‌کند، کاربر را Redirect نمی‌کند و به‌تنهایی مانع Crawl شدن URLهای دیگر نیز نمی‌شود.
Canonicalization چیست؟
Canonicalization یا فرایند تعیین URL Canonical، فرایندی است که در آن موتور جستجو از میان چند URL تکراری یا بسیار مشابه، یک URL را به‌عنوان نسخه نماینده محتوا انتخاب می‌کند.
برای مثال، اگر این چهار URL تقریباً یک محتوا را نمایش دهند:
https://example.com/product/
https://example.com/product/?utm_source=instagram
https://example.com/product/?utm_source=telegram
https://example.com/product/?sort=priceموتور جستجو باید تشخیص دهد آیا این URLها صفحات مستقل هستند یا نسخه‌های مختلف یک محتوا.
Google در فرایند Canonicalization صفحات مشابه را بررسی و در صورت تشخیص شباهت زیاد، آن‌ها را در یک مجموعه قرار می‌دهد و با استفاده از سیگنال‌های مختلف URL نماینده را انتخاب می‌کند. rel=”canonical” یکی از این سیگنال‌هاست، اما تنها عامل نیست.
چرا به Canonical نیاز داریم؟
ایجاد چند URL برای یک محتوا در سایت‌ها بسیار رایج است و لزوماً نتیجه یک اشتباه عمدی نیست.
برای مثال، یک فروشگاه اینترنتی ممکن است برای یک دسته محصولات URLهایی مانند موارد زیر ایجاد کند:
- URL اصلی دسته
- URL دارای پارامتر Tracking
- URL فیلتر شده بر اساس رنگ
- URL فیلتر شده بر اساس اندازه
- URL مرتب‌سازی محصولات
- ترکیبی از چند فیلتر
همچنین نسخه‌های مختلف HTTP و HTTPS، www و non-www یا برخی ساختارهای ایجادشده توسط CMS می‌توانند باعث ایجاد URLهای مشابه شوند.
Google نیز فیلتر و مرتب‌سازی صفحات، تفاوت پروتکل و برخی نسخه‌های مختلف URL را از نمونه‌های رایج ایجاد محتوای تکراری می‌داند.
نکته مهم این است که Duplicate Content به‌خودی‌خود به معنی جریمه شدن سایت نیست. مسئله اصلی این است که وجود تعداد زیادی URL مشابه می‌تواند تشخیص نسخه نماینده، مدیریت ایندکس و تحلیل عملکرد صفحات را پیچیده‌تر کند.
تگ Canonical چه کاربردی در سئو دارد؟
مهم‌ترین کاربرد Canonical، اعلام URL ترجیحی در میان صفحات تکراری یا بسیار مشابه است. اما استفاده صحیح از آن چند مزیت فنی مهم دارد.
۱. مشخص کردن URL ترجیحی
اگر چند URL تقریباً یک محتوا را نمایش می‌دهند، Canonical ترجیح سایت را درباره URL نماینده مشخص می‌کند.
۲. کمک به تجمیع سیگنال‌های صفحات مشابه
Canonical می‌تواند به موتور جستجو کمک کند رابطه میان نسخه‌های مشابه را بهتر درک کند و سیگنال‌های مرتبط با یک محتوا را در ارتباط با نسخه ترجیحی تفسیر کند.
۳. کاهش ابهام در معماری URL
اگر Canonical، Sitemap و لینک‌های داخلی همگی یک URL را به‌عنوان نسخه اصلی معرفی کنند، سیگنال‌های فنی سایت هماهنگ‌تر خواهند بود.
۴. مدیریت URLهای مشابه در سایت‌های بزرگ
در فروشگاه‌ها و سایت‌هایی که تعداد زیادی URL از طریق فیلتر، Sort یا پارامتر ایجاد می‌شود، Canonical می‌تواند بخشی از استراتژی مدیریت URLهای مشابه باشد؛ البته مشکل تولید بی‌رویه URL را به‌تنهایی حل نمی‌کند.
یک مثال ساده برای درک Canonical
فرض کنید صفحه محصول شما این URL را دارد:
https://example.com/product/mobile/کاربری از یک کمپین تبلیغاتی وارد همان صفحه می‌شود و URL به شکل زیر باز می‌شود:
https://example.com/product/mobile/?utm_source=telegramاگر پارامتر فقط برای Tracking باشد و محتوای صفحه را تغییر ندهد، URL اصلی می‌تواند نسخه ترجیحی باشد:
<link rel="canonical" href="https://example.com/product/mobile/">در این حالت URL دارای پارامتر همچنان ممکن است برای کاربر قابل دسترسی باشد، اما سایت ترجیح خود را درباره URL نماینده مشخص کرده است.
آیا Canonical یک دستور قطعی برای گوگل است؟
خیر.
یکی از مهم‌ترین نکاتی که در آموزش Canonical باید به آن توجه کرد این است که rel="canonical" یک سیگنال یا Hint است، نه یک دستور غیرقابل تغییر.
گوگل در کنار Canonical، سیگنال‌هایی مانند Redirect، URLهای موجود در Sitemap، پروتکل HTTP/HTTPS، لینک‌های داخلی و میزان شباهت و کیفیت محتوا را نیز بررسی می‌کند. بنابراین ممکن است URLی را که سایت به‌عنوان Canonical معرفی کرده است، نپذیرد و URL دیگری را انتخاب کند.
برای مثال اگر صفحه A به B Canonical شده باشد اما بیشتر لینک‌های داخلی، Sitemap و Redirectهای سایت به C اشاره کنند، سیگنال‌های سایت با یکدیگر هماهنگ نیستند.
در چنین شرایطی صرفاً تغییر تگ Canonical کافی نیست و باید کل مجموعه سیگنال‌ها بررسی شود.
User-declared Canonical و Google-selected Canonical چیست؟
در Google Search Console ممکن است با دو مفهوم مهم روبه‌رو شوید:
User-declared Canonical
URLای است که سایت شما به‌عنوان URL ترجیحی معرفی کرده است.
User-declared Canonical:
https://example.com/page-a/Google-selected Canonical
URLای است که Google پس از بررسی مجموعه سیگنال‌های موجود، آن را به‌عنوان نسخه نماینده انتخاب کرده است.
Google-selected Canonical:
https://example.com/page-b/اگر این دو URL متفاوت باشند، الزاماً به معنی وجود یک خطای فنی قطعی نیست؛ اما اگر شما انتظار دارید A نسخه اصلی باشد، باید دلیل انتخاب B را بررسی کنید.
Canonical را کجا قرار می‌دهیم؟
Canonical در حالت معمول باید در بخش <head> سند HTML قرار بگیرد:
<head>
<title>عنوان صفحه</title>
<link rel="canonical" href="https://example.com/page/">
</head>بهتر است URL داخل href به‌صورت کامل یا Absolute URL نوشته شود:
<link rel="canonical" href="https://example.com/page/">و نه:
<link rel="canonical" href="/page/">همچنین مقصد Canonical باید URL نهایی و معتبر باشد و بهتر است مستقیماً به صفحه ترجیحی اشاره کند؛ نه اینکه خود آن URL Redirect شود یا خطای 404 داشته باشد.
Self-Referencing Canonical چیست؟
وقتی یک صفحه Canonical خود را به خودش اختصاص می‌دهد، با Self-Referencing Canonical روبه‌رو هستیم.
فرض کنید URL اصلی صفحه این باشد:
https://example.com/seo/Canonical همان صفحه می‌تواند چنین باشد:
<link rel="canonical" href="https://example.com/seo/">Self-referencing Canonical الزام مطلق برای تمام صفحات نیست، اما در صفحات قابل ایندکس می‌تواند ترجیح URL اصلی را به شکل واضح‌تری مشخص کند و برای جلوگیری از ابهام ناشی از پارامترها و نسخه‌های URL مفید باشد.
مهم‌تر از وجود این تگ، درست بودن URL داخل آن و هماهنگی آن با سایر سیگنال‌های سایت است.
چه صفحاتی معمولاً به Canonical نیاز دارند؟
Canonical را نباید مانند یک قانون ثابت روی تمام صفحات سایت اعمال کرد. ابتدا باید رابطه میان URLها و هدف هر صفحه مشخص شود.
سناریوهای رایج عبارت‌اند از:
- URLهای دارای پارامترهای Tracking
- برخی URLهای فیلتر و Faceted Navigation
- صفحات مرتب‌سازی
- نسخه‌های بسیار مشابه یک محصول
- برخی نسخه‌های مختلف URL یک محتوا
- صفحات مشابهی که یک URL مشخص باید نماینده آن‌ها باشد
در مقابل، اگر دو صفحه واقعاً هدف جستجوی متفاوتی دارند، صرفاً مشابه بودن موضوع آن‌ها دلیل مناسبی برای Canonical کردن یکی به دیگری نیست.
Canonical در URLهای پارامتری
یکی از رایج‌ترین کاربردهای Canonical مربوط به Query Parameterهاست.
https://example.com/product/
https://example.com/product/?utm_source=google
https://example.com/product/?utm_campaign=springاگر پارامترها فقط برای Tracking باشند و محتوای صفحه را تغییر ندهند، معمولاً URL بدون پارامتر می‌تواند نسخه ترجیحی باشد.
اما همه پارامترها یکسان نیستند. برای مثال، پارامتری که واقعاً مجموعه محصولات یا محتوای صفحه را تغییر می‌دهد باید جداگانه بررسی شود.
به همین دلیل نباید یک Rule ساده ایجاد کرد که «هر URL دارای Query String را به URL اصلی Canonical کن».
Canonical در فروشگاه اینترنتی
فروشگاه‌های اینترنتی یکی از مهم‌ترین محیط‌های استفاده از Canonical هستند؛ زیرا فیلتر، مرتب‌سازی و انتخاب ویژگی‌های محصول می‌تواند تعداد زیادی URL ایجاد کند.
https://example.com/shoes/
https://example.com/shoes/?color=red
https://example.com/shoes/?color=red&size=42
https://example.com/shoes/?color=red&size=42&sort=priceاما در اینجا یک نکته بسیار مهم وجود دارد:
هر صفحه فیلترشده الزاماً Duplicate نیست.
مثال: صفحه «کفش نایک»
فرض کنید فروشگاه یک صفحه اختصاصی برای «کفش نایک» ایجاد کرده است. این صفحه محصولات مشخص، عنوان، محتوای اختصاصی و هدف جستجوی مستقلی دارد.
نباید صرفاً به دلیل اینکه این صفحه از نظر فنی نوعی Filter Page محسوب می‌شود، آن را به دسته عمومی «کفش» Canonical کنیم.
در مقابل، URL موقتی زیر:
?color=red&size=41&sort=priceممکن است صرفاً ترکیبی از انتخاب‌های کاربر باشد و ارزش جستجوی مستقلی نداشته باشد.
بنابراین سؤال درست این نیست:
«آیا این صفحه فیلتر است؟»
بلکه باید پرسید:
«آیا این URL واقعاً یک نیاز جستجوی مستقل را پاسخ می‌دهد؟»
Canonical صفحات مرتب‌سازی
برخی فروشگاه‌ها برای مرتب‌سازی محصولات URLهایی مانند موارد زیر ایجاد می‌کنند:
/category/?sort=price
/category/?sort=newestاگر این URLها فقط ترتیب نمایش محصولات را تغییر می‌دهند و قرار نیست صفحات مستقلی برای جستجو باشند، می‌توان آن‌ها را در معماری فنی سایت مدیریت کرد و در شرایط مناسب URL اصلی دسته را به‌عنوان نسخه ترجیحی معرفی کرد.
اما اگر یک URL مرتب‌شده واقعاً محتوای متفاوت و هدف جستجوی مشخصی دارد، نباید بدون بررسی آن را Duplicate فرض کرد.
Canonical صفحات جستجوی داخلی سایت
فرض کنید سایت URLهایی مانند این ایجاد می‌کند:
https://example.com/search/?q=seoصفحات جستجوی داخلی معمولاً قرار نیست مانند یک Landing Page مستقل در نتایج جستجوی گوگل حضور داشته باشند. اما Canonical راه‌حل خودکار برای همه مشکلات این صفحات نیست.
ابتدا باید مشخص شود:
- آیا این صفحات ارزش ایندکس شدن دارند؟
- آیا باید توسط موتور جستجو Crawl شوند؟
- آیا تولید بی‌رویه آن‌ها باید در معماری سایت کنترل شود؟
- آیا برای برخی URLها Noindex یا راهکار دیگری مناسب‌تر است؟
تفاوت Canonical و Redirect 301 چیست؟
Canonical و Redirect 301 هر دو می‌توانند در مدیریت URLها استفاده شوند، اما کاربرد یکسانی ندارند.
| Canonical | Redirect 301 |
|---|---|
| نسخه ترجیحی یک محتوا را معرفی می‌کند | کاربر و خزنده را به URL دیگری منتقل می‌کند |
| URL مبدا معمولاً همچنان قابل دسترسی است | URL مبدا به مقصد منتقل می‌شود |
| برای URLهای مشابه کاربرد دارد | برای جایگزینی دائمی URL مناسب است |
برای مثال اگر URL قدیمی سایت:
https://example.com/old-page/برای همیشه با این URL جایگزین شده است:
https://example.com/new-page/در چنین شرایطی Redirect دائمی معمولاً راهکار مناسب‌تری است؛ زیرا URL قدیمی دیگر قرار نیست یک نسخه مستقل از محتوا باشد.
تفاوت Canonical و Noindex چیست؟
این دو مفهوم نیز نباید با یکدیگر اشتباه گرفته شوند.
Canonical می‌گوید:
«از میان این URLهای مشابه، این URL نسخه ترجیحی است.»
Noindex می‌گوید:
«این صفحه را در نتایج جستجو Index نکن.»
بنابراین اگر مشکل شما این است که یک URL نباید در نتایج جستجو حضور داشته باشد، صرفاً Canonical کردن آن همیشه راهکار مناسب نیست.
تفاوت Canonical و Robots.txt چیست؟
robots.txt ابزار مدیریت دسترسی خزنده به مسیرهای سایت است و نباید به‌عنوان جایگزین Canonical استفاده شود.
اگر URL را در robots.txt مسدود کنید، ممکن است Google نتواند صفحه را Crawl کند و در نتیجه نتواند Canonical موجود در HTML آن را نیز ببیند.
پس هر ابزار مسئله متفاوتی را حل می‌کند:
- Canonical: معرفی URL ترجیحی
- 301: انتقال دائمی URL
- Noindex: جلوگیری از ایندکس صفحه
- Robots.txt: مدیریت Crawl مسیرها
Canonical صفحات Pagination؛ آیا همه صفحات باید به صفحه اول Canonical شوند؟
خیر.
فرض کنید یک دسته‌بندی چند صفحه دارد:
/category/
/category/page/2/
/category/page/3/صفحه دوم ممکن است محصولات یا مقالات متفاوتی نسبت به صفحه اول داشته باشد. بنابراین نباید فقط به دلیل Pagination، آن را به صفحه اول کنونیکال کرد.
هر صفحه باید بر اساس نقش واقعی خود در معماری سایت بررسی شود.
Canonical و صفحات چندزبانه
یکی از اشتباهات رایج این است که صفحات زبان‌های مختلف به یک URL Canonical شوند.
اگر یک سایت نسخه فارسی، انگلیسی و آلمانی یک محتوا را در URLهای جداگانه ارائه می‌کند، این صفحات صرفاً به دلیل ترجمه شدن نباید همگی به نسخه یک زبان Canonical شوند.
در سایت‌های چندزبانه و چندمنطقه‌ای، Canonical و hreflang وظایف متفاوتی دارند و باید در کنار ساختار صحیح URL استفاده شوند. گوگل نیز برای نسخه‌های منطقه‌ای مشابه، استفاده هماهنگ از کنونیکال و hreflang را توصیه می‌کند.
Canonical و محتوای مشابه؛ چه زمانی ادغام محتوا بهتر است؟
گاهی دو صفحه آن‌قدر به یکدیگر نزدیک هستند که بهتر است اصلاً دو صفحه مستقل باقی نمانند.
برای مثال ممکن است دو مقاله با موضوع‌های بسیار نزدیک داشته باشید:
- آموزش سئو داخلی
- راهنمای کامل سئو داخلی سایت
اگر هر دو صفحه تقریباً یک هدف، محتوای مشابه و ارزش یکسان دارند، ادغام محتوا و انتقال URL قدیمی به نسخه نهایی می‌تواند راهکار منطقی‌تری نسبت به Canonical کردن دائمی یکی به دیگری باشد.
بنابراین قبل از کنونیکال کردن دو صفحه، این سؤال را بپرسید:
«آیا این دو URL واقعاً باید دو صفحه مستقل برای کاربران باشند؟»
Canonical و محتوای منتشرشده در سایت‌های دیگر
اگر مقاله شما در سایت دیگری نیز منتشر شده است، Canonical لزوماً راهکار مطمئنی برای کنترل Duplicate Content میان دو سایت نیست.
در محتوای Syndicated، باید شرایط انتشار، میزان تفاوت صفحات، سیاست ایندکس سایت منتشرکننده و هدف هر صفحه بررسی شود. بنابراین نمی‌توان برای تمام رپورتاژها یا محتوای بازنشرشده یک Rule ثابت Canonical تعریف کرد.
آیا Canonical روی Crawl Budget تأثیر دارد؟
Canonical می‌تواند در مدیریت مجموعه‌ای از URLهای مشابه نقش داشته باشد. Google توضیح می‌دهد که در یک مجموعه صفحات تکراری، صفحه Canonical معمولاً بیشتر از نسخه‌های تکراری Crawl می‌شود.
اما این به معنی آن نیست که با اضافه کردن Canonical به تعداد زیادی URL، مشکل Crawl Budget خودکار حل می‌شود.
اگر یک فروشگاه میلیون‌ها URL غیرضروری به دلیل فیلتر، پارامتر یا لینک‌سازی داخلی تولید می‌کند، باید علت تولید URLهای اضافی نیز اصلاح شود.
برای آشنایی بیشتر با این موضوع می‌توانید راهنمای بودجه خزش (Crawl Budget) را نیز مطالعه کنید.
Canonical در WordPress چگونه تنظیم می‌شود؟
در WordPress و بسیاری از CMSها، Canonical صفحات به‌صورت خودکار تولید می‌شود و افزونه‌های سئو نیز معمولاً امکان مدیریت آن را فراهم می‌کنند.
بنابراین در بیشتر پروژه‌ها لازم نیست برای تک‌تک صفحات به‌صورت دستی این کد را وارد کنید.
مهم‌تر این است که بررسی کنید Canonical خودکار دقیقاً چه URLای تولید می‌کند.
در WordPress چه زمانی باید Canonical را تغییر دهیم؟
اگر Canonical تولیدشده صحیح است، تغییر دستی آن ضرورتی ندارد. اما اگر افزونه، قالب یا تنظیمات سایت URL اشتباهی تولید می‌کنند، باید علت اصلی مشکل پیدا و اصلاح شود.
برای مثال اگر افزونه SEO به‌درستی Canonical را تولید می‌کند اما قالب نیز یک کنونیکال دوم اضافه می‌کند، بهتر است یکی از منابع تولید تگ حذف شود.
چگونه Canonical واقعی یک صفحه را بررسی کنیم؟
فقط به تنظیمات افزونه SEO اعتماد نکنید. خروجی HTML نهایی صفحه را نیز بررسی کنید.
- صفحه موردنظر را در مرورگر باز کنید.
- روی صفحه کلیک راست کنید.
- گزینه View Page Source را انتخاب کنید.
- عبارت
canonicalرا جستجو کنید. - URL داخل
hrefرا بررسی کنید.
باید چیزی شبیه این مشاهده کنید:
<link rel="canonical" href="https://example.com/page/">اگر بیش از یک کنونیکال در HTML وجود دارد، باید مشخص شود کدام افزونه، قالب یا کد سفارشی آن را تولید کرده است.
Canonical و JavaScript؛ نکته مهم برای سایت‌های مدرن
در سایت‌هایی که بخش‌هایی از HTML با JavaScript ساخته یا تغییر داده می‌شوند، Canonical باید با دقت بیشتری بررسی شود.
بهترین حالت این است که Canonical صحیح در HTML اولیه صفحه وجود داشته باشد و JavaScript آن را به URL دیگری تغییر ندهد. Google در مستندات جدید خود نیز درباره Canonicalization در سایت‌های JavaScript بر ثبات URL Canonical میان HTML اولیه و فرایند Render تأکید کرده است.
این موضوع برای پروژه‌های React، Vue، Next.js و سایر سایت‌های JavaScript-heavy اهمیت بیشتری دارد.
Canonical در PDF و فایل‌های غیر HTML
Canonical فقط برای صفحات HTML نیست. در برخی سناریوها می‌توان برای فایل‌هایی مانند PDF از HTTP Link Header با rel="canonical" استفاده کرد.
برای مثال:
Link: <https://example.com/guide/>; rel="canonical"اما استفاده از این قابلیت باید بر اساس معماری واقعی محتوا انجام شود. اگر PDF و صفحه HTML هر دو ارزش مستقل برای کاربر دارند، نباید صرفاً به دلیل یکسان بودن موضوع، PDF را Canonical به HTML کرد.
Canonical به URL 404؛ چرا اشتباه است؟
فرض کنید صفحه A چنین Canonicalای دارد:
<link rel="canonical" href="https://example.com/product-b/">اما product-b دیگر وجود ندارد و سرور پاسخ 404 برمی‌گرداند.
در این حالت Canonical به یک URL نامعتبر اشاره می‌کند. مقصد Canonical باید واقعاً نسخه ترجیحی و قابل دسترسی محتوا باشد.
Canonical به URL Redirect شده
فرض کنید:
/page-a/
↓
301
↓
/page-b/اگر page-b نسخه نهایی و ترجیحی است، بهتر است Canonical مستقیماً به B اشاره کند:
<link rel="canonical" href="https://example.com/page-b/">این کار سیگنال‌های فنی را ساده‌تر و قابل‌فهم‌تر می‌کند.
چند Canonical در یک صفحه؛ آیا درست است؟
بهتر است هر صفحه یک Canonical روشن و مشخص داشته باشد.
مثلاً این وضعیت مناسب نیست:
<link rel="canonical" href="https://example.com/a/">
<link rel="canonical" href="https://example.com/b/">وجود چند Canonical با مقصدهای متفاوت می‌تواند سیگنال متناقض ایجاد کند. این مشکل معمولاً زمانی رخ می‌دهد که دو افزونه SEO یا قالب و افزونه به‌صورت هم‌زمان Canonical تولید کنند.
Canonical Loop چیست؟
Canonical Loop زمانی رخ می‌دهد که صفحات به شکل دوری به یکدیگر اشاره کنند.
A → B
B → Aدر این شرایط ترجیح روشنی وجود ندارد.
همچنین بهتر است از Canonical Chain مانند زیر جلوگیری شود:
A → B
B → Cاگر C نسخه نهایی است، بهتر است A مستقیماً به C اشاره کند.
اگر Google Canonical دیگری انتخاب کرد چه کنیم؟
اگر شما URL A را Canonical اعلام کرده‌اید اما Google URL B را انتخاب کرده است، ابتدا باید علت اختلاف را پیدا کنید.
- URL انتخاب‌شده توسط Google را در Search Console بررسی کنید.
- محتوای A و B را با یکدیگر مقایسه کنید.
- Canonical هر دو صفحه را بررسی کنید.
- Redirectهای هر دو URL را بررسی کنید.
- وضعیت HTTP و HTTPS را بررسی کنید.
- Sitemap را بررسی کنید.
- لینک‌های داخلی را بررسی کنید.
- پارامترهای URL و فیلترها را بررسی کنید.
- در سایت چندزبانه، hreflang را بررسی کنید.
- در سایت‌های JavaScript، HTML اولیه و خروجی Render شده را بررسی کنید.
Google نیز برای عیب‌یابی Canonical پیشنهاد می‌کند ابتدا URL انتخاب‌شده توسط Google را با ابزار URL Inspection بررسی کرده و سپس سیگنال‌های فنی و محتوایی صفحات را ارزیابی کنید.
تغییر مداوم Canonical بدون پیدا کردن علت اصلی معمولاً راهکار مناسبی نیست. اگر لینک‌های داخلی، Sitemap یا ساختار URL همچنان نسخه دیگری را ترجیح دهند، تنها تغییر یک تگ ممکن است مشکل را حل نکند.
Canonical و محتوای مشابه؛ چه زمانی Canonical نکنیم؟
گاهی مشکل شما اصلاً Canonical نیست.
- اگر یک URL برای همیشه با URL دیگری جایگزین شده است، Redirect دائمی را بررسی کنید.
- اگر صفحه نباید در نتایج جستجو حضور داشته باشد، Noindex را بررسی کنید.
- اگر دو صفحه هدف جستجوی متفاوت دارند، آن‌ها را فقط به دلیل شباهت موضوعی Canonical نکنید.
- اگر صفحه باید حذف شود، وضعیت HTTP مناسب و حذف واقعی URL را بررسی کنید.
- اگر مشکل از تولید بی‌رویه URLهای فیلتر است، معماری Faceted Navigation را اصلاح کنید.
بنابراین قبل از اضافه کردن Canonical ابتدا مشخص کنید:
«دقیقاً چه مشکلی را می‌خواهم با این تگ حل کنم؟»
آیا Canonical باعث افزایش مستقیم رتبه می‌شود؟
خیر.
Canonical یک تکنیک مستقیم برای افزایش رتبه نیست. هدف آن کمک به موتور جستجو برای درک رابطه میان URLهای مشابه و شناسایی نسخه نماینده است.
اگر سایت شما URLهای تکراری یا بسیار مشابه دارد، Canonical صحیح می‌تواند به سازمان‌دهی بهتر سیگنال‌های فنی کمک کند؛ اما نباید انتظار داشت صرفاً با اضافه کردن این تگ، رتبه یک صفحه افزایش پیدا کند.
آیا Canonical باعث حذف URL تکراری می‌شود؟
خیر. Canonical URL دیگر را حذف نمی‌کند و کاربر را نیز به URL مقصد منتقل نمی‌کند.
اگر هدف شما حذف دسترسی به URL قدیمی است، باید راهکار مناسب مانند ریدایرکت یا حذف واقعی صفحه را بررسی کنید.
آیا Canonical برای همه صفحات سایت لازم است؟
خیر. وجود یا نبود Canonical باید بخشی از معماری URL سایت باشد.
در بسیاری از سایت‌ها Self-referencing Canonical برای صفحات اصلی و قابل ایندکس استفاده می‌شود، اما مهم‌تر از اینکه «همه صفحات حتماً تگ داشته باشند»، این است که URL ترجیحی سایت به شکل واضح و سازگار مشخص باشد.
چک‌لیست حرفه‌ای بررسی Canonical
| مورد بررسی | وضعیت مطلوب |
|---|---|
| Canonical | صحیح و مشخص |
| URL Canonical | URL کامل و معتبر |
| وضعیت مقصد | URL نهایی و قابل دسترسی |
| Canonical به 404 | نباید وجود داشته باشد |
| Canonical به Redirect | ترجیحاً مستقیم به URL نهایی اشاره شود |
| چند Canonical | نباید وجود داشته باشد |
| Canonical همه صفحات به Home | نباید انجام شود |
| Sitemap | هماهنگ با URLهای ترجیحی |
| Internal Links | ترجیحاً به URL اصلی اشاره کنند |
| HTTP/HTTPS | نسخه اصلی مشخص و هماهنگ |
| فیلترها | بر اساس Search Intent و معماری سایت مدیریت شوند |
| Pagination | بدون Canonical اشتباه به صفحه اول |
| چندزبانه | هماهنگ با hreflang |
| Google-selected Canonical | در Search Console بررسی شود |
آموزش بررسی Canonical در Google Search Console
برای بررسی وضعیت Canonical یک URL، از ابزار URL Inspection در Google Search Console استفاده کنید.
- URL موردنظر را در Search Console وارد کنید.
- اطلاعات Indexing را بررسی کنید.
- User-declared Canonical را مشاهده کنید.
- Google-selected Canonical را بررسی کنید.
- اگر این دو URL متفاوت هستند، علت اختلاف را بررسی کنید.
اگر Canonical اعلام‌شده و Canonical انتخاب‌شده یکسان باشند، این بخش از سیگنال‌های Canonical سایت با انتخاب Google هماهنگ است.
اگر متفاوت باشند، ابتدا Redirect، نقشه سایت، لینک‌های داخلی، وضعیت URL، شباهت محتوا و تنظیمات فنی را بررسی کنید. تغییر Canonical باید آخرین مرحله یک فرایند عیب‌یابی باشد، نه اولین واکنش.
یک سناریوی کامل Canonical در فروشگاه اینترنتی
فرض کنید یک فروشگاه کفش دارید و صفحه اصلی دسته این URL است:
https://example.com/shoes/چند URL دیگر نیز ایجاد شده‌اند:
https://example.com/shoes/?color=black
https://example.com/shoes/?size=42
https://example.com/shoes/?color=black&size=42
https://example.com/shoes/?color=black&size=42&sort=priceدر اینجا نباید بدون بررسی همه URLها را یکجا Canonical کنیم.
ابتدا باید بررسی شود آیا عبارتی مانند «کفش مشکی» یا «کفش سایز ۴۲» برای سایت Search Intent ارزشمندی ایجاد می‌کند یا خیر.
اگر یک ترکیب فیلتر ارزش جستجوی واقعی داشته باشد، ممکن است بهتر باشد یک Landing Page مستقل با URL، محتوا و معماری مشخص ایجاد شود.
اما اگر URL صرفاً ترکیبی موقتی از انتخاب‌های کاربر باشد و ارزش مستقلی نداشته باشد، Canonical کردن آن به صفحه مناسب‌تر می‌تواند بخشی از راهکار باشد.
این مثال نشان می‌دهد که Canonical فقط یک موضوع HTML نیست؛ بلکه با معماری سایت، Search Intent، ساختار URL و استراتژی ایندکس ارتباط دارد.
Canonical چه ارتباطی با سئوی تکنیکال دارد؟
Canonical یکی از اجزای سئوی تکنیکال است، اما به‌تنهایی یک سیستم مستقل نیست.
در یک Audit حرفه‌ای بهتر است Canonical در کنار موارد زیر بررسی شود:
- ساختار URL
- Redirectها
- HTTP Status Code
- Sitemap
- لینک‌های داخلی
- HTTPS
- hreflang
- Pagination
- فیلترهای فروشگاهی
- پارامترهای URL
- JavaScript Rendering
به عبارت دیگر، اگر معماری URL سایت مشکل داشته باشد، Canonical نمی‌تواند به‌تنهایی تمام مشکلات را برطرف کند.
بهترین روش استفاده از Canonical چیست؟
۱. ابتدا URL ترجیحی را مشخص کنید
قبل از نوشتن Canonical باید بدانید کدام URL واقعاً باید نماینده محتوا باشد.
۲. مقصد را بررسی کنید
Canonical باید به URL معتبر و ترجیحی اشاره کند؛ نه یک صفحه 404، Redirect شده یا صفحه‌ای با محتوای نامرتبط.
۳. Sitemap را هماهنگ کنید
اگر A نسخه اصلی است، تا حد امکان Sitemap نیز A را معرفی کند.
۴. لینک‌های داخلی را هماهنگ کنید
اگر نسخه اصلی A است، لینک‌های داخلی نیز بهتر است مستقیماً به A اشاره کنند و دائماً کاربران و خزنده‌ها را به نسخه‌های دیگر نفرستند.
۵. Canonical را با Redirect و Noindex اشتباه نگیرید
هرکدام از این ابزارها مسئله متفاوتی را حل می‌کنند.
۶. Search Intent صفحات را بررسی کنید
خصوصاً در فروشگاه‌ها، هر URL فیلترشده الزاماً Duplicate نیست. اگر صفحه واقعاً نیاز جستجوی مستقلی را پاسخ می‌دهد، ممکن است به یک Landing Page مستقل نیاز داشته باشد.
سؤالات متداول درباره تگ کنونیکال
تگ Canonical چیست؟
Canonical یک عنصر HTML با rel="canonical" است که ترجیح سایت درباره URL نماینده یک محتوای تکراری یا بسیار مشابه را به موتورهای جستجو اعلام می‌کند.
آیا Canonical باعث حذف URL تکراری می‌شود؟
خیر. Canonical URL را حذف یا Redirect نمی‌کند؛ بلکه نسخه ترجیحی محتوا را معرفی می‌کند.
آیا Canonical دستور قطعی گوگل است؟
خیر. Canonical یک سیگنال است و Google می‌تواند با توجه به سایر سیگنال‌های فنی و محتوایی URL دیگری را انتخاب کند.
آیا همه صفحات باید Self-Referencing Canonical داشته باشند؟
الزام مطلقی برای همه صفحات وجود ندارد، اما Self-referencing Canonical در بسیاری از صفحات قابل ایندکس می‌تواند ترجیح URL اصلی را شفاف‌تر کند.
آیا Canonical و 301 جایگزین یکدیگر هستند؟
خیر. اگر URL قدیمی برای همیشه با URL جدید جایگزین شده است، Redirect دائمی معمولاً راهکار مناسب‌تری است. Canonical برای معرفی نسخه ترجیحی میان URLهای مشابه کاربرد دارد.
آیا Canonical باعث افزایش رتبه می‌شود؟
به‌صورت مستقیم خیر. Canonical برای مدیریت URLهای مشابه و کمک به تشخیص نسخه نماینده استفاده می‌شود.
آیا صفحات فیلتر باید همیشه Canonical شوند؟
خیر. ابتدا باید مشخص شود صفحه فیلترشده آیا Search Intent مستقل و ارزش محتوایی دارد یا صرفاً یک ترکیب موقتی از انتخاب‌های کاربر است.
اگر Google-selected Canonical با Canonical سایت متفاوت باشد چه کنیم؟
ابتدا علت اختلاف را بررسی کنید. Canonical، Redirect، Sitemap، لینک‌های داخلی، HTTPS، ساختار URL و شباهت محتوا را بررسی کنید و سپس در صورت نیاز Canonical را اصلاح کنید. Google نیز استفاده از URL Inspection برای بررسی Canonical انتخاب‌شده را توصیه می‌کند.
آیا می‌توان Canonical را به صفحه Home سایت قرار داد؟
صرفاً به این دلیل که صفحه Home مهم‌تر است، خیر. مقصد کنونیکال باید واقعاً نسخه نماینده یا ترجیحی محتوای موردنظر باشد.
آیا Canonical برای صفحات Pagination باید به صفحه اول اشاره کند؟
خیر. صفحات Pagination ممکن است محتوای متفاوتی داشته باشند و نباید صرفاً به دلیل شماره صفحه به صفحه اول کنونیکال شوند.
آیا Canonical در وردپرس باید دستی نوشته شود؟
در بیشتر سایت‌های WordPress، افزونه SEO یا خود CMS می‌تواند Canonical را تولید کند. بهتر است ابتدا خروجی HTML را بررسی کنید و فقط در صورت وجود مشکل، تنظیمات Canonical را تغییر دهید.
جمع‌بندی؛ تگ کنونیکال چیست و چگونه باید از آن استفاده کنیم؟
تگ کنونیکال یک عنصر HTML برای معرفی URL ترجیحی یک محتوا در میان URLهای تکراری یا بسیار مشابه است:
<link rel="canonical" href="https://example.com/page/">اما استفاده حرفه‌ای از Canonical فقط نوشتن همین یک خط کد نیست. باید مشخص شود:
- کدام URL واقعاً نسخه اصلی است؟
- آیا صفحات واقعاً Duplicate یا بسیار مشابه هستند؟
- آیا صفحه دیگری Search Intent مستقل دارد؟
- آیا مقصد Canonical معتبر و نهایی است؟
- آیا Sitemap و لینک‌های داخلی همان URL را ترجیح می‌دهند؟
- آیا Redirect یا Noindex با Canonical تعارض ایجاد نمی‌کند؟
- آیا Google همان URL را به‌عنوان Canonical انتخاب کرده است؟
همچنین نباید Canonical را با 301، Noindex یا robots.txt اشتباه گرفت. هرکدام از این ابزارها برای مسئله متفاوتی طراحی شده‌اند.
در سایت‌های فروشگاهی نیز مهم است که هر URL فیلترشده را به‌صورت خودکار کنونیکال نکنیم؛ زیرا برخی صفحات فیلتر ممکن است ارزش جستجویی مستقل داشته باشند و بهتر باشد به‌عنوان Landing Page اختصاصی توسعه پیدا کنند.
در نهایت، بهترین نتیجه زمانی به دست می‌آید که Canonical با Sitemap، لینک‌های داخلی، Redirectها، HTTPS، hreflang، ساختار URL و محتوای واقعی صفحات هماهنگ باشد. گوگل نیز تأکید می‌کند که Canonical انتخابی سایت فقط یک سیگنال است و ممکن است Google با توجه به مجموعه سیگنال‌های موجود URL دیگری را به‌عنوان نسخه نماینده انتخاب کند.
در پروژه‌های طراحی سایت، سئو و پشتیبانی سایت پرشیا وب نیز بررسی Canonical باید بخشی از Audit فنی باشد؛ زیرا سئوی موفق فقط به تولید محتوا و انتخاب کلمه کلیدی محدود نمی‌شود و موتور جستجو باید بتواند ساختار URLها، نسخه ترجیحی صفحات و ارتباط میان آن‌ها را به‌درستی درک کند.
یک اصل ساده را به خاطر بسپارید: Canonical را فقط زمانی استفاده کنید که بدانید دقیقاً کدام URL باید نماینده محتوا باشد و چرا.
