تگ Canonical یا کنونیکال یکی از مهم‌ترین ابزارهای تکنیکال سئو برای مدیریت صفحات مشابه، تکراری و چندنسخه‌ایه. با این تگ به گوگل میگی از بین چند URL مشابه، کدام نسخه را به‌عنوان نسخه اصلی در نظر بگیرد؛ اما حواست باشه، کنونیکال دستور قطعی نیست، یک سیگنال قویه. هشت پا این راهنما را برای سئوکارها، تیم‌های محتوا و مدیر سایت‌هایی نوشته که با خطاهایی مثل Duplicate, Google chose different canonical، Alternate page with proper canonical tag، پارامترهای فیلتر، صفحات تکراری یا URLهای چندنسخه‌ای درگیرند. خلاصه‌اش اینه: Canonical وقتی درست استفاده شود، سیگنالهای صفحات مشابه را منظم‌تر میکند؛ اما وقتی اشتباه پیاده‌سازی شود، می‌تواند صفحه مهم سایت را از ایندکس خارج کند. بله، به همین ترسناکی.
در این راهنمای هشت پا با کاربرد تگ Canonical، انتخاب نسخه اصلی صفحات مشابه و روش تشخیص و رفع خطاهای کنونیکال آشنا می‌شوید.
تگ Canonical چیست؟
تگ Canonical یک قطعه کد HTML است که داخل بخش <head> صفحه قرار می‌گیرد و به موتور جستجو می‌گوید نسخه اصلی یا ترجیحی این محتوا کدام URL است. این تگ معمولاً با فرمت <link rel=”canonical” href=”https://example.com/main-page/” /> نوشته میشود.
کار اصلی تگ کنونیکال اینه که وقتی یک محتوا از چند URL مختلف قابل دسترسه، گوگل بفهمه کدام URL باید نسخه اصلی حساب شود. مثلاً اگر یک محصول با چند مسیر مختلف باز میشود، یا یک مقاله هم با اسلش آخر URL و هم بدون اسلش در دسترسه، Canonical کمک میکند سیگنال‌ها روی نسخه درست جمع شوند.
گوگل در مستندات خودش میگه URL کنونیکال، نماینده اصلی یک گروه از صفحات duplicate است و فرایند Canonicalization کمک میکند گوگل فقط یک نسخه از محتوای تکراری یا بسیار مشابه را در نتایج نشان دهد. این تعریف ساده است، اما اجرای درستش شوخی‌بردار نیست.
نکته: Canonical برای این نیست که صفحه را مخفی کنی. برای اینه که نسخه اصلی را از بین چند نسخه مشابه مشخص کنی. اگر هدفت حذف صفحه از نتایجه، احتمالاً باید درباره noindex، robots.txt، 404 یا ریدایرکت فکر کنی؛ نه اینکه همه‌چیز را با canonical بزنی و امیدوار باشی درست شود.
کنونیکال دقیقاً چه مشکلی را حل میکند؟
کنونیکال مشکل چندنسخه‌ای بودن URLها را مدیریت میکند. وقتی یک محتوای مشابه از چند آدرس مختلف قابل دسترس باشد، گوگل باید تصمیم بگیرد کدام نسخه را ایندکس و نمایش دهد. Canonical به گوگل کمک میکند انتخاب تو را بفهمد و سیگنال‌هایی مثل لینک‌ها را روی نسخه اصلی متمرکزتر کند.
چند سناریوی رایج:
- URL با پارامتر:
مثل example.com/shoes/?color=black و example.com/shoes/. اگر فیلتر رنگ ارزش مستقل سئویی ندارد، ممکنه نسخه اصلی همان دسته‌بندی کفش باشد. - نسخه‌های http و https:
اگر هم http://example.com/page/ و هم https://example.com/page/ باز شوند، نسخه HTTPS باید نسخه اصلی باشد. - URL با اسلش و بدون اسلش:
مثل /seo-guide و /seo-guide/. برای آدم شاید فرق زیادی نکند، اما برای سیستم‌ها دو URL جدا هستند. - محصول در چند دسته‌بندی:
یک محصول ممکنه هم از مسیر /men/shoes/product-a/ باز شود، هم از مسیر /sale/product-a/. باید مشخص باشد نسخه اصلی کدامه. - صفحه چاپی یا نسخه AMP:
بعضی صفحات نسخه جایگزین دارند. Canonical کمک میکند نسخه اصلی محتوا مشخص بماند.
گوگل میگه یکی از مزایای مشخص کردن Canonical اینه که سیگنالهای URLهای مشابه، مثل لینک‌هایی که به آن‌ها داده شده، می‌تونن به URL ترجیحی منتقل و تجمیع شوند. همین‌جا می‌فهمیم کنونیکال فقط بحث «تکراری نبودن» نیست؛ بحث تمرکز سیگنال هم هست.
[LINK: صفحه خدمات تکنیکال سئو و بررسی خطاهای ایندکس هشت پا]
Canonical دستور است یا پیشنهاد؟
Canonical برای گوگل یک سیگنال قوی است، نه دستور قطعی. یعنی تو می‌تونی URL ترجیحی را معرفی کنی، اما گوگل ممکنه اگر سیگنالهای دیگر با آن نخوانند، نسخه دیگری را به‌عنوان canonical انتخاب کند.
اینجا خیلی‌ها اشتباه می‌کنن. فکر می‌کنن وقتی تگ canonical را گذاشتند، گوگل حتماً همان URL را قبول میکند. نه عزیز من، گوگل کورکورانه اطاعت نمیکند. اگر صفحه A به صفحه B کنونیکال بدهد، اما لینک داخلی، Sitemap، محتوای صفحه، ریدایرکت‌ها و سیگنالهای دیگر چیز دیگری بگویند، گوگل ممکنه بگه «مرسی از نظرت، ولی من این یکی رو منطقی‌تر می‌دونم.»
گوگل در مستندات Canonicalization توضیح میده چند عامل در انتخاب کنونیکال نقش دارند؛ از جمله HTTP یا HTTPS بودن، ریدایرکت‌ها، حضور URL در Sitemap و تگ rel=”canonical”. یعنی تگ canonical فقط یکی از سیگنال‌هاست، نه کل ماجرا.
نکته: اگر می‌خوای گوگل canonical تو را جدی‌تر بگیرد، همه سیگنال‌ها باید هم‌جهت باشند. Sitemap، لینک داخلی، hreflang، ریدایرکت، canonical و نسخه URL باید یک حرف بزنند. اگر هرکدام یک چیزی بگن، گوگل هم حق داره گیج بشه.
تگ Canonical کجا قرار می‌گیرد؟
تگ Canonical معمولاً داخل بخش <head> صفحه HTML قرار می‌گیرد. این تگ باید فقط یک‌بار در صفحه بیاد و بهتره URL داخل href به‌صورت کامل و Absolute نوشته شود؛ یعنی شامل پروتکل و دامنه باشد.
نمونه درست:
<link rel=”canonical” href=”https://example.com/seo/canonical-tag/” />
نمونه‌های پرریسک یا اشتباه:
<link rel=”canonical” href=”/seo/canonical-tag/” />
<link rel=”canonical” href=”http://example.com/seo/canonical-tag/” />
<link rel=”canonical” href=”https://example.com/seo/canonical-tag/” />
<link rel=”canonical” href=”https://example.com/seo/another-page/” />
گوگل در راهنمای خودش توصیه میکند برای canonical از URLهای کامل استفاده شود، نه مسیرهای نسبی. چون URL نسبی در بعضی پیاده‌سازی‌ها ممکنه باعث برداشت اشتباه شود، مخصوصاً وقتی نسخه‌های مختلف دامنه یا مسیرهای پیچیده داری.
نکته: یک صفحه، یک canonical. اگر دو تگ canonical در head صفحه داری، نگو «یکی‌ش رو گوگل انتخاب می‌کنه دیگه». این کار سیگنال را خراب میکند. دقیق و تمیز پیاده کن.
Self-referencing Canonical چیست؟
Self-referencing Canonical یعنی هر صفحه قابل ایندکس، خودش را به‌عنوان نسخه اصلی معرفی کند. مثلاً صفحه https://example.com/blog/seo-guide/ داخل خودش canonical بدهد به همان URL.
نمونه:
<link rel=”canonical” href=”https://example.com/blog/seo-guide/” />
این کار برای صفحات اصلی و قابل ایندکس خیلی مفیده، چون به گوگل یک سیگنال شفاف میده که این صفحه نسخه ترجیحی خودش است. مخصوصاً در سایت‌هایی که پارامتر، UTM، Sort، فیلتر یا نسخه‌های URL مختلف دارند، Self canonical می‌تونه از شلوغی سیگنال‌ها کم کند.
گوگل در راهنمای ساختار URL فروشگاهی هم توصیه میکند روی همه صفحات قابل ایندکس از self-referencing canonical استفاده شود و همان URLها در Sitemap قرار بگیرند. این توصیه برای فروشگاه‌ها خیلی مهمه، چون محصولات و دسته‌بندی‌ها معمولاً از چند مسیر مختلف قابل دسترس میشن.
نکته: Self canonical مثل کارت ملی صفحه است. به گوگل میگه «من همینم، نسخه اصلی من همین URLه.» ساده است، اما نبودنش در سایت‌های بزرگ می‌تونه دردسر بسازه.
چه زمانی باید از Canonical استفاده کنیم؟
از Canonical وقتی استفاده کن که چند URL محتوای یکسان یا بسیار مشابه دارند و می‌خوای یک نسخه اصلی برای ایندکس و تجمیع سیگنال‌ها معرفی کنی. کاربرد اصلی آن مدیریت Duplicate یا Near-duplicate URLهاست، نه حذف صفحه‌های بی‌کیفیت یا پنهان کردن محتوای ضعیف.
موارد مناسب برای Canonical:
- URLهای پارامتردار:
مثل فیلتر، Sort، UTM و Session ID. اگر این نسخه‌ها محتوای مستقل ارزشمند ندارند، معمولاً باید به نسخه اصلی canonical شوند. - محصول قابل دسترس از چند مسیر:
اگر یک محصول از چند دسته‌بندی باز میشود، یک URL اصلی برای محصول مشخص کن. - نسخه چاپی مقاله:
صفحه چاپی یا Print Version می‌تواند canonical به مقاله اصلی بدهد. - محتوای مشابه در چند صفحه:
مثلاً صفحه‌ای که فقط کمی در ترتیب محصولات یا نمایش محتوا فرق دارد. - نسخه HTML و PDF یک محتوا:
برای فایل‌های غیر HTML میشه از canonical در HTTP Header استفاده کرد. گوگل هم این روش را برای محتواهایی مثل PDF یا فایل Word توضیح داده. - نسخه‌های http/https یا www/non-www، اگر ریدایرکت کامل ندارند:
البته در این مورد ریدایرکت 301 معمولاً راه‌حل اصلی‌تریه، ولی canonical هم باید هم‌جهت باشد.
نکته: Canonical را برای صفحه‌هایی استفاده کن که واقعاً مشابه‌اند. اگر دو صفحه Intent متفاوت دارند، کنونیکال زدن یکی به دیگری ممکنه صفحه مفید را از رقابت خارج کند.
چه زمانی نباید از Canonical استفاده کنیم؟
از Canonical نباید به‌عنوان جایگزین noindex، robots.txt، حذف صفحه، ریدایرکت یا اصلاح محتوا استفاده کنی. اگر صفحه‌ای واقعاً نباید در نتایج باشد، باید دلیل و ابزار درستش را انتخاب کنی.
مواردی که Canonical معمولاً انتخاب خوبی نیست:
- صفحه کاملاً متفاوت از صفحه مقصد:
مثلاً مقاله «آموزش سئو داخلی» را canonical بدهی به صفحه «خدمات سئو». این دو Intent متفاوت دارند. این کار یعنی صفحه آموزشی را بی‌دلیل ضعیف می‌کنی. - صفحه‌ای که باید حذف شود:
اگر محصول برای همیشه حذف شده و جایگزین مشخص دارد، 301 بهتر از canonical است. - صفحه‌ای که نمی‌خواهی ایندکس شود اما باید Crawl شود:
اینجا noindex ممکنه مناسب‌تر باشد. - صفحه‌ای که با robots.txt بلاک شده:
اگر گوگل نتونه صفحه را Crawl کند، نمی‌تونه تگ canonical داخلش را ببیند. گوگل در مستندات قدیمی‌ترش هم همین نکته را گفته بود که اگر صفحه با robots.txt بلاک شود، crawler نمی‌تواند rel=”canonical” را کشف کند. - صفحات Pagination با محتوای مکمل:
صفحه ۲، ۳ و ۴ یک دسته‌بندی همیشه نباید canonical به صفحه ۱ بدهند. اگر محصولات متفاوت دارند، این کار می‌تواند کشف محصولات را خراب کند. - صفحات شهری یا خدماتی که واقعاً هدف جدا دارند:
اگر «خدمات سئو در تهران» و «خدمات سئو در مشهد» محتوای اختصاصی و بازار جدا دارند، canonical یکی به دیگری معمولاً اشتباهه.
نکته: اگر با canonical می‌خوای مشکل کیفیت محتوا را قایم کنی، نکن. گوگل شاید کوتاه‌مدت گیج شود، ولی مشکل اصلی سایتت حل نمی‌شود.
Canonical با 301 Redirect چه فرقی دارد؟
Canonical به گوگل نسخه ترجیحی را پیشنهاد میکند، اما صفحه مبدا همچنان برای کاربر قابل مشاهده است. 301 Redirect کاربر و موتور جستجو را از URL قدیمی به URL جدید منتقل میکند و برای انتقال دائمی آدرس استفاده میشود.
|
وضعیت |
Canonical |
301 Redirect |
|
کاربر صفحه مبدا را می‌بیند؟ |
بله |
نه، منتقل میشود |
|
سیگنال برای گوگل |
قوی اما پیشنهادی |
قوی‌تر و مستقیم‌تر برای انتقال URL |
|
مناسب برای |
صفحات مشابه که باید باقی بمانند |
URL قدیمی یا حذف‌شده با مقصد مشخص |
|
مثال |
نسخه فیلترشده محصول به دسته اصلی |
URL قدیمی مقاله به URL جدید |
|
ریسک اشتباه |
انتخاب canonical متفاوت توسط گوگل |
انتقال اشتباه و از دست رفتن صفحه |
گوگل میگه برای حذف نسخه‌های duplicate و فرستادن ترافیک به URL ترجیحی، Redirect یکی از روش‌های قابل استفاده است و Sitemap هم راهی برای اعلام URLهای مهم محسوب میشه. یعنی Canonical فقط یکی از ابزارهای Canonicalization است، نه تنها ابزار.
نمونه فرضی: اگر مقاله /old-canonical-guide/ را کامل با مقاله جدید /canonical-tag-guide/ ادغام کردی و دیگر نمی‌خوای URL قدیمی دیده شود، 301 Redirect منطقی‌تره. اما اگر صفحه فیلتر ?color=black باید برای کاربر قابل مشاهده باشد ولی نمی‌خوای نسخه اصلی سئو باشد، canonical می‌تونه گزینه بهتری باشد.
Canonical با noindex چه فرقی دارد؟
برای کنترل مسیرهای خزش باید تفاوت Canonical، noindex و قواعد فایل Robots.txt را دقیق بدانید؛ هرکدام مسئله متفاوتی را حل می‌کنند.
Canonical می‌گوید نسخه اصلی این محتوا کدام URL است، اما noindex می‌گوید این صفحه در نتایج جستجو ایندکس نشود. این دو ابزار هدف متفاوتی دارند و نباید بی‌دلیل با هم قاطی شوند.
|
ابزار |
هدف اصلی |
مثال استفاده |
|
Canonical |
انتخاب نسخه اصلی بین صفحات مشابه |
صفحه فیلتر به دسته اصلی |
|
noindex |
جلوگیری از ایندکس شدن یک صفحه |
صفحه جستجوی داخلی یا پنل کاربری |
|
robots.txt |
جلوگیری از Crawl مسیر مشخص |
مسیرهای بی‌ارزش و بی‌نیاز به Crawl |
|
301 Redirect |
انتقال دائمی URL |
تغییر آدرس مقاله یا محصول |
گوگل درباره noindex توضیح می‌دهد این دستور باید توسط crawler دیده شود؛ اگر صفحه با robots.txt بلاک شده باشد، crawler نمی‌تواند noindex را ببیند و URL ممکن است همچنان در نتایج ظاهر شود، مثلاً وقتی صفحات دیگر به آن لینک داده‌اند. این دقیقاً نشان می‌دهد انتخاب ابزار اشتباه چقدر می‌تونه دردسر بسازه.
نکته: Canonical + noindex روی یک صفحه معمولاً ترکیب خوبی نیست. چون از یک طرف میگی سیگنال‌ها را به صفحه اصلی منتقل کن، از طرف دیگر میگی این صفحه را ایندکس نکن. گوگل ممکنه مسیر دلخواه تو را نفهمه. اگر لازم شد، خیلی دقیق و با دلیل استفاده کن، نه به‌عنوان نسخه پیش‌فرض.
[LINK: مقاله تفاوت noindex، robots.txt و canonical در سئو تکنیکال]
Canonical در فروشگاه اینترنتی چطور باید استفاده شود؟
در صفحات تجاری، نسخه Canonical باید با مقصد اصلی کاربر هماهنگ باشد؛ راهنمای لندینگ پیج نیز اصول انتخاب و بهینه‌سازی صفحه مقصد را توضیح می‌دهد.
در فروشگاه اینترنتی، Canonical بیشتر برای مدیریت فیلترها، Sort، محصولات چندمسیره، پارامترهای URL و نسخه‌های تکراری محصول استفاده میشود. اگر فروشگاه بزرگ داری و canonical را درست نچینی، Googlebot ممکنه بین هزاران URL مشابه بچرخه و صفحات مهم دیرتر یا اشتباه‌تر ایندکس شوند.
سناریوهای رایج فروشگاهی:
- فیلتر رنگ یا سایز:
اگر صفحه «کفش مردانه مشکی» Search Demand دارد و می‌خوای برایش رتبه بگیری، شاید باید صفحه مستقل قابل ایندکس باشد. اما اگر فقط یک فیلتر موقت است، canonical به دسته اصلی منطقی‌تره. - Sort بر اساس قیمت یا جدیدترین:
معمولاً URLهای Sort نباید نسخه اصلی باشند. این‌ها اغلب به همان صفحه دسته‌بندی canonical می‌شوند. - محصول در چند دسته:
یک URL اصلی برای محصول انتخاب کن. بهتره محصول چند آدرس مستقل با canonicalهای متناقض نداشته باشد. - محصولات با Variation:
اگر هر رنگ یا مدل صفحه جدا دارد و محتوای مستقل، عکس، موجودی و جستجوی جدا دارد، شاید هرکدام باید canonical به خودش داشته باشد. اما اگر فقط پارامتر ساده است، canonical به محصول اصلی بهتره. - محصول ناموجود:
اگر موقتاً ناموجوده، صفحه را نگه دار و Self canonical بزن. اگر برای همیشه حذف شده، بسته به وجود جایگزین، 301، 404 یا 410 را بررسی کن.
نمونه فرضی: یک فروشگاه لباس ۱۲ رنگ برای یک تیشرت دارد. اگر همه رنگ‌ها URL جدا بسازند اما محتوا، توضیح، عنوان و هدف یکی باشد، ممکنه نسخه‌ها با هم تداخل داشته باشند. اگر رنگ‌ها Search Demand مستقل ندارند، بهتره یک صفحه اصلی محصول داشته باشی و تغییر رنگ داخل همان صفحه مدیریت شود. اما اگر «تیشرت سفید مردانه» و «تیشرت مشکی مردانه» هر دو تقاضای جستجوی جدی دارند و موجودی و تصویر و محتوای جدا دارند، داستان فرق میکند.
Canonical در صفحات Pagination چطور باید باشد؟
در صفحات Pagination، معمولاً هر صفحه باید canonical به خودش داشته باشد، نه اینکه همه صفحات صفحه‌بندی‌شده canonical به صفحه اول بدهند. اگر صفحه ۲ و ۳ دسته‌بندی محصولات متفاوتی را نشان می‌دهند، canonical کردن همه آن‌ها به صفحه ۱ ممکنه باعث شود گوگل محتوای صفحات بعدی را کمتر جدی بگیرد.
مثلاً:
- /blog/page/1/ → canonical به خودش
- /blog/page/2/ → canonical به خودش
- /blog/page/3/ → canonical به خودش
اشتباه رایج:
- /blog/page/2/ → canonical به /blog/
- /blog/page/3/ → canonical به /blog/
این کار اگر صفحات بعدی محتوای متفاوت دارند، می‌تونه کشف مقالات یا محصولات عمیق‌تر را خراب کند. البته اگر صفحه‌بندی فقط نسخه‌های تکراری یا بی‌ارزش ساخته، باید ساختار را جدا بررسی کرد. ولی پیش‌فرض حرفه‌ای این نیست که همه Paginationها را به صفحه اول canonical کنیم.
نکته: Pagination را با Duplicate Content اشتباه نگیر. صفحه ۲ دسته‌بندی معمولاً تکرار صفحه ۱ نیست؛ ادامه لیست است.
Canonical و hreflang چه ارتباطی دارند؟
در سایت‌های چندزبانه یا چندمنطقه‌ای، canonical و hreflang باید با هم هماهنگ باشند. هر نسخه زبانی معمولاً باید canonical به خودش داشته باشد و hreflang به نسخه‌های معادل زبانی اشاره کند. اگر نسخه فارسی canonical به نسخه انگلیسی بدهد، ممکنه گوگل نسخه فارسی را به‌عنوان صفحه مستقل جدی نگیرد.
نمونه درست ساده:
- صفحه فارسی: canonical به URL فارسی خودش، hreflang به فارسی و انگلیسی
- صفحه انگلیسی: canonical به URL انگلیسی خودش، hreflang به انگلیسی و فارسی
نمونه اشتباه:
- صفحه فارسی canonical به انگلیسی
- صفحه انگلیسی canonical به خودش
- hreflang بینشان تعریف شده
اینجا داری دو سیگنال متناقض میدی. از یک طرف میگی این‌ها نسخه‌های زبانی هم‌اند، از طرف دیگر میگی نسخه فارسی خودش اصلی نیست. گوگل معمولاً با سیگنال متناقض خوب کنار نمیاد؛ یعنی ممکنه چیزی را انتخاب کند که تو نمی‌خواستی.
نکته: در سایت چندزبانه، اول ساختار زبان و منطقه را درست کن، بعد canonical و hreflang را بچین. برعکسش یعنی دردسر.
خطای Alternate page with proper canonical tag یعنی چه؟
خطای Alternate page with proper canonical tag در Search Console یعنی گوگل صفحه‌ای را پیدا کرده، اما آن را نسخه جایگزین می‌داند و نسخه canonical دیگری را برای ایندکس انتخاب کرده است. این وضعیت همیشه خطا به معنی بد نیست؛ گاهی دقیقاً همان چیزی است که خودت خواسته‌ای.
مثلاً اگر صفحه ?sort=price canonical به صفحه دسته‌بندی اصلی دارد، طبیعی است که Search Console آن URL را به‌عنوان Alternate page with proper canonical tag نشان دهد. این یعنی گوگل canonical را دیده و پذیرفته. مشکل وقتی شروع میشه که URL مهمی که باید ایندکس شود، در این وضعیت قرار بگیرد.
در Search Console Help هم توضیح داده میشود که گوگل یک گروه از URLهای duplicate را تحلیل میکند و یک canonical URL انتخاب میکند. همچنین URLهای duplicate معمولاً در نتایج نشان داده نمی‌شوند مگر اینکه نسخه جایگزین باشند.
چک کن:
- آیا این URL واقعاً باید ایندکس شود؟
- آیا canonical آن به صفحه درست اشاره میکند؟
- آیا صفحه مقصد 200 و قابل ایندکس است؟
- آیا URL در Sitemap آمده؟ اگر alternate است، نباید بیاد.
- آیا لینک داخلی به نسخه جایگزین زیاد است؟
نکته: هر مورد Alternate page را لازم نیست رفع کنی. بعضی‌ها نشانه کار درست canonical هستند. اول ببین URL باید ایندکس شود یا نه.
خطای Duplicate, Google chose different canonical than user چیست؟
این خطا را همراه با گزارش‌های سرچ کنسول بررسی کنید تا ببینید گوگل کدام URL را نسخه اصلی تشخیص داده و چه سیگنال‌هایی با انتخاب شما تضاد دارند.
این وضعیت یعنی تو یک canonical معرفی کرده‌ای، اما گوگل نسخه دیگری را به‌عنوان canonical انتخاب کرده است. اینجا گوگل عملاً سیگنالهای تو را کافی یا منطقی ندیده و خودش URL دیگری را نماینده محتوا دانسته.
دلایل رایج:
- canonical به URL ضعیف یا نامناسب اشاره کرده.
- صفحه مقصد noindex، 404، ریدایرکت یا بلاک است.
- لینک داخلی بیشتر به URL دیگری اشاره میکند.
- Sitemap نسخه‌ای غیر از canonical را معرفی کرده.
- محتوای صفحه‌ها آن‌قدر شبیه نیست که canonical تو منطقی باشد.
- نسخه HTTPS و HTTP یا www و non-www سیگنالهای متناقض دارند.
- canonical چندگانه یا اشتباه در head صفحه وجود دارد.
- URL مقصد از نظر گوگل تجربه کاربری بهتری دارد.
گوگل در راهنمای Troubleshooting Canonicalization میگه قبل از رفع مشکل، اول فکر کن شاید canonical انتخاب‌شده توسط گوگل برای کاربران سرچ منطقی‌تر از canonical ترجیحی تو باشد. این جمله خیلی مهمه؛ یعنی همیشه گوگل اشتباه نکرده، شاید ما صفحه اصلی را اشتباه انتخاب کردیم.
نمونه فرضی: صفحه A یک مقاله قدیمی و ناقصه، صفحه B نسخه کامل‌تر و جدیدتر همان موضوعه. تو اشتباهی canonical صفحه B را به A داده‌ای، اما گوگل B را انتخاب کرده. اینجا شاید مشکل از گوگل نیست؛ مشکل از تصمیم توست.
چطور خطاهای Canonical را در Search Console بررسی کنیم؟
برای بررسی خطاهای Canonical در Search Console باید URL Inspection، Page Indexing Report و داده‌های Sitemap را کنار هم ببینی. فقط با دیدن یک وضعیت، تصمیم نگیر؛ باید بفهمی URL از نظر گوگل duplicate است، alternate است، canonical پیشنهادی چیست و canonical انتخابی گوگل کدام است.
مراحل عملی:
- وارد Search Console شو.
- به Page Indexing برو.
- وضعیت‌های مرتبط با Duplicate و Canonical را بررسی کن.
- چند URL مهم را با URL Inspection باز کن.
- بخش User-declared canonical را ببین.
- بخش Google-selected canonical را ببین.
- وضعیت Indexing allowed، robots.txt، noindex و response code را چک کن.
- بررسی کن URL در Sitemap هست یا نه.
- لینک داخلی به URL اصلی و نسخه‌های جایگزین را بررسی کن.
- اگر گوگل canonical متفاوت انتخاب کرده، دلیل احتمالی را از سیگنال‌ها پیدا کن.
Search Console Help توضیح می‌دهد در گزارش Page indexing، ممکنه صفحاتی به‌خاطر duplicate بودن با صفحات دیگر، blocked بودن با robots.txt یا noindex، یا مشکلات دیگر ایندکس نشوند. همین گزارش برای تشخیص اینکه canonical واقعاً مشکل است یا نتیجه طبیعی مدیریت نسخه‌هاست، نقطه شروع خوبیه.
نکته: URL Inspection را فقط برای یک URL انجام نده. چند نمونه از یک الگوی مشابه را بررسی کن. خطای Canonical معمولاً الگو دارد، نه فقط یک URL تصادفی.
اعداد خوب، متوسط و ضعیف برای بررسی وضعیت Canonical
برای Canonical عدد رسمی جهانی وجود ندارد؛ نمی‌تونیم بگیم اگر ۵٪ URLها Alternate بودند خوبه یا بد. بستگی به نوع سایت دارد. اما برای مدیریت پروژه تکنیکال، میشه چند معیار اجرایی گذاشت تا بفهمی وضعیت سالمه یا نیاز به بررسی جدی دارد.
|
معیار |
خوب |
متوسط |
ضعیف |
|
URLهای canonical شده داخل Sitemap |
تقریباً صفر |
چند مورد محدود |
زیاد و ساختاری |
|
صفحات مهم با Google-selected canonical متفاوت |
نزدیک به صفر |
چند الگوی قابل بررسی |
زیاد و اثرگذار |
|
canonical به URL غیر 200 |
صفر |
موردی |
پرتکرار |
|
canonical چندگانه در یک صفحه |
صفر |
موردی |
ساختاری |
|
self canonical در صفحات قابل ایندکس |
بیشتر صفحات مهم دارند |
ناقص اما قابل اصلاح |
نامنظم یا غایب |
|
canonical به noindex/redirect/404 |
صفر |
موردی |
پرتکرار |
|
canonical متناقض با لینک داخلی |
کم |
قابل تشخیص |
زیاد و گیج‌کننده |
نمونه فرضی: اگر فروشگاهی ۳۰ هزار URL دارد و ۸ هزار URL فیلترشده به دسته اصلی canonical شده‌اند، این الزاماً بد نیست. اما اگر ۲ هزار URL از محصولات اصلی هم canonical به دسته‌بندی یا محصولات دیگر دارند، مشکل جدیه. فرقش اینه که فیلترها ممکنه نسخه جایگزین باشند، اما محصولات اصلی باید معمولاً Self canonical داشته باشند.
اشتباهات رایج در استفاده از Canonical
بیشتر خطاهای Canonical از اینجا میاد که باهاش مثل چسب زخم برخورد می‌کنیم. هرجا URL اضافه یا صفحه ضعیف دیدیم، سریع canonical می‌زنیم. ولی canonical ابزار تصمیم‌گیری دقیق می‌خواد، نه واکنش عصبی.
اشتباهات مهم:
- canonical دادن همه صفحات به صفحه اصلی:
این فاجعه است. یعنی عملاً به گوگل میگی بیشتر صفحات سایت نسخه اصلی نیستند. بعضی سایت‌ها با همین اشتباه کلی صفحه مهم را از ایندکس انداخته‌اند. - canonical به URL ریدایرکت‌شده:
مقصد canonical باید URL نهایی و 200 باشد. اگر به URLی اشاره می‌کنی که خودش ریدایرکت میشود، سیگنال را شلخته می‌کنی. - canonical به صفحه noindex:
این ترکیب معمولاً سیگنال متناقض می‌سازد. صفحه مقصدی که باید canonical باشد، باید قابل ایندکس باشد. - canonical چندگانه در یک صفحه:
افزونه سئو، قالب سایت و کد دستی گاهی هر کدام یک canonical می‌سازند. نتیجه؟ دو سیگنال مختلف در head. - استفاده از URL نسبی:
مسیر نسبی در بعضی ساختارها می‌تواند اشتباه تفسیر شود. URL کامل و دقیق بنویس. - canonical صفحات Pagination به صفحه اول:
اگر صفحات بعدی محتوای متفاوت دارند، این کار می‌تونه کشف URLهای عمیق‌تر را خراب کند. - canonical بین صفحات با Intent متفاوت:
مثلاً مقاله آموزشی به صفحه خدماتی. این کار اغلب به جای حل مشکل، صفحه مفید را حذف سیگنالی میکند. - وجود URLهای canonical شده در Sitemap:
Sitemap باید URLهای اصلی و قابل ایندکس را معرفی کند، نه نسخه‌های جایگزین.
نکته: اگر canonical را نمی‌فهمی، کمتر استفاده کن. اشتباه کم‌استفاده کردن معمولاً از اشتباه بد استفاده کردن کم‌هزینه‌تره.
چطور Canonical سایت را Audit کنیم؟
برای Audit کنونیکال باید چند منبع داده را کنار هم بررسی کنی: Crawl با ابزارهایی مثل Screaming Frog یا Sitebulb، گزارش Page Indexing در Search Console، Sitemap، لینک داخلی و نمونه‌های URL Inspection. هدف اینه که بفهمی الگوهای canonical سایت منطقی‌اند یا نه.
مراحل پیشنهادی:
- سایت را با یک crawler کامل Crawl کن.
- URLهای بدون canonical را جدا کن.
- URLهای با چند canonical را پیدا کن.
- canonicalهایی که به 3xx، 4xx، 5xx یا noindex می‌رسند را استخراج کن.
- URLهایی که canonical به صفحه دیگری دارند اما داخل Sitemap هستند را پیدا کن.
- صفحات قابل ایندکس بدون Self canonical را بررسی کن.
- canonicalهای Cross-domain را جداگانه چک کن.
- صفحات مهمی را که Google-selected canonical متفاوت دارند در Search Console بررسی کن.
- لینک داخلی را با canonicalها مقایسه کن.
- برای هر الگوی مشکل، تصمیم جدا بگیر؛ نه اینکه همه را یک‌جا تغییر بدهی.
نمونه فرضی: در Audit یک سایت فروشگاهی می‌بینی ۴۵۰ صفحه محصول canonical به URL دسته‌بندی دارند. این احتمالاً اشتباهه، چون محصول‌ها باید مستقل ایندکس شوند. اما ۷ هزار URL Sort که canonical به دسته‌بندی دارند، شاید طبیعی باشد. فرق این دو را باید بفهمی؛ ابزار فقط لیست می‌دهد، تصمیم با توست.
[LINK: صفحه Audit تکنیکال سئو و بررسی Search Console]
چطور خطاهای Canonical را رفع کنیم؟
اگر خطاهای کنونیکال بین صفحات سئو و لندینگ‌های کمپین تکرار می‌شوند، مشاوره گوگل ادز می‌تواند هماهنگی URL نهایی، ردیابی و ساختار صفحه مقصد را بررسی کند.
برای رفع خطای Canonical اول باید نوع مشکل را تشخیص بدی. هر خطا راه‌حل خودش را دارد. گاهی فقط تگ را اصلاح می‌کنی، گاهی Sitemap را پاک‌سازی می‌کنی، گاهی لینک داخلی را تغییر میدی و گاهی باید صفحه‌ها را ادغام یا ریدایرکت کنی.
اگر canonical به URL اشتباه اشاره میکند
URL داخل href را به نسخه اصلی واقعی تغییر بده. بعد مطمئن شو همان URL در Sitemap است، لینک داخلی به همان نسخه می‌رود و صفحه مقصد 200 و indexable است.
اگر گوگل canonical متفاوت انتخاب کرده
اول User-declared و Google-selected را مقایسه کن. اگر گوگل منطقی‌تر انتخاب کرده، شاید باید انتخاب خودت را اصلاح کنی. اگر انتخاب گوگل اشتباهه، سیگنالهای خودت را یکدست کن: لینک داخلی، Sitemap، canonical، ریدایرکت و محتوای صفحه.
اگر canonical به noindex یا 404 می‌رود
این یکی را سریع اصلاح کن. مقصد canonical باید صفحه سالم، قابل Crawl، قابل ایندکس و مرتبط باشد. canonical به صفحه خراب یعنی آدرس دادن به در بسته.
اگر چند canonical در صفحه وجود دارد
منبع تولیدشان را پیدا کن. ممکنه افزونه سئو، قالب، CMS یا کد دستی همزمان canonical بسازند. یکی را نگه دار و بقیه را حذف کن.
اگر صفحات مهم به صفحه مادر canonical شده‌اند
بررسی کن آیا واقعاً duplicate هستند یا صفحه مستقل‌اند. اگر صفحه مستقل است، Self canonical بزن و لینک داخلی و Sitemap را هم اصلاح کن.
اگر URLهای alternate داخل Sitemap هستند
Sitemap را پاک‌سازی کن. فقط URLهای canonical، 200 و قابل ایندکس باید داخل Sitemap باشند. این یکی خیلی ساده است، ولی عجیب زیاد خراب دیده میشه.
سناریوی عملی: وقتی Canonical اشتباه صفحه‌های محصول را از ایندکس خارج کرد
نمونه فرضی: یک فروشگاه اینترنتی بعد از تغییر قالب، متوجه میشه تعداد زیادی صفحه محصول در Search Console با وضعیت Alternate page with proper canonical tag دیده میشن. در نگاه اول شاید بگیم «خب canonical درست کار کرده». اما وقتی URL Inspection انجام میدیم، می‌بینیم محصول‌ها به صفحه دسته‌بندی مادر canonical شده‌اند.
مشکل چی بوده؟ قالب جدید برای همه محصولات یک canonical اشتباه ساخته:
<link rel=”canonical” href=”https://example.com/category/shoes/” />
در حالی که هر محصول باید canonical به URL خودش می‌داشت:
<link rel=”canonical” href=”https://example.com/product/running-shoe-a/” />
اصلاح پیشنهادی:
- الگوی canonical قالب محصول اصلاح شود.
- همه محصولات قابل ایندکس Self canonical بگیرند.
- Sitemap محصولات دوباره تولید شود.
- URLهای محصولات در Sitemap باشند، نه نسخه‌های پارامتردار.
- لینک داخلی دسته‌بندی‌ها به URL نهایی محصول برود.
- چند URL مهم با URL Inspection بررسی شود.
- بعد از چند هفته، وضعیت Page Indexing و Google-selected canonical دوباره چک شود.
اینجا اگر فقط به اسم وضعیت Search Console نگاه می‌کردی، ممکن بود فکر کنی همه‌چیز خوبه. اما واقعیت این بود که صفحه‌های محصول اصلی داشتند از ایندکس خارج می‌شدند. این دقیقاً همان جاییه که باید داده را با عقل بخونی، نه با ترس یا خوش‌خیالی.
Canonical و Sitemap چطور باید هماهنگ باشند؟
قرارگرفتن فقط URLهای اصلی در Sitemap به مدیریت بهتر Crawl Budget کمک میکند و از ارسال سیگنالهای متناقض جلوگیری میکند.
Sitemap باید فقط URLهایی را معرفی کند که نسخه canonical، قابل ایندکس و مهم هستند. اگر URLی داخل Sitemap است اما خودش canonical به صفحه دیگری می‌دهد، داری سیگنال متناقض می‌فرستی.
گوگل هم در راهنمای مشخص کردن canonical میگه Sitemap راه ساده‌ای برای اعلام URLهای canonical در سایت‌های بزرگه، چون به گوگل میگه کدام صفحات را مهم‌تر می‌دانی. البته قدرت canonical در Sitemap نسبت به ریدایرکت یا rel=canonical کمتره، اما برای هماهنگی سیگنال‌ها مهمه.
چک‌لیست Sitemap و Canonical:
- URL داخل Sitemap باید 200 باشد.
- URL داخل Sitemap نباید noindex باشد.
- URL داخل Sitemap نباید canonical به URL دیگری داشته باشد.
- URL داخل Sitemap نباید ریدایرکت شود.
- نسخه HTTPS و دامنه اصلی باید استفاده شود.
- URLهای پارامتردار و alternate نباید در Sitemap اصلی باشند.
- lastmod فقط وقتی تغییر واقعی رخ داده، آپدیت شود.
نکته: Sitemap لیست آرزوهای تو برای ایندکس نیست؛ لیست URLهای مهم و سالم سایتته. URL مریض را داخل Sitemap نذار، بعد از گوگل گله نکن چرا جدی‌اش نگرفته.
Canonical و لینک داخلی چه ارتباطی دارند؟
برای تقویت نسخه اصلی، انکرتکست و مسیر لینک‌ها را با اصول سئو محتوا هماهنگ کنید تا صفحات داخلی به URLهای جایگزین اشاره نکنند.
در تبلیغات گوگل ادز نیز بهتر است URL نهایی آگهی به نسخه Canonical و قابل ایندکس صفحه اشاره کند تا داده‌ها و تجربه مقصد پراکنده نشوند.
لینک داخلی باید به نسخه canonical صفحات اشاره کند. اگر canonical صفحه به URL A است اما لینک‌های داخلی بیشتر به URL B می‌روند، سیگنال‌ها متناقض میشن و گوگل ممکنه نسخه‌ای را انتخاب کند که تو نمی‌خواستی.
مثال بد:
- canonical: https://example.com/seo-guide/
- لینک‌های داخلی: https://example.com/seo-guide?utm=menu
- Sitemap: https://example.com/seo-guide
- Breadcrumb: http://example.com/seo-guide/
اینجا همه‌چیز نزدیکه، ولی تمیز نیست. بهتره همه مسیرها به نسخه نهایی، HTTPS، با یا بدون اسلش ثابت و canonicalشده اشاره کنند.
چند قانون ساده:
- منوی اصلی به نسخه canonical لینک بدهد.
- Breadcrumb به نسخه canonical لینک بدهد.
- لینک‌های داخل محتوا به نسخه canonical بروند.
- لینک‌های قدیمی بعد از تغییر URL اصلاح شوند.
- لینک به URLهای ریدایرکت‌شده کم شود.
- لینک داخلی به صفحات alternate یا پارامتردار تا حد ممکن کنترل شود.
نکته: وقتی خود سایتت به نسخه‌های مختلف لینک می‌دهد، از گوگل انتظار نداشته باشه ذهن‌خوانی کند. خودت باید نسخه اصلی را جدی بگیری تا گوگل هم جدی بگیرد.
Cross-domain Canonical چیست؟
Cross-domain Canonical یعنی یک صفحه در یک دامنه به صفحه‌ای در دامنه دیگر canonical بدهد. این روش برای بعضی سناریوهای محتوای تکراری بین دامنه‌ها کاربرد دارد، اما باید خیلی محتاط استفاده شود.
مثلاً اگر یک مقاله در سایت اصلی منتشر شده و همان مقاله عیناً در یک سایت دیگر هم بازنشر شده، سایت دوم می‌تواند canonical به منبع اصلی بدهد. اما این کار همیشه قابل اتکا نیست و همه سایت‌های منتشرکننده هم آن را درست پیاده نمی‌کنند.
گوگل در بلاگ Search Central درباره محتوای تکراری بین دامنه‌ها توضیح داده بود که هنگام مواجهه با محتوای duplicate، موتورهای جستجو معمولاً یک نسخه را انتخاب و نسخه‌های دیگر را فیلتر می‌کنند. همان مقاله اشاره میکند که در چنین سناریوهایی، rel=canonical می‌تواند برای اشاره به نسخه اصلی استفاده شود، به شرطی که crawler بتواند آن را ببیند.
اما ریسک هم دارد. گوگل در مقاله‌ای درباره انتخاب URLهای Cross-domain هشدار داده بود که canonicalization اشتباه به دامنه خارجی می‌تواند باعث شود الگوریتم‌ها URL خارجی را برای نمایش در نتایج انتخاب کنند. یعنی اگر اشتباه بزنی، ممکنه اعتبار صفحه خودت را دودستی تقدیم جای دیگری کنی.
نکته: Cross-domain canonical را فقط وقتی استفاده کن که مالکیت، هدف، نسخه اصلی و رابطه محتوا کاملاً روشن است. اینجا جای تست بی‌حساب نیست.
Canonical برای صفحات فیلتر و Faceted Navigation
صفحات فیلتر یکی از پیچیده‌ترین بخش‌های Canonical هستند. چون بعضی فیلترها ارزش سئویی دارند و بعضی فقط URL اضافه تولید می‌کنند. اشتباه بزرگ اینه که همه فیلترها را یک‌جا canonical کنی یا همه را باز بگذاری.
مثال فروشگاهی:
- example.com/shoes/
دسته اصلی کفش - example.com/shoes/?color=black
فیلتر رنگ مشکی - example.com/shoes/black/
صفحه سئویی کفش مشکی - example.com/shoes/?sort=price_asc
مرتب‌سازی قیمت
تصمیم بهتر:
- اگر «کفش مشکی» Search Demand دارد، صفحه /shoes/black/ می‌تواند قابل ایندکس و Self canonical باشد.
- URL پارامتردار ?color=black بهتره به صفحه سئویی یا دسته اصلی canonical شود، بسته به ساختار.
- ?sort=price_asc معمولاً ارزش ایندکس ندارد و باید canonical به دسته اصلی یا کنترل Crawl شود.
نکته: Canonical برای فیلترها بدون Keyword Research خطرناک است. ممکنه صفحه‌ای را canonical کنی که اتفاقاً می‌توانست ترافیک خوب بگیرد. اول تقاضای جستجو را بفهم، بعد تصمیم فنی بگیر.
چک‌لیست استفاده صحیح از Canonical
قبل از انتشار یا اصلاح canonical، این چک‌لیست را برو. مخصوصاً اگر سایت فروشگاهی، محتوایی بزرگ یا چندزبانه داری، این موارد را دوره‌ای بررسی کن.
- هر صفحه قابل ایندکس Self canonical دارد؟
- canonical فقط یک‌بار در head صفحه آمده؟
- URL canonical کامل و Absolute است؟
- URL مقصد 200 است؟
- URL مقصد noindex نیست؟
- URL مقصد با robots.txt بلاک نشده؟
- canonical به URL ریدایرکت‌شده اشاره نمیکند؟
- URLهای canonical شده داخل Sitemap نیستند؟
- لینک داخلی به نسخه canonical اشاره میکند؟
- صفحات Pagination به اشتباه همه به صفحه اول canonical نشده‌اند؟
- صفحات محصول مستقل canonical به دسته‌بندی ندارند؟
- نسخه‌های زبانی canonical به خودشان دارند؟
- hreflang و canonical با هم تناقض ندارند؟
- URLهای پارامتردار سیاست مشخص دارند؟
- نسخه HTTPS و دامنه اصلی در canonical استفاده شده؟
- canonicalهای Cross-domain با دلیل و کنترل‌شده‌اند؟
- Google-selected canonical برای صفحات مهم بررسی شده؟
- خطاهای Duplicate و Alternate در Search Console تحلیل شده‌اند؟
- canonical با هدف صفحه و Search Intent هماهنگه؟
- بعد از اصلاح، URL Inspection و Crawl دوباره انجام شده؟
اگر فقط یک چیز از این چک‌لیست یادت بمونه، همین باشه: canonical باید با بقیه سیگنالهای سایت هم‌جهت باشد. یک تگ تنها نمی‌تواند معماری شلخته سایت را نجات دهد.
اشتباهات خطرناک Canonical که باید فوری اصلاح شوند
بعضی خطاها فقط جزئی نیستند؛ ممکنه مستقیماً صفحه‌های مهم را از ایندکس خارج کنند یا باعث شوند گوگل صفحه اشتباهی را انتخاب کند.
خطاهای فوری:
- همه صفحات canonical به Homepage:
این یکی را اگر دیدی، سریع اصلاح کن. معمولاً از تنظیم اشتباه CMS یا افزونه میاد. - محصولات canonical به دسته‌بندی:
اگر محصول‌ها باید رتبه بگیرند، این اشتباه خیلی پرهزینه است. - مقالات قدیمی و جدید canonical متقاطع:
صفحه A به B، صفحه B به A. گوگل با این بازی مار و پله حال نمیکند. - canonical به URL noindex:
مقصدی که خودش نباید ایندکس شود، نباید نسخه اصلی باشد. - canonical به URL 404 یا 500:
یعنی نسخه اصلی را به صفحه خراب معرفی کرده‌ای. قشنگه؟ نه. - canonical متناقض با hreflang:
مخصوصاً در سایت‌های چندزبانه می‌تونه کل ساختار زبان را خراب کند. - وجود canonical در body به جای head:
گوگل ممکنه آن را نادیده بگیرد یا درست پردازش نکند. جای تگ مهمه. - canonical تولیدشده با JavaScript بدون اطمینان از Render:
اگر canonical بعداً با JS تزریق میشود، باید دقیق تست کنی که Googlebot واقعاً آن را می‌بیند یا نه.
نکته: Canonical اشتباه از نبود canonical هم بدتره. نبودش ممکنه باعث ابهام شود؛ اشتباه بودنش ممکنه مسیر را کاملاً غلط نشان دهد.
نتیجه‌گیری
تگ Canonical ابزار ساده‌ای به نظر می‌رسد، اما اثرش در تکنیکال سئو خیلی جدی است. این تگ کمک میکند نسخه اصلی صفحات مشابه مشخص شود، سیگنال‌ها روی URL درست جمع شوند و گوگل بین چند نسخه تکراری کمتر سردرگم شود. با این حال، canonical دستور قطعی نیست و اگر با Sitemap، لینک داخلی، hreflang، ریدایرکت و Search Intent هماهنگ نباشد، ممکن است گوگل نسخه دیگری را انتخاب کند. در سایت‌های فروشگاهی، چندزبانه و بزرگ، خطای کنونیکال می‌تواند مستقیم روی ایندکس صفحات مهم اثر بگذارد. اگر در Search Console با وضعیت‌های Duplicate، Alternate یا Google-selected canonical متفاوت درگیر شدی، هشت پا می‌تونه ساختار canonical، Sitemap و الگوهای URL سایتت را بررسی کند تا قبل از تغییرات سنگین، تصمیم فنی درست‌تری بگیری.
سوالات متداول
آیا تگ Canonical باعث حذف صفحه از گوگل میشود؟
Canonical مستقیم برای حذف صفحه از گوگل ساخته نشده. این تگ به گوگل می‌گوید نسخه اصلی یک محتوای مشابه کدام URL است، و معمولاً گوگل نسخه canonical را برای ایندکس و نمایش ترجیح می‌دهد. اگر صفحه‌ای canonical به صفحه دیگری بدهد، ممکن است خودش در نتایج نمایش داده نشود، اما این با noindex فرق دارد. اگر واقعاً می‌خوای صفحه‌ای ایندکس نشود، باید noindex، حذف، ریدایرکت یا روش مناسب دیگری را بررسی کنی.
آیا همه صفحات سایت باید Self canonical داشته باشند؟
برای بیشتر صفحات قابل ایندکس، داشتن Self canonical انتخاب خوبی است. این کار به گوگل کمک میکند نسخه اصلی هر صفحه را واضح‌تر بفهمد، مخصوصاً وقتی URLهای پارامتردار، UTM، نسخه با اسلش و بدون اسلش یا مسیرهای مختلف وجود دارند. البته Self canonical به‌تنهایی کافی نیست؛ لینک داخلی، Sitemap و نسخه نهایی URL هم باید هماهنگ باشند. اگر صفحه‌ای نباید ایندکس شود، اول باید هدف آن صفحه را مشخص کنی، نه اینکه صرفاً Self canonical بزنی.
آیا گوگل همیشه canonical انتخابی ما را قبول میکند؟
نه، گوگل همیشه canonical انتخابی تو را قبول نمیکند. Canonical یک سیگنال قوی است، اما اگر سیگنالهای دیگر مثل لینک داخلی، Sitemap، ریدایرکت، محتوای صفحه و کیفیت URL با آن نخوانند، گوگل ممکن است URL دیگری را انتخاب کند. این وضعیت در Search Console با مواردی مثل Google-selected canonical متفاوت از User-declared canonical دیده میشود. اگر این اتفاق برای صفحات مهم افتاده، باید همه سیگنالهای صفحه را با هم بررسی کنی.
آیا Canonical برای صفحات مشابه شهری مناسب است؟
گاهی بله، اما معمولاً باید با احتیاط استفاده شود. اگر صفحات شهری فقط اسم شهر را عوض کرده‌اند و محتوای واقعی متفاوتی ندارند، شاید مشکل محتوایی و Duplicate Intent داشته باشی. اما اگر هر صفحه شهر، اطلاعات اختصاصی، خدمات واقعی، نمونه‌کار، آدرس یا توضیح مرتبط با همان بازار دارد، canonical کردن آن‌ها به یک صفحه مادر می‌تواند اشتباه باشد. بهتره اول ببینی صفحات شهری واقعاً ارزش مستقل دارند یا فقط نسخه‌های تکراری‌اند.
Canonical بهتر است یا Redirect؟
اگر URL مبدا دیگر نباید برای کاربر باز شود و نسخه جدید جایگزین دائمی آن است، 301 Redirect معمولاً انتخاب بهتری است. اما اگر URL مبدا باید برای کاربر قابل مشاهده بماند، ولی از نظر سئو نسخه اصلی صفحه دیگری است، Canonical مناسب‌تره. مثلاً صفحه Sort یا فیلتر ممکنه برای تجربه کاربر لازم باشد، اما نسخه اصلی سئو نباشد. تصمیم درست به این بستگی دارد که URL مبدا باید زنده بماند یا نه.
