تگ کنونیکال را چگونه درست تنظیم کنیم؟

ابتدا مجموعه URLهای مشابه را مشخص کنید. پارامتر رهگیری، مرتب‌سازی، نسخه چاپی و مسیرهای متعدد محصول می‌توانند یک پاسخ نزدیک به هم بسازند. شباهت باید در محتوای اصلی و هدف صفحه بررسی شود. صرف وجود چند عبارت مشترک برای قرار دادن دو URL در یک مجموعه تکراری کافی نیست و ممکن است به انتخاب مقصد نامرتبط منجر شود.

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

برای ادامه بررسی: تفاوت رقابت صفحات و نسخه تکراری

ریدایرکت زمانی مناسب است که نسخه دیگر دیگر نباید به‌عنوان صفحه مستقل در دسترس بماند و جانشین مرتبطی دارد. کنونیکال اجازه می‌دهد نسخه‌های مشابه برای کاربردی مشخص باقی بمانند. این تفاوت برای پارامتر مرتب‌سازی یا نسخه چاپ اهمیت دارد. تصمیم باید از نیاز محصول و تجربه کاربر بیاید، نه از تمایل به استفاده یکسان از یک تنظیم در همه URLها.

در یک نمونه آموزشی، صفحه https://example.com/products/model-a/ نسخه ترجیحی است و پارامتر utm_source فقط مسیر ورود را ثبت می‌کند. اگر پاسخ اصلی یکسان باشد، تگ <link rel="canonical" href="https://example.com/products/model-a/"> می‌تواند همان نسخه را معرفی کند. این مثال به معنی حذف تمام پارامترها نیست. پارامتری که مدل یا مجموعه محصول را عوض می‌کند باید جدا بررسی شود. مقصد نمونه باید در سایت واقعی با URL معتبر و نهایی همان محتوا جایگزین شود.

noindex هدف متفاوتی دارد و برای اعلام ترجیح میان نسخه‌های مشابه طراحی نشده است. اگر هدف، خارج کردن صفحه از نتیجه جستجو باشد، باید امکان دیده شدن دستور توسط خزنده فراهم باشد. ترکیب دستورهای مختلف بدون تعریف هدف، عیب‌یابی را سخت می‌کند. برای هر الگوی URL مشخص شود می‌خواهیم آن را منتقل کنیم، خارج از ایندکس نگه داریم یا نسخه نماینده‌اش را معرفی کنیم.

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

برای ادامه بررسی: سیاست URL در معماری سایت

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

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

کنونیکال برای صفحه‌های فیلترشده نیز تصمیم موردی می‌خواهد. ترکیبی که مجموعه متفاوت و ارزشمند برای یک نیاز مشخص دارد، شاید به صفحه فرود مستقل نیاز داشته باشد. ترکیبی بی‌ارزش یا تکراری سیاست دیگری می‌خواهد. اشاره دادن همه ترکیب‌ها به دسته مادر، بدون بررسی میزان شباهت، نسخه عمومی قابل دفاعی برای تمام فروشگاه‌ها نیست.

در پایان طراحی، یک جدول الگوها ساخته شود. برای هر گروه، نمونه URL، علت تکثیر، نسخه مطلوب و ابزار انتخاب‌شده ثبت شود. این جدول به توسعه‌دهنده اجازه می‌دهد قواعد را در قالب پیاده کند. همچنین به تیم سئو کمک می‌کند نتیجه را با نمونه‌های سالم و مرزی بررسی کند، نه اینکه فقط وجود کلمه canonical را در خروجی بشمارد.

در HTML، تگ کنونیکال باید در بخش head معتبر قرار بگیرد و به URL ترجیحی کامل اشاره کند. خروجی نهایی باید یک تصمیم روشن داشته باشد. تولید همزمان تگ‌های ناسازگار از قالب و افزونه می‌تواند ابهام ایجاد کند. پیش از حذف یا افزودن تگ، منبع تولید آن‌ها مشخص شود تا اصلاح موقتی با به‌روزرسانی قالب دوباره برنگردد.

اگر صفحه با جاوااسکریپت ساخته می‌شود، HTML اولیه و DOM پس از رندر با هم مقایسه شوند. مقصد نباید در مراحل مختلف به نشانی‌های متناقض تبدیل شود. داشتن کنونیکال روشن در خروجی اولیه، بررسی را ساده‌تر می‌کند. در سایت‌هایی که تنظیم فقط در مرورگر انجام می‌شود، نمونه صفحه و رندر دیده‌شده توسط ابزار بررسی URL اهمیت بیشتری پیدا می‌کند.

برای ادامه بررسی: اصلاح فنی کنونیکال ها

برای فایل غیر HTML مانند PDF، امکان استفاده از هدر Link با رابطه canonical بررسی شود. تیم سرور باید بداند این هدر برای کدام فایل‌ها و چه مقصدی تولید می‌شود. اضافه کردن قاعده عمومی بدون نگاشت می‌تواند فایل‌های متفاوت را به یک مقصد نامناسب وصل کند. تست هدر و محتوای مقصد، بخشی از تایید این نوع پیاده‌سازی است.

لینک‌های داخلی باید تا جای ممکن به نسخه ترجیحی بروند. اگر منو به نسخه پارامتری، نقشه سایت به نسخه دیگری و کنونیکال به آدرس سوم اشاره کند، سایت پیام یکپارچه‌ای ندارد. اصلاح این اختلاف‌ها اغلب از تغییر چندباره خود تگ مفیدتر است. هدف، ساختن یک مسیر ثابت برای کاربر و ابزارهای خزش است، نه افزودن تنظیمات بیشتر روی نشانه‌های متناقض.

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

برای تشخیص زنجیره یا حلقه، مقصد کنونیکال چند مرحله دنبال شود. صفحه اول نباید به صفحه‌ای اشاره کند که خودش مقصد دیگری معرفی می‌کند، مگر اینکه وضعیت انتقال موقتی و مستندی در حال اصلاح باشد. حلقه میان دو URL نیز باید برطرف شود. نگاشت مستقیم به نسخه نهایی، هم فهم ساختار و هم بازبینی دوره‌ای را ساده‌تر می‌کند.

برای ادامه بررسی: بررسی علت ایندکس نشدن صفحه

پس از انتشار، تگ اعلام‌شده و نسخه انتخاب‌شده گوگل در ابزار بررسی URL مقایسه شوند. تفاوت این دو، لزوما خطای ابزار یا بی‌اثر بودن کامل کنونیکال نیست. شباهت محتوا، لینک‌ها، تغییر مسیر و دسترسی مقصد دوباره بررسی شوند. زمان خزش آخر نیز اهمیت دارد، چون داده گزارش ممکن است هنوز مربوط به خروجی پیش از اصلاح باشد.

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

نگهداری کنونیکال به هماهنگی تیم‌ها وابسته است. افزودن فیلتر، تغییر مسیر URL یا نصب افزونه می‌تواند قاعده قبلی را عوض کند. جدول الگوها و آزمون‌های نمونه باید همراه تغییر محصول به‌روز شوند. کنونیکال زمانی مفیدتر است که بخشی از سیاست آدرس‌های سایت باشد و سایر مسیرها نیز همان نسخه ترجیحی را به‌طور ثابت معرفی کنند.