نویسنده: مای محتوا
راهنمای جامع شناسایی و رفع مشکل انتخاب Canonical اشتباه توسط گوگل؛ بررسی تفاوت User-declared canonical و Google-selected canonical، علت انتخاب صفحات تکراری، محصولات متغیر، URLهای پارامتردار، دسته‌بندی‌ها و صفحات صفحه‌بندی‌شده. همراه با روش عیب‌یابی در Google Search Console، بررسی کد HTML و پاسخ سرور، جدول تصمیم‌گیری، سناریوهای واقعی فروشگاهی و چک‌لیست اجرایی.
فرض کنید در فروشگاه اینترنتی خود یک صفحه محصول با آدرس مشخص دارید. این صفحه عنوان، تصاویر، قیمت و توضیحات کامل دارد و در کد آن نیز Canonical را روی همان آدرس تنظیم کرده‌اید. اما وقتی وارد Google Search Console می‌شوید، متوجه می‌شوید گوگل یک آدرس دیگر را به‌عنوان نسخه اصلی یا Canonical انتخاب کرده است.
برای مثال، صفحه محصول با ظرفیت ۲۵۶ گیگابایت را بررسی می‌کنید، اما گوگل نسخه ۱۲۸ گیگابایتی همان مدل را به‌عنوان Canonical نشان می‌دهد. یا صفحه دوم یک دسته‌بندی به صفحه اول مرتبط شده، درحالی‌که محصولات متفاوتی در آن نمایش داده می‌شوند.
این وضعیت ممکن است باعث شود صفحه‌ای که انتظار دارید در گوگل دیده شود، به‌عنوان نسخه مستقل ایندکس نشود. بااین‌حال، هر تفاوت میان Canonical انتخابی سایت و گوگل به معنی خطا نیست. بعضی آدرس‌ها واقعاً نسخه تکراری صفحه دیگری هستند و انتخاب یک URL اصلی برای آن‌ها کاملاً طبیعی است.
برای رفع مشکل، باید ابتدا مشخص کنید چرا گوگل صفحه دیگری را انتخاب کرده است. آیا دو URL محتوای بسیار مشابه دارند؟ آیا تگ Canonical اشتباه نوشته شده است؟ آیا Sitemap و لینک‌های داخلی به آدرس متفاوتی اشاره می‌کنند؟ یا شاید ریدایرکت‌ها و مشکلات فنی باعث شده‌اند سیگنال‌های متناقضی به گوگل ارسال شود؟
در این مقاله بررسی می‌کنیم وقتی گوگل صفحه اشتباهی را به‌عنوان Canonical انتخاب می‌کند چه کنیم، چگونه در Search Console علت را پیدا کنیم و برای صفحات محصول، دسته‌بندی، فیلترها، محصولات متغیر و URLهای قدیمی چه روشی مناسب است. همچنین دستورهای فنی بررسی، جدول تصمیم‌گیری و چک‌لیست کامل رفع مشکل را ارائه می‌کنیم.
Canonical به آدرسی گفته می‌شود که گوگل آن را نسخه اصلی یا نماینده یک مجموعه از صفحات تکراری یا بسیار مشابه در نظر می‌گیرد.
ممکن است یک محصول از چند آدرس قابل دسترسی باشد؛ مثلاً یک URL اصلی، یک آدرس دارای پارامتر تبلیغاتی و یک URL دارای پارامتر مرتب‌سازی یا ردیابی.
اگر محتوای اصلی این آدرس‌ها یکسان باشد، گوگل معمولاً تلاش می‌کند یک نسخه را به‌عنوان Canonical انتخاب کند تا لازم نباشد تمام نسخه‌های تکراری به‌شکل مستقل در نتایج جست‌وجو نمایش داده شوند.
طبق مستندات رسمی Google Search Central درباره Canonicalization، گوگل محتوای اصلی صفحات را بررسی می‌کند و URLهایی را که محتوای یکسان یا بسیار مشابه دارند در یک مجموعه قرار می‌دهد. سپس براساس سیگنال‌های مختلف، یکی از آن‌ها را به‌عنوان نماینده انتخاب می‌کند.
نکته کلیدی: تعیین Canonical در کد سایت، اعلام ترجیح مدیر سایت است؛ نه دستوری که گوگل موظف باشد در تمام شرایط از آن پیروی کند.
در Google Search Console دو مفهوم مهم وجود دارد که باید از یکدیگر تفکیک شوند.
| عنوان | معنا | تعیین‌کننده |
|---|---|---|
| User-declared canonical | آدرسی که سایت به‌عنوان نسخه اصلی معرفی کرده است | تنظیمات و سیگنال‌های سایت |
| Google-selected canonical | آدرسی که گوگل در پردازش خود به‌عنوان نسخه اصلی انتخاب کرده است | سیستم‌های گوگل |
برای مثال، ممکن است سایت شما آدرس https://example.com/products/model-a را به‌عنوان Canonical معرفی کرده باشد، اما گوگل آدرس https://example.com/products/model-a-new را ترجیح دهد.
اگر هر دو آدرس واقعاً یک محصول یکسان را نمایش می‌دهند و آدرس دوم نسخه اصلی مطلوب شماست، این انتخاب ممکن است مشکل خاصی نداشته باشد.
اما اگر دو آدرس مربوط به دو محصول مستقل هستند یا گوگل آدرس قدیمی، نامعتبر یا نامرتبط را ترجیح داده، باید علت را بررسی کنید.
در راهنمای رسمی گوگل برای رفع مشکلات Canonicalization نیز تأکید شده است که اولین مرحله، بررسی Canonical انتخاب‌شده و ارزیابی این موضوع است که آیا URL منتخب گوگل واقعاً برای کاربران مناسب‌تر است یا خیر.
خیر. وجود اختلاف میان Canonical معرفی‌شده و انتخاب‌شده، به‌تنهایی به معنی جریمه شدن سایت یا وجود مشکل جدی نیست.
فرض کنید صفحه محصول با این دو آدرس قابل دسترسی است:
https://example.com/products/bag-25
https://example.com/products/bag-25?utm_source=instagram
اگر محتوای اصلی هر دو نسخه یکسان باشد، طبیعی است که URL بدون پارامتر تبلیغاتی به‌عنوان Canonical انتخاب شود.
همچنین ممکن است گوگل برای نسخه HTTP و HTTPS یک صفحه، آدرس HTTPS را ترجیح دهد؛ البته به شرط آنکه مشکلات فنی یا سیگنال‌های متناقض وجود نداشته باشند.
زمانی باید نگران باشید که گوگل صفحه‌ای را انتخاب کند که از نظر هدف، محصول یا محتوای اصلی نباید جایگزین صفحه موردنظر شما شود.
برای تشخیص این موضوع، ابتدا باید محتوای دو صفحه و علت واقعی وجود چند URL را بررسی کنید.
در بخش Page Indexing سرچ کنسول چند وضعیت مرتبط با صفحات تکراری وجود دارد. این وضعیت‌ها یک معنی ندارند و نباید برای همه آن‌ها یک راه‌حل اجرا شود.
| وضعیت | معنا | اقدام اولیه |
|---|---|---|
| Alternate page with proper canonical tag | صفحه به‌عنوان نسخه جایگزین دارای Canonical مناسب شناخته شده است | بررسی عمدی بودن این وضعیت |
| Duplicate without user-selected canonical | گوگل صفحه را تکراری شناخته و نسخه اصلی را خود انتخاب کرده است | بررسی محتوای دو URL و ترجیح سایت |
| Duplicate, Google chose different canonical than user | گوگل نسخه متفاوتی از Canonical معرفی‌شده را ترجیح داده است | مقایسه دو Canonical و بررسی سیگنال‌ها |
| Crawled - currently not indexed | گوگل صفحه را خزش کرده اما فعلاً ایندکس نکرده است | بررسی علت‌های مختلف؛ نه صرفاً Canonical |
| Page with redirect | آدرس به مقصد دیگری هدایت می‌شود | بررسی درستی مقصد انتقال |
طبق راهنمای رسمی گزارش Page Indexing، وضعیت Duplicate, Google chose different canonical than user زمانی نمایش داده می‌شود که گوگل URL دیگری را نسبت به نسخه معرفی‌شده از طرف سایت مناسب‌تر تشخیص دهد.
این گزارش به معنی آن نیست که باید تمام URLهای موجود را به‌اجبار ایندکس کنید. ممکن است وجود نسخه جایگزین دقیقاً همان رفتاری باشد که از سیستم انتظار داریم.
اولین مرحله رفع مشکل، استفاده از ابزار URL Inspection در Google Search Console است.
اگر گوگل یک آدرس متفاوت انتخاب کرده است، آن آدرس را نیز جداگانه در URL Inspection بررسی کنید.
نکته بسیار مهم: طبق راهنمای رسمی URL Inspection، مقدار Google-selected canonical از اطلاعات ایندکس‌شده گوگل به دست می‌آید. تست زنده یا Test Live URL نمی‌تواند پیش‌بینی کند گوگل در فرایند ایندکس نهایی کدام Canonical را انتخاب خواهد کرد.
بنابراین اگر تست زنده صفحه موفق باشد، به این معنی نیست که اختلاف Canonical حتماً اصلاح شده است.
بعد از شناسایی دو URL، باید بررسی کنید چرا گوگل آن‌ها را مشابه تشخیص داده است.
فرض کنید یک فروشگاه دو صفحه برای گوشی یک برند دارد. صفحه اول نسخه ۱۲۸ گیگابایتی و صفحه دوم نسخه ۲۵۶ گیگابایتی را معرفی می‌کند.
اگر عنوان، توضیحات، تصاویر، قیمت و مشخصات هر دو صفحه تقریباً یکسان باشند و فقط یک عدد کوچک در بخشی از صفحه تغییر کرده باشد، ممکن است درک تفاوت واقعی آن‌ها برای سیستم‌های پردازش دشوارتر شود.
اما راه‌حل این نیست که صرفاً چند پاراگراف بی‌ارتباط برای متفاوت کردن صفحات اضافه کنیم.
راهکار: تفاوت واقعی محصولات را در عنوان، مشخصات، قیمت، موجودی، تصاویر و گزینه خرید به‌درستی نشان دهید. اگر دو صفحه واقعاً یک محصول را معرفی می‌کنند، شاید اصلاً نیازی به ایندکس مستقل هر دو نباشد.
برای مقایسه دو صفحه، موارد زیر را بررسی کنید: عنوان اصلی H1، توضیحات محصول، SKU، مدل، برند، ویژگی‌های اصلی، تصویر، قیمت، وضعیت موجودی و هدف خرید.
اگر تفاوت فقط پارامتر تبلیغاتی یا شیوه مرتب‌سازی یک فهرست است، Canonical مشترک می‌تواند کاملاً منطقی باشد.
یکی از روش‌های اصلی اعلام URL ترجیحی، استفاده از تگ rel='canonical' در بخش head صفحه HTML است.
برای مثال، اگر نسخه اصلی یک محصول آدرس زیر باشد:
https://example.com/products/model-a
می‌توان در کد HTML نسخه اصلی یا نسخه‌های واقعاً تکراری، متناسب با معماری سایت، تگی مانند این قرار داد:
<link rel='canonical' href='https://example.com/products/model-a'>این تگ به گوگل اعلام می‌کند که آدرس مشخص‌شده، نسخه ترجیحی سایت است.
اما طبق مستندات رسمی گوگل درباره معرفی Canonical، این سیگنال قوی است، ولی دستور قطعی محسوب نمی‌شود.
اگر محتوا یا سایر سیگنال‌های سایت با این ترجیح تناقض داشته باشند، گوگل ممکن است URL دیگری را انتخاب کند.
پیشنهاد فنی: برای صفحات مستقلی که قرار است ایندکس شوند، از Canonical مناسب و در صورت کاربرد از Self-referencing Canonical استفاده کنید. آدرس معرفی‌شده باید واقعی، قابل دسترسی و متناسب با محتوای همان صفحه باشد.
Self-referencing Canonical یعنی صفحه، آدرس خودش را به‌عنوان نسخه اصلی معرفی کند.
برای مثال، صفحه محصول با آدرس https://example.com/products/wood-chair در کد خود نیز همین آدرس را به‌عنوان Canonical داشته باشد.
این روش برای بسیاری از صفحات مستقل و قابل ایندکس، ساختار واضحی ایجاد می‌کند.
بااین‌حال Self-referencing Canonical تضمین نمی‌کند گوگل همان URL را انتخاب کند. اگر صفحه از نظر محتوا تکراری باشد یا سیگنال‌های دیگر خلاف آن را نشان دهند، گوگل ممکن است تصمیم متفاوتی بگیرد.
اشتباه رایج: تصور کنیم افزودن Canonical به خود صفحه، بدون اصلاح محتوای تکراری، ریدایرکت و لینک‌های داخلی، همیشه مشکل را حل می‌کند.
بهتر است Self-referencing Canonical را بخشی از یک ساختار فنی هماهنگ بدانیم؛ نه راه‌حلی مستقل برای تمام مشکلات ایندکس.
علت انتخاب Canonical متفاوت ممکن است یک یا چند عامل باشد. گاهی تنظیمات اشتباه سایت باعث ارسال سیگنال متناقض می‌شود و گاهی خود محتوای صفحه نشان می‌دهد URL دیگری نسخه مناسب‌تری است.
| علت احتمالی | نمونه مشکل | اقدام پیشنهادی |
|---|---|---|
| محتوای بسیار مشابه | دو صفحه محصول تفاوت واقعی مشخصی ندارند | بررسی نیاز به صفحات مستقل |
| Canonical اشتباه | صفحه محصول به دسته‌بندی اشاره می‌کند | اصلاح تگ در قالب یا تنظیمات |
| سیگنال‌های متناقض | Canonical به A و Sitemap به B اشاره می‌کند | هماهنگ کردن URL اصلی |
| ریدایرکت نامناسب | URL منتخب سایت به آدرس دیگری منتقل می‌شود | اصلاح مسیر انتقال |
| لینک‌سازی داخلی نامنظم | اغلب لینک‌ها به نسخه پارامتردار می‌روند | لینک‌دهی به URL ترجیحی |
| مشکل دسترسی | نسخه مطلوب خطای سرور یا دسترسی دارد | بررسی پاسخ و سلامت صفحه |
| اختلاف HTTP و HTTPS | Canonical یا ریدایرکت به نسخه ناامن اشاره دارد | یکسان‌سازی نسخه اصلی |
| جاوااسکریپت | Canonical یا محتوا پس از رندر تغییر می‌کند | اصلاح خروجی HTML و رندر |
| مشکلات چندزبانه | ارتباط نسخه‌های منطقه‌ای درست معرفی نشده | بررسی Canonical و hreflang |
برای تشخیص علت واقعی، بهتر است فقط یک URL را بررسی نکنید. نسخه انتخاب‌شده توسط گوگل، مقصد ریدایرکت، صفحه اصلی محصول و لینک‌های مرتبط نیز باید بررسی شوند.
نقشه سایت XML یکی از سیگنال‌هایی است که گوگل برای شناسایی URLهای مهم و ترجیحی استفاده می‌کند.
فرض کنید صفحه محصول در HTML خود آدرس A را Canonical معرفی کرده است، اما در Sitemap آدرس B ثبت شده و هر دو URL محتوای مشابهی ارائه می‌دهند.
در چنین شرایطی، سایت ترجیح یکدستی ارائه نمی‌کند.
طبق مستندات Google Search Central، Sitemap نسبت به Canonical و ریدایرکت سیگنال ضعیف‌تری است؛ اما هماهنگ بودن آن‌ها می‌تواند به روشن‌تر شدن ترجیح سایت کمک کند.
راهکار: برای هر صفحه قابل ایندکس، URL اصلی را مشخص کنید و همان آدرس را در نقشه سایت، Canonical و لینک‌های داخلی مرتبط استفاده کنید.
آدرس‌هایی که صرفاً نسخه تکراری و غیرترجیحی هستند، معمولاً نباید به‌عنوان صفحات اصلی قابل ایندکس در Sitemap معرفی شوند.
همچنین وجود URL در Sitemap تضمین نمی‌کند گوگل آن را ایندکس یا به‌عنوان Canonical انتخاب کند.
در فروشگاه اینترنتی، لینک‌های داخلی معمولاً در منو، دسته‌بندی‌ها، محصولات مرتبط، جست‌وجوی داخلی و بلاگ قرار دارند.
اگر بیشتر این لینک‌ها به URL غیرترجیحی اشاره کنند، سایت ممکن است سیگنال‌های ناسازگاری به گوگل بدهد.
برای مثال، اگر نسخه اصلی محصول /products/model-a است اما لینک‌های دسته‌بندی به /products/model-a?sort=popular اشاره می‌کنند، بهتر است علت این طراحی بررسی شود.
در راهنمای رسمی گوگل توصیه شده است که لینک‌های داخلی تا حد امکان به URL ترجیحی یا Canonical اشاره کنند.
نکته: همه پارامترها لزوماً نامعتبر نیستند. بعضی پارامترها برای انتخاب تنوع محصول یا عملکرد واقعی سایت لازم‌اند. بنابراین حذف عمومی تمام پارامترها از لینک‌ها بدون بررسی کاربردشان، تصمیم مناسبی نیست.
بهتر است الگوهای مختلف لینک‌دهی را بررسی و مشخص کنید کدام URLها نماینده اصلی محتوا هستند.
یکی از مهم‌ترین سناریوهای Canonical در فروشگاه‌های اینترنتی، مدیریت محصولات متغیر است.
فرض کنید یک مدل کفش در چند رنگ و سایز عرضه می‌شود. ممکن است فروشگاه تمام تنوع‌ها را در یک صفحه نمایش دهد یا برای هر رنگ و اندازه آدرس متفاوتی داشته باشد.
این دو معماری از نظر سئو یکسان نیستند.
در این حالت، مشتری از داخل صفحه محصول رنگ و سایز را انتخاب می‌کند و تصویر، قیمت و موجودی متناسب با انتخاب او تغییر می‌کنند.
ممکن است URLهایی با پارامترهایی مانند ?color=blue یا ?size=42 برای انتخاب مستقیم تنوع وجود داشته باشند.
طبق راهنمای رسمی Product Variants گوگل، برای معماری تک‌صفحه‌ای معمولاً یک URL اصلی برای گروه محصول در نظر گرفته می‌شود و تنوع‌ها می‌توانند با URLهای قابل انتخاب از یکدیگر مشخص شوند.
در چنین ساختاری، استفاده از Canonical صفحه پایه برای نسخه‌های پارامتردار می‌تواند متناسب با معماری سایت باشد.
گاهی هر تنوع مهم، صفحه جداگانه با محتوای کامل، تصویر، قیمت، موجودی و امکان خرید مستقیم دارد.
در این حالت، اگر صفحات واقعاً به‌عنوان نسخه‌های مستقل و ارزشمند طراحی شده‌اند، Canonical کردن کورکورانه تمام آن‌ها به یک URL عمومی ممکن است مناسب نباشد.
در معماری چندصفحه‌ای معرفی‌شده توسط گوگل، صفحه‌های تنوع می‌توانند هویت و URL مستقل داشته باشند و رابطه آن‌ها با گروه محصول از طریق داده ساختاریافته مناسب مشخص شود.
قاعده: قبل از تغییر Canonical محصولات متغیر، مشخص کنید فروشگاه از معماری تک‌صفحه‌ای یا چندصفحه‌ای استفاده می‌کند و آیا URL هر تنوع واقعاً محتوای مستقل و قابل خرید ارائه می‌دهد.
نباید فقط به این دلیل که همه تنوع‌ها نام مدل مشترکی دارند، تفاوت‌های مهم آن‌ها را از دید مشتری و گوگل حذف کرد.
این مثال یکی از سناریوهای قابل درک در فروش محصولات دیجیتال است.
فرض کنید دو URL مستقل دارید:
https://example.com/phone-x-128
https://example.com/phone-x-256
اگر گوگل نسخه ۱۲۸ گیگابایتی را Canonical نسخه ۲۵۶ گیگابایتی انتخاب کرده است، ابتدا باید بررسی کنید آیا سیستم شما این دو را به‌عنوان تنوع یک محصول اصلی مدیریت می‌کند یا دو صفحه کاملاً مستقل ساخته است.
اگر صفحات مستقل‌اند، باید مطمئن شوید هر کدام عنوان و مشخصات واقعی مربوط به همان ظرفیت، قیمت و موجودی درست و امکان خرید همان نسخه را نمایش می‌دهد.
در صورتی که تصویر، محتوا و اطلاعات محصول در هر دو صفحه اشتباه یا یکسان ثبت شده باشند، ابتدا داده اصلی را اصلاح کنید.
اگر قصد دارید هر دو URL مستقل بمانند، Canonical خودارجاع و لینک‌دهی مناسب هر نسخه را نیز بررسی کنید.
هشدار: افزودن متن بی‌ارزش فقط برای افزایش تفاوت صفحات، راهکار مناسبی نیست. تفاوت باید ناشی از ویژگی واقعی محصول و تجربه خرید مستقل باشد.
ممکن است فروشگاه یک دسته اصلی مانند «کفش مردانه» و چند دسته تخصصی مانند «کفش رسمی مردانه» و «کفش ورزشی مردانه» داشته باشد.
اگر دسته‌های تخصصی محصولات و هدف جست‌وجوی متفاوتی دارند، انتخاب دسته اصلی به‌عنوان Canonical همه آن‌ها ممکن است باعث شود صفحات تخصصی به‌صورت مستقل بررسی یا ایندکس نشوند.
برای مثال، اگر صفحه کفش رسمی دارای مجموعه واقعی محصولات رسمی است، نباید بدون دلیل آن را تکرار کامل صفحه عمومی کفش مردانه فرض کرد.
راهکار: ساختار دسته‌ها، محصولات نمایش‌داده‌شده، عنوان H1، توضیحات و لینک‌های داخلی را بررسی کنید. اگر دسته واقعاً مستقل است، URL اصلی و Canonical آن باید با هدف صفحه هماهنگ باشند.
در مقابل، اگر دو دسته فقط نام متفاوت دارند و دقیقاً همان مجموعه محصولات و محتوای مشابه را ارائه می‌کنند، بهتر است درباره ادغام ساختاری آن‌ها تصمیم بگیرید.
ایجاد صفحات تکراری متعدد تنها برای هدف‌گیری ترکیب‌های مختلف کلمات کلیدی، لزوماً ارزش سئویی ایجاد نمی‌کند.
یکی از اشتباهات فنی رایج در سایت‌های فروشگاهی، تنظیم Canonical تمام صفحات صفحه‌بندی‌شده روی صفحه اول دسته‌بندی است.
فرض کنید یک دسته شامل ۱۲۰ محصول است و محصولات در چهار صفحه نمایش داده می‌شوند.
صفحه اول ۳۰ محصول ابتدایی را نمایش می‌دهد و صفحه دوم شامل ۳۰ محصول متفاوت است.
اگر Canonical صفحه دوم به صفحه اول اشاره کند، درحالی‌که این دو مجموعه محتوای یکسانی ندارند، ترجیح سایت ممکن است با ماهیت واقعی صفحات سازگار نباشد.
طبق راهنمای رسمی Pagination گوگل، صفحات یک مجموعه صفحه‌بندی‌شده باید URL مستقل داشته باشند و نباید صفحه اول را به‌صورت عمومی Canonical تمام صفحات بعدی قرار داد.
برای مثال، این URLها می‌توانند صفحات مستقل باشند:
https://example.com/category/shoes?page=1
https://example.com/category/shoes?page=2
https://example.com/category/shoes?page=3
روش پیشنهادی: برای هر صفحه معتبر از صفحه‌بندی، Canonical متناسب با همان URL تعیین کنید و لینک‌های قابل خزش برای دسترسی به صفحات بعدی داشته باشید.
همچنین استفاده از تگ‌های rel='next' و rel='prev' به‌تنهایی راه‌حل نیست؛ زیرا گوگل دیگر از آن‌ها برای تشخیص رابطه صفحات صفحه‌بندی‌شده استفاده نمی‌کند.
فروشگاه‌های اینترنتی معمولاً فیلترهایی مانند رنگ، برند، قیمت و موجودی دارند. این فیلترها ممکن است تعداد زیادی URL تولید کنند.
برای مثال:
https://example.com/shoes?color=black
https://example.com/shoes?sort=price
https://example.com/shoes?brand=alpha&size=42
در بعضی موارد، این آدرس‌ها فقط روش دیگری برای نمایش مجموعه‌ای از محصولات هستند و ارزش ایندکس مستقل ندارند.
اما در بعضی کسب‌وکارها، یک فیلتر خاص ممکن است صفحه فرود مستقلی با مجموعه محصولات و هدف جست‌وجوی مشخص ایجاد کند.
راهکار: ابتدا تعیین کنید کدام فیلترها باید قابل ایندکس باشند و کدام فقط برای استفاده تعاملی مشتری ایجاد شده‌اند.
برای نسخه‌هایی که صرفاً ترتیب نمایش یک فهرست را تغییر می‌دهند، Canonical به نسخه اصلی می‌تواند مناسب باشد؛ مشروط بر اینکه محتوا واقعاً معادل باشد.
اما برای صفحات فیلتری که به‌صورت مستقل هدف‌گذاری شده‌اند، باید ساختار URL، محتوای واقعی و سیاست ایندکس جداگانه بررسی شود.
گوگل در راهنمای مدیریت Faceted Navigation توضیح می‌دهد که تعداد زیاد URLهای فیلتر می‌تواند منابع خزش را مصرف کند و بهتر است از ابتدا درباره نحوه خزش و ایندکس آن‌ها تصمیم مشخصی وجود داشته باشد.
نکته مهم: Canonical، noindex و robots.txt ابزارهای متفاوتی هستند. نباید برای تمام URLهای فیلتر، بدون بررسی هدف و معماری سایت، از یک قاعده کلی استفاده کرد.
گاهی مدیر سایت وقتی متوجه می‌شود گوگل URL نامطلوبی را به‌عنوان Canonical انتخاب کرده است، روی آن صفحه noindex قرار می‌دهد.
اما noindex برای اعلام این است که یک صفحه نباید در نتایج گوگل حضور داشته باشد. این دستور ابزار اصلی تعیین Canonical میان صفحات تکراری نیست.
اگر صفحه‌ای را که قرار است ایندکس شود noindex کنید، ممکن است برخلاف هدف اصلی خود عمل کرده باشید.
در مستندات Google Search Central نیز استفاده از noindex برای اجبار انتخاب Canonical در یک سایت توصیه نشده است؛ زیرا می‌تواند صفحه را کاملاً از نتایج جست‌وجو کنار بگذارد.
راهکار: اگر هدف شما مشخص کردن نسخه اصلی میان چند URL مشابه است، ابتدا Canonical و سایر سیگنال‌های مربوط را اصلاح کنید.
اگر صفحه‌ای واقعاً نباید ایندکس شود، noindex ممکن است برای همان هدف کاربرد داشته باشد، اما تصمیم باید مستقل از مسئله انتخاب Canonical گرفته شود.
فایل robots.txt برای کنترل دسترسی خزنده‌ها به مسیرهای سایت استفاده می‌شود. این فایل به‌خودی‌خود ابزار تعیین نسخه اصلی محتوا نیست.
اگر URLهای تکراری را با robots.txt مسدود کنید، ممکن است گوگل نتواند محتوای آن‌ها یا تگ Canonical داخل صفحه را ببیند.
بنابراین اگر هدف شما انتقال سیگنال Canonical از صفحه تکراری به صفحه اصلی است، مسدودسازی خزش ممکن است با آن هدف سازگار نباشد.
طبق مستندات رسمی گوگل، استفاده از robots.txt برای Canonicalization توصیه نشده است. همچنین مسدود بودن یک URL لزوماً تضمین نمی‌کند آدرس آن هرگز در نتایج شناسایی نشود.
نکته: برای بعضی الگوهای URL فیلتر که اصلاً نیازی به خزش ندارند، محدودسازی از طریق robots.txt می‌تواند بخشی از سیاست مدیریت خزش باشد. اما این موضوع با رفع اختلاف Canonical یک صفحه مشخص تفاوت دارد.
ریدایرکت دائمی یکی از سیگنال‌های قوی برای معرفی مقصد اصلی است.
فرض کنید محصولی از URL قدیمی به آدرس جدید منتقل شده و قرار نیست آدرس قدیمی به‌صورت مستقل باقی بماند.
در این حالت، استفاده از ریدایرکت دائمی به مقصد جدید می‌تواند مناسب باشد.
برای مثال:
https://example.com/old-product
به آدرس زیر منتقل شود:
https://example.com/products/new-product
به شرط آنکه مقصد واقعاً همان محصول یا جانشین مناسب آن باشد.
اما اگر هر دو صفحه باید برای کاربر قابل دسترسی و دارای هدف مستقل باشند، ریدایرکت کردن یکی به دیگری ممکن است تصمیم اشتباهی باشد.
اصل مهم: ریدایرکت برای انتقال واقعی URL استفاده می‌شود، نه برای وادار کردن گوگل به انتخاب یک صفحه نامرتبط.
در راهنمای رسمی ریدایرکت گوگل، انتقال دائمی به‌عنوان یکی از روش‌های مشخص کردن مقصد ترجیحی معرفی شده است.
آدرسی که به‌عنوان نسخه اصلی معرفی می‌شود باید از نظر فنی سالم و متناسب با محتوا باشد.
فرض کنید صفحه A در تگ Canonical خود به B اشاره می‌کند، اما B حذف شده و پاسخ 404 می‌دهد.
یا B چند مرحله ریدایرکت می‌شود و در نهایت به صفحه‌ای نامرتبط می‌رسد.
این ساختار می‌تواند سیگنال Canonical نامطمئن یا متناقضی ایجاد کند.
راهکار: مقصد Canonical را بررسی کنید. اگر URL جدید و معتبر وجود دارد، آدرس نهایی مناسب را در Canonical و دیگر سیگنال‌های مربوط معرفی کنید.
همچنین از زنجیره‌های طولانی و غیرضروری ریدایرکت پرهیز کنید و مطمئن شوید URL نهایی با محتوای واقعی صفحه ارتباط دارد.
اگر صفحه واقعاً حذف شده و دیگر مقصد معادلی ندارد، باید درباره 404 یا 410 تصمیم بگیرید؛ نه اینکه Canonical آن را به صفحه اصلی فروشگاه تغییر دهید.
ممکن است یک فروشگاه از طریق هر دو نسخه HTTP و HTTPS قابل دسترسی باشد.
اگر سایت آدرس HTTPS را به‌عنوان نسخه اصلی انتخاب کرده، اما در بعضی صفحات تگ Canonical به HTTP اشاره کند، سیگنال‌های ناسازگاری ایجاد می‌شود.
گوگل معمولاً نسخه HTTPS را به نسخه HTTP ترجیح می‌دهد، اما طبق مستندات رسمی، مشکلات گواهی SSL، ریدایرکت و برخی تنظیمات فنی می‌توانند این ترجیح را تحت تأثیر قرار دهند.
راهکار: نسخه اصلی دامنه را مشخص کنید. سپس ریدایرکت‌ها، Canonical، Sitemap و لینک‌های داخلی را با همان ساختار هماهنگ کنید.
برای مثال، اگر نسخه اصلی سایت https://example.com است، بهتر است آدرس‌های اصلی محصول نیز در همین ساختار معرفی شوند.
همچنین وضعیت دامنه با www و بدون www باید مطابق سیاست فنی سایت بررسی شود تا چند نسخه نامنظم از یک محتوا ایجاد نشود.
هنگام انتقال فروشگاه از دامنه قدیمی به دامنه جدید، ممکن است بخشی از تنظیمات سایت همچنان به دامنه قبلی اشاره کنند.
برای مثال، صفحات دامنه جدید باز می‌شوند، اما تگ Canonical داخل HTML هنوز URL دامنه قدیمی را نشان می‌دهد.
یا Sitemap جدید با آدرس‌های دامنه تازه ساخته شده، اما لینک‌های داخلی و ریدایرکت‌های اصلی به مسیرهای قدیمی اشاره می‌کنند.
در چنین شرایطی، گوگل ممکن است در تعیین نسخه اصلی با سیگنال‌های متناقض روبه‌رو شود.
راهکار: برای انتقال دامنه، جدول نگاشت URLهای قدیمی و جدید داشته باشید. ریدایرکت‌های دائمی را به مقصد متناظر تنظیم کنید و Canonical و Sitemap را با ساختار نهایی هماهنگ نگه دارید.
همچنین مطمئن شوید دامنه جدید پاسخ مناسب می‌دهد و محتوای واقعی صفحات در مقصد قابل دریافت است.
اگر نسخه قدیمی و جدید هر دو بدون برنامه به‌شکل مستقل قابل دسترسی بمانند، احتمال ایجاد وضعیت تکراری و انتخاب ناخواسته Canonical افزایش پیدا می‌کند.
در بعضی فروشگاه‌های اینترنتی، بخش بزرگی از صفحه با جاوااسکریپت تولید می‌شود.
ممکن است سرور در HTML اولیه یک Canonical مشخص قرار دهد، اما بعد از اجرای JavaScript همان مقدار تغییر کند.
برای مثال، HTML اولیه به صفحه اصلی محصول اشاره می‌کند، ولی جاوااسکریپت پس از انتخاب یک تنوع، Canonical را به URL دیگری تبدیل می‌کند.
گوگل در راهنمای خود توصیه می‌کند Canonical تا حد امکان در HTML اولیه مشخص و پایدار باشد و JavaScript بدون دلیل آن را تغییر ندهد.
راهکار: محتوای HTML اولیه و خروجی رندرشده را مقایسه کنید. اگر تگ Canonical در دو مرحله متفاوت است، علت فنی آن را بررسی کنید.
در فروشگاه‌هایی که رندر سمت سرور یا SSR دارند، بهتر است خروجی نهایی هر URL با هویت واقعی همان صفحه هماهنگ باشد.
اگر سیستم به‌ناچار Canonical را از طریق JavaScript تولید می‌کند، باید از ایجاد تگ‌های متناقض یا تغییرهای ناخواسته جلوگیری شود.
اگر فروشگاه نسخه فارسی، انگلیسی یا زبان‌های دیگر دارد، باید رابطه آن‌ها را به‌درستی معرفی کند.
ممکن است یک سایت برای یک محصول دو صفحه فارسی و انگلیسی داشته باشد که محتوای اصلی آن‌ها واقعاً ترجمه شده است.
در چنین شرایطی، Canonical کردن همه زبان‌ها به یک زبان واحد بدون توجه به هدف صفحات می‌تواند مناسب نباشد.
گوگل برای ارتباط نسخه‌های زبانی و منطقه‌ای از راهکارهایی مانند hreflang استفاده می‌کند.
نکته مهم: hreflang و Canonical دو مفهوم متفاوت هستند. Canonical به نسخه نماینده محتوا اشاره می‌کند، درحالی‌که hreflang برای معرفی نسخه‌های زبانی یا منطقه‌ای مرتبط کاربرد دارد.
برای صفحات چندزبانه، باید بررسی شود هر صفحه دارای محتوای واقعی همان زبان است و Canonical آن به نسخه مناسب اشاره می‌کند.
اگر دو صفحه فقط منو و فوتر ترجمه‌شده دارند، ولی محتوای اصلی یکسان باقی مانده، ممکن است گوگل آن‌ها را مشابه تشخیص دهد.
گاهی در URL Inspection مشاهده می‌شود Google-selected canonical به دامنه‌ای خارج از سایت اشاره دارد.
این وضعیت می‌تواند علت‌های متفاوتی داشته باشد.
برای مثال، ممکن است سایت شما نسخه کپی‌شده محتوایی از منبع دیگر باشد. گاهی نیز تنظیمات اشتباه سرور یا تگ Canonical باعث اشاره به دامنه خارجی شده‌اند.
در موارد خاص، نفوذ امنیتی یا تغییر غیرمجاز کد نیز ممکن است Canonical یا ریدایرکت خارجی ایجاد کند.
طبق راهنمای رفع خطاهای Canonical گوگل، تنظیم نادرست سرور، کدهای Canonical اشتباه و حتی برخی حملات می‌توانند در انتخاب دامنه خارجی نقش داشته باشند.
روش بررسی: ابتدا کد HTML و هدرهای پاسخ را کنترل کنید. سپس ریدایرکت‌ها، تنظیمات سرور، محتوای مقصد و تغییرهای اخیر قالب یا افزونه‌ها را بررسی کنید.
اگر نسخه کپی‌شده بدون مجوزی در سایت دیگر وجود دارد، موضوع باید جداگانه و براساس مستندات واقعی بررسی شود. صرف اینکه دامنه دیگری انتخاب شده، به‌تنهایی اثبات‌کننده سرقت محتوا یا نفوذ امنیتی نیست.
برای عیب‌یابی دقیق، باید هم کد وضعیت HTTP و هم مقدار Canonical صفحه را بررسی کنید.
در خط فرمان، دستور زیر برای مشاهده هدرهای پاسخ قابل استفاده است:
curl -I https://example.com/products/model-aاین دستور درخواست HEAD ارسال می‌کند. توجه کنید بعضی سرورها رفتار HEAD و GET متفاوتی دارند.
برای بررسی کد پاسخ درخواست GET می‌توانید از دستور زیر استفاده کنید:
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/products/model-aاگر پاسخ 200 باشد، سرور درخواست را موفق اعلام کرده است؛ اما این نتیجه به‌تنهایی سلامت Canonical یا ایندکس شدن صفحه را ثابت نمی‌کند.
برای بررسی ریدایرکت، می‌توان هدر Location را مشاهده کرد و مقصد نهایی را جداگانه آزمایش کرد.
برای مشاهده تگ Canonical، کد منبع HTML صفحه را بررسی کنید. در مرورگر نیز می‌توان از ابزارهای توسعه‌دهنده استفاده کرد.
نکته: در صفحات مبتنی بر JavaScript، مقدار Canonical در View Source ممکن است با DOM رندرشده متفاوت باشد. در چنین شرایطی لازم است هر دو بررسی شوند.
همچنین اگر سایت از CDN، کش یا سیستم چندسروری استفاده می‌کند، باید مطمئن شوید نسخه‌های متفاوت پاسخ به کاربران و خزنده‌ها داده نمی‌شوند.
اگر چندین صفحه درگیر مشکل هستند، بررسی موردی بدون ثبت اطلاعات می‌تواند باعث تکرار کار و تصمیم‌های ناسازگار شود.
بهتر است برای URLهای مهم یک جدول کنترل تهیه کنید.
| ستون گزارش | کاربرد |
|---|---|
| URL بررسی‌شده | آدرس مسئله‌دار |
| نوع صفحه | محصول، دسته، بلاگ یا فیلتر |
| کد HTTP | بررسی پاسخ واقعی سرور |
| User-declared canonical | نسخه معرفی‌شده توسط سایت |
| Google-selected canonical | نسخه انتخاب‌شده توسط گوگل |
| URL مطلوب | نسخه‌ای که براساس معماری سایت باید اصلی باشد |
| تفاوت محتوایی | دلیل استقلال یا تکراری بودن صفحات |
| وضعیت Sitemap | وجود یا نبود URL ترجیحی |
| وضعیت لینک‌های داخلی | آدرس‌هایی که سایت به آن‌ها لینک می‌دهد |
| علت احتمالی | فرضیه فنی یا محتوایی |
| اقدام اصلاحی | تغییر اجراشده |
| نتیجه پیگیری | وضعیت پس از خزش و پردازش مجدد |
این جدول کمک می‌کند خطاهای مربوط به قالب یا فروشگاه‌ساز را از مشکلات اختصاصی چند محصول جدا کنید.
برای مثال، اگر صدها صفحه محصول به صفحه دسته‌بندی Canonical شده‌اند، ممکن است علت در قالب مشترک صفحات باشد. اما اگر فقط دو محصول شبیه به هم چنین وضعیتی دارند، بررسی محتوای همان دو صفحه اولویت بیشتری دارد.
فرض کنید فروشگاهی ۵۰۰ محصول دارد و در Search Console مشاهده می‌کند ۴۰ URL با وضعیت Duplicate, Google chose different canonical than user گزارش شده‌اند.
پس از بررسی نمونه‌ها، مدیر سایت متوجه می‌شود این ۴۰ آدرس به چهار گروه تقسیم می‌شوند. اعداد زیر فرضی هستند.
| گروه مشکل | تعداد فرضی | اقدام مناسب |
|---|---|---|
| محصولات با پارامتر تبلیغاتی | ۱۰ | تأیید درستی Canonical نسخه اصلی |
| محصولات متغیر با اطلاعات ناقص | ۱۲ | بررسی معماری تنوع‌ها و اصلاح مشخصات واقعی |
| صفحات دسته‌بندی و صفحه‌بندی | ۸ | اصلاح Canonical صفحات مستقل |
| URLهای قدیمی دارای ریدایرکت یا Canonical اشتباه | ۱۰ | اصلاح نگاشت آدرس‌ها و سیگنال‌های متناقض |
در این مثال، هر ۴۰ URL الزاماً مشکل ندارند. ممکن است ده آدرس دارای پارامتر تبلیغاتی دقیقاً همان رفتاری را نشان دهند که از سایت انتظار داریم.
اما برای صفحات دسته‌بندی مستقل یا محصولات دارای نسخه‌های مشخص، باید بررسی بیشتری انجام شود.
در چنین شرایطی، تغییر یکجای Canonical تمام صفحات به URL خودشان، راهکار مطمئنی نیست؛ زیرا ممکن است باعث شود نسخه‌های واقعاً تکراری نیز به‌اشتباه مستقل معرفی شوند.
نتیجه: پیش از اصلاح، باید URLهای واقعاً مشکل‌دار را از موارد طبیعی تفکیک کنیم.
پس از اصلاح، ابتدا مطمئن شوید تغییرات روی نسخه واقعی سایت منتشر شده‌اند.
کد HTML، پاسخ سرور، Sitemap و لینک‌های داخلی مرتبط را دوباره بررسی کنید.
سپس از URL Inspection برای بررسی وضعیت فعلی صفحه و اطلاعات ایندکس استفاده کنید.
در صورت نیاز می‌توانید Test Live URL را اجرا کنید تا وضعیت فعلی دسترسی و رندر صفحه بررسی شود.
اما همان‌طور که اشاره شد، تست زنده انتخاب نهایی Canonical توسط گوگل را پیش‌بینی نمی‌کند.
برای مشاهده نتیجه واقعی انتخاب Canonical، باید منتظر خزش و پردازش مجدد گوگل بمانید و داده ایندکس‌شده را بررسی کنید.
نکته: مدت زمان ثابتی برای تغییر Canonical وجود ندارد. گوگل ممکن است در زمان‌های متفاوتی URLها را دوباره بررسی و پردازش کند.
همچنین درخواست ایندکس یا درخواست اعتبارسنجی، تضمین نمی‌کند URL انتخابی شما حتماً Canonical شود.
خیر. اگر ده‌ها یا صدها URL با مشکل مشترک درگیر هستند، بهتر است ابتدا علت اصلی در قالب، ساختار لینک‌دهی، Sitemap یا تنظیمات سایت برطرف شود.
برای صفحات مهم و معتبر، پس از اصلاح واقعی می‌توان درخواست بررسی مجدد ثبت کرد.
اما ارسال مکرر درخواست ایندکس بدون اصلاح سیگنال‌ها، تضمینی برای تغییر انتخاب Canonical ایجاد نمی‌کند.
برای تعداد زیاد صفحات، سلامت نقشه سایت، لینک‌های داخلی و قابل خزش بودن URLهای اصلی اهمیت دارد.
اصل مهم: درخواست ایندکس یک روش اطلاع‌رسانی به گوگل است، نه ابزاری برای اجبار انتخاب Canonical.
اگر فروشگاه تعداد زیادی URL دارد، ممکن است اصلاح همه موارد در یک مرحله امکان‌پذیر نباشد.
برای اولویت‌بندی، ابتدا صفحاتی را بررسی کنید که برای کسب‌وکار اهمیت بیشتری دارند.
برای مثال، صفحه محصول پرفروش، دسته اصلی با ورودی گوگل یا مقاله‌ای که قبلاً بازدیدکننده داشته است می‌تواند اولویت بالاتری از یک URL پارامتردار بدون هدف ایندکس داشته باشد.
سه معیار پیشنهادی عبارت‌اند از اهمیت تجاری صفحه، میزان اختلاف واقعی URL انتخاب‌شده و احتمال وجود علت مشترک فنی.
همچنین اگر یک تغییر قالب باعث شده تمام محصولات به صفحه اصلی Canonical شوند، رفع آن مشکل سراسری باید پیش از اصلاح موردی URLهای کم‌اهمیت انجام شود.
پیشنهاد: قبل از اجرای تغییرات گسترده، چند نمونه از هر گروه را بررسی کنید و نتیجه اصلاح آزمایشی را بسنجید.
خیر. انتخاب Canonical صحیح می‌تواند به گوگل کمک کند نسخه مناسب‌تر یک محتوا را شناسایی کند، اما به‌تنهایی تضمین‌کننده افزایش رتبه یا کلیک نیست.
ممکن است پس از اصلاح، صفحه مطلوب شما به‌عنوان Canonical انتخاب شود، اما همچنان برای بعضی کلمات کلیدی رتبه مناسبی نداشته باشد.
همچنین ممکن است انتخاب قبلی گوگل کاملاً منطقی بوده و تغییر آن هیچ مزیت واقعی برای کاربران ایجاد نکند.
بهتر است نتیجه را با مجموعه‌ای از شاخص‌ها بررسی کنید؛ از جمله وضعیت ایندکس، URL انتخاب‌شده، کلیک‌های صفحات مهم، نمایش‌ها و کیفیت ترافیک.
نکته تحلیلی: هنگام بررسی عملکرد جست‌وجو باید توجه داشت که گوگل ممکن است سیگنال‌ها و داده‌های مرتبط با نسخه‌های تکراری را به URL اصلی نسبت دهد. بنابراین کاهش نمایش یک URL غیرCanonical همیشه به معنی از دست رفتن تمام عملکرد آن محتوا نیست.
| وضعیت واقعی | اقدام پیشنهادی |
|---|---|
| دو URL دقیقاً محتوای یکسان دارند | انتخاب یک Canonical مشخص و هماهنگ کردن سیگنال‌ها |
| URL دوم فقط پارامتر تبلیغاتی دارد | ترجیح نسخه اصلی بدون پارامتر، در صورت یکسان بودن محتوا |
| محصول واقعاً به آدرس جدید منتقل شده | ریدایرکت دائمی به مقصد متناظر |
| دو صفحه محصول مستقل و متفاوت‌اند | بررسی محتوای اختصاصی، Canonical و معماری تنوع‌ها |
| صفحه دوم دسته محصولات مستقل است | Canonical متناسب با همان URL صفحه‌بندی |
| فیلتر صرفاً ترتیب نمایش را تغییر می‌دهد | بررسی Canonical به فهرست اصلی و سیاست خزش |
| دسته مستقل به دسته عمومی Canonical شده | اصلاح تگ و تقویت تفاوت واقعی و لینک‌های داخلی |
| Canonical به صفحه حذف‌شده اشاره می‌کند | اصلاح مقصد و وضعیت URL |
| نسخه HTTP و HTTPS سیگنال متناقض دارند | یکسان‌سازی نسخه اصلی دامنه |
| دامنه قدیمی پس از مهاجرت انتخاب شده | بررسی ریدایرکت و Canonical و Sitemap دامنه جدید |
| Canonical توسط JavaScript تغییر می‌کند | بررسی HTML اولیه و خروجی رندرشده |
| دامنه خارجی نامرتبط انتخاب شده | بررسی پیکربندی سرور، کد و احتمال مشکل امنیتی |
در Google Search Console، وضعیت‌های مربوط به صفحات تکراری و Canonical را بررسی کنید. URLهای مهم را انتخاب و نمونه‌ها را براساس نوع صفحه گروه‌بندی کنید.
برای هر نمونه، User-declared canonical و Google-selected canonical را ثبت کنید. سپس تعیین کنید انتخاب متفاوت طبیعی است یا با هدف واقعی صفحه تناقض دارد.
عنوان، مشخصات، تصاویر و هدف هر صفحه را با URL منتخب گوگل مقایسه کنید. تفاوت‌های واقعی محصولات و دسته‌ها را شناسایی کنید.
تگ Canonical، پاسخ HTTP، ریدایرکت‌ها، URLهای Sitemap و لینک‌های داخلی را کنترل کنید. اگر مشکل از قالب یا کد مشترک است، علت اصلی را مشخص کنید.
Canonicalهای اشتباه و سیگنال‌های متناقض را اصلاح کنید. برای محصولات متغیر و صفحه‌بندی‌ها، از قاعده متناسب با معماری واقعی استفاده کنید.
خروجی HTML، پاسخ HTTP و رندر صفحه را بررسی کنید. مطمئن شوید صفحات معتبر قابل دسترسی‌اند و ریدایرکت‌های واقعی به مقصد مناسب می‌رسند.
وضعیت فنی اصلاحات را ثبت کنید. برای صفحات مهم می‌توانید درخواست خزش مجدد ارسال کنید و بعداً نتیجه انتخاب Canonical را در داده ایندکس‌شده گوگل پیگیری کنید.
این برنامه برای بررسی و اجرای اصلاحات اولیه است. به معنی آن نیست که گوگل در مدت هفت روز تمام URLها را دوباره پردازش یا Canonical انتخابی را تغییر خواهد داد.
برای کاهش مشکلات Canonical، داشتن ساختاری منظم برای آدرس محصولات، دسته‌بندی‌ها، صفحات متغیر و محتوای سایت اهمیت دارد.
مای‌تارنما یک سایت‌ساز اختصاصی فروشگاهی است که امکانات معرفی‌شده‌ای مانند مدیریت محصولات، محصولات متغیر و چندقیمتی، دسته‌بندی کالاها، وبلاگ، اتصال دامنه اختصاصی و ساختار مناسب برای فعالیت‌های سئو دارد.
این امکانات می‌توانند برای ساخت فروشگاه اینترنتی با محتوای منظم و مدیریت متمرکز محصولات کاربرد داشته باشند.
بااین‌حال باید میان داشتن زیرساخت مناسب سئو و تضمین انتخاب Canonical دلخواه توسط گوگل تفاوت وجود داشته باشد.
انتخاب Canonical در نهایت توسط گوگل انجام می‌شود. همچنین امکاناتی مانند تنظیم دستی Canonical هر صفحه، کنترل Canonical تنوع‌های محصول، مدیریت ریدایرکت‌ها، خروجی Sitemap و تغییر ساختار URL باید براساس نسخه و قابلیت‌های فنی واقعی فروشگاه‌ساز بررسی شوند.
اگر کسب‌وکار شما دارای محصولات متغیر، دسته‌بندی‌های زیاد یا صفحات پارامتردار است، بهتر است پیش از شروع فعالیت گسترده سئو، نحوه تولید Canonical و ساختار URL را با پشتیبانی فنی بررسی کنید.
در تست رایگان ۱۰روزه مای‌تارنما می‌توانید چند صفحه محصول و دسته‌بندی نمونه ایجاد کنید، ساختار URLها را بررسی کنید و درباره امکانات فنی مرتبط با Canonical، Sitemap و مدیریت آدرس‌ها اطلاعات دقیق بگیرید.
زیرا Canonical یک سیگنال ترجیحی است و دستور قطعی نیست. گوگل محتوای اصلی، ریدایرکت‌ها، لینک‌های داخلی، Sitemap و سایر عوامل را نیز بررسی می‌کند و ممکن است URL متفاوتی را مناسب‌تر بداند.
اولی نسخه‌ای است که سایت ترجیح خود را درباره آن اعلام کرده، اما دومی نسخه‌ای است که گوگل پس از بررسی و پردازش به‌عنوان نماینده مجموعه صفحات مشابه انتخاب کرده است.
خیر. این وضعیت به‌تنهایی جریمه نیست. نشان می‌دهد گوگل نسخه متفاوتی را نسبت به ترجیح سایت انتخاب کرده است. باید بررسی شود این انتخاب طبیعی است یا با هدف صفحه تفاوت دارد.
در Google Search Console، URL موردنظر را با URL Inspection بررسی کنید و در اطلاعات ایندکس‌شده صفحه، مقدار Google-selected canonical را مشاهده کنید.
تست زنده برای بررسی دسترسی و رندر فعلی مفید است، اما طبق راهنمای گوگل انتخاب نهایی Canonical را پیش‌بینی نمی‌کند. برای نتیجه واقعی باید داده ایندکس‌شده بعد از پردازش مجدد بررسی شود.
خیر. این تگ می‌تواند ترجیح سایت را روشن کند، اما اگر محتوا و سیگنال‌های دیگر با آن ناسازگار باشند، گوگل همچنان ممکن است URL دیگری را انتخاب کند.
نه در همه معماری‌ها. در ساختار تک‌صفحه‌ای معمولاً URL پایه گروه محصول Canonical مناسبی است؛ اما در ساختار چندصفحه‌ای با تنوع‌های مستقل، باید URLها، مشخصات واقعی و قواعد مربوط جدا بررسی شوند.
طبق راهنمای رسمی گوگل، صفحات صفحه‌بندی‌شده باید URL مستقل و Canonical متناسب با خود داشته باشند. تنظیم عمومی Canonical همه صفحات روی صفحه اول توصیه نمی‌شود.
Canonical می‌تواند به گوگل در انتخاب نماینده صفحات مشابه کمک کند، اما URLهای فیزیکی را حذف نمی‌کند. اگر آدرس قدیمی واقعاً کنار گذاشته شده، ممکن است ریدایرکت دائمی مناسب‌تر باشد.
به‌عنوان راه‌حل عمومی خیر. noindex برای خارج کردن صفحه از نتایج است و می‌تواند برخلاف هدف ایندکس شدن صفحه عمل کند. برای تعیین نسخه اصلی معمولاً سیگنال Canonical مناسب‌تر است.
خیر. robots.txt ابزار مدیریت دسترسی خزش است، نه تعیین URL اصلی. مسدود کردن URL می‌تواند مانع مشاهده محتوای صفحه و تگ Canonical آن توسط گوگل شود.
باید مقصد معرفی‌شده را اصلاح کنید. URL اصلی مناسب باید از نظر فنی معتبر و مرتبط با محتوا باشد. اگر صفحه حذف شده، وضعیت آن را با پاسخ HTTP مناسب مدیریت کنید.
بله، اما سیگنال ضعیف‌تری نسبت به ریدایرکت و تگ Canonical است. بهتر است آدرس‌های اصلی موجود در Sitemap با Canonical و لینک‌های داخلی هماهنگ باشند.
ابتدا محتوای دو دامنه، تگ‌های Canonical، ریدایرکت و تنظیمات سرور را بررسی کنید. در شرایط خاص، خطای پیکربندی، محتوای کپی‌شده یا مشکل امنیتی ممکن است نقش داشته باشند.
زمان ثابتی وجود ندارد. گوگل باید URLها را دوباره خزش و پردازش کند. درخواست ایندکس می‌تواند به پیگیری کمک کند، اما تغییر انتخاب Canonical را تضمین نمی‌کند.
خیر. انتخاب درست نسخه اصلی می‌تواند به سامان‌دهی ایندکس و سیگنال‌های صفحات کمک کند، اما رتبه و کلیک به عوامل دیگری نیز وابسته‌اند.
ابتدا User-declared canonical و Google-selected canonical را مقایسه کنید. سپس مشخص کنید دو صفحه واقعاً تکراری هستند یا مستقل. بعد از آن Canonical، پاسخ HTTP، ریدایرکت، محتوای صفحه، لینک‌های داخلی و Sitemap را بررسی و اصلاح کنید.
برای پاسخ به سؤال وقتی گوگل صفحه اشتباهی را به‌عنوان Canonical انتخاب می‌کند چه کنیم؟ باید ابتدا بدانیم که تفاوت Canonical انتخاب‌شده توسط گوگل و ترجیح سایت، همیشه نشانه وجود مشکل نیست.
گاهی گوگل به‌درستی نسخه بدون پارامتر یک صفحه را انتخاب می‌کند. اما در موارد دیگر ممکن است صفحات مستقل محصول، دسته‌بندی یا تنوع کالا به‌اشتباه مشابه شناخته شوند یا تنظیمات فنی سایت سیگنال‌های متناقضی ارائه دهند.
برای تشخیص علت، ابتدا وضعیت را در URL Inspection بررسی کنید. سپس محتوای واقعی دو URL را مقایسه کنید و مطمئن شوید Canonical، ریدایرکت‌ها، Sitemap و لینک‌های داخلی با یکدیگر هماهنگ هستند.
در محصولات متغیر، معماری تک‌صفحه‌ای و چندصفحه‌ای باید جدا بررسی شود. در صفحات دسته‌بندی نیز نباید همه صفحات صفحه‌بندی‌شده را به صفحه اول Canonical کرد. همچنین noindex و robots.txt نباید بدون توجه به هدفشان جایگزین Canonical شوند.
پس از اصلاح، نتیجه فنی را بررسی کنید و برای مشاهده انتخاب نهایی گوگل، داده ایندکس‌شده پس از خزش و پردازش مجدد را پیگیری کنید.
اصل کلیدی این است: اگر دو صفحه واقعاً یک محتوا هستند، یک نسخه اصلی روشن معرفی کنید؛ اما اگر دو صفحه هدف و محتوای مستقل دارند، ساختار سایت باید این تفاوت واقعی را به گوگل نشان دهد.
اگر قصد دارید فروشگاه اینترنتی خود را با ساختار منظم محصولات، دسته‌بندی‌ها و صفحات قابل توسعه برای سئو راه‌اندازی کنید، می‌توانید امکانات سایت‌ساز مای‌تارنما و تست رایگان ۱۰روزه آن را بررسی کنید. پیش از انتشار تعداد زیاد محصولات نیز بهتر است رفتار Canonical، Sitemap و آدرس‌های محصولات متغیر را با پشتیبانی فنی کنترل کنید.
برای طراحی سایت اختصاصی کسب‌وکارتان، همین حالا مشاوره رایگان دریافت کنید.
نام و شماره را بگذارید تا با شما تماس بگیریم.
دیگر محتوا های مرتبط را بخوانید
مای‌تارنما قویترین و سادهترین سایتسازاینترنتی برای راه‌اندازی کسب‌وکار آنلاین شماست. با ما می‌توانید در سریعترین زمان ممکن، بدون نیاز به دانش برنامهنویسی، سایت فروشگاهی اختصاصی خود را بسازید، محصولاتتان را عرضه کنید و مستقیماً از مشتریان خود سفارش بگیرید. مای‌تارنما ابزارهای کامل مدیریت محصولات، گزارش‌های مالی و سیستم پرداخت ایمن را برای تضمین موفقیت و رشد پایدار فروشگاه شما فراهم میآورد.
