قرر ما إذا كانت العناوين مكررة فعلاً
العنوان canonical هو العنوان المُمثل للصفحات المكررة أو شبه المكررة. صِلة الرابط canonical مناسبة عندما يحتوي الهدف على محتوى مكرر أو مجموعة فرعية شاملة (superset) من محتوى الصفحة المحيلة. ليست وسيلة لإخفاء منتجات مختلفة، أو فلاتر مفيدة، أو مقالات، أو لغات.
اسأل ما إذا كان الزائر سيفقد محتوى مهمًا أو خيارًا أو إمكانية إكمال مهمة إذا كان هذا العنوان سيمثله العنوان المرشح. إذا كانت الإجابة نعم، فاجعله مميزًا وحسّن محتواه أو تخصيصه. إذا لا، فاختر عنوان URL ثابتًا ووثق قواعد البروتوكول، والمضيف، والمسار، والشرطة المائلة الختامية (trailing-slash)، والمعلمات.
أضف وسم canonical يشير إلى نفس الصفحة لكل صفحة HTML مفهرسة مفضلة، حتى عندما لا يكون هناك تكرار واضح اليوم.
وجه نسخة مكررة لازمة، مثل مسار يحتوي على معلمة تحليلات، إلى العنوان المفضل فقط إذا كانت كلتا الصفحتين تُرجع نفس المحتوى الرئيسي.
استخدم إعادة توجيه عندما يجب أن يختفي العنوان القديم
استخدم إعادة توجيه دائمة على مستوى الخادم عندما لا يجب أن يكون المسار القديم أو المضيف المتقاعد أو إصدار HTTP وجهة للزوار أو الزاحفين. تعامل Google مع إعادة التوجيه كإشارة قوية للتوحيد (canonicalization) وتوصي بها عند إهمال نسخة مكررة.
استخدم rel=canonical عندما يجب أن تستجيب كلا الصفحتين بمحتوى لكن ينبغي لأحدهما أن يمثل المجموعة في البحث. الوسم لا يغير عنوان الزائر أو يزيل المسار الآخر. يجب أن ينجح الهدف وألا يعيد توجيه أو يُشير canonical إلى مكان آخر.
أرسل عنوان HTTP القديم مباشرةً إلى عنوان HTTPS النهائي واستخدم ذلك العنوان HTTPS في كل مكان آخر.
robots.txt، وإزالات URL، وnoindex لا تعبّر عن تفضيل لنسخة مكررة. noindex بدلاً من ذلك يمنع صفحة من الظهور في البحث.
انشر وسمًا واضحًا واحدًا
بالنسبة لـ HTML، ضع وسم rel=canonical المطلق واحدًا في عنصر الرأس (head). راجع المصدر المرسَل (delivered source)، لا إعداد CMS فقط: قد يستبدل قيمة القالب أو الإضافة أو قاعدة الحافة أو JavaScript القيمة. تنصح Google بتوفيره في مصدر HTML والتأكد من أن JavaScript لا يغيّره.
بالنسبة للمستند غير HTML مثل PDF، استخدم ترويسة Link في استجابة HTTP تشير إلى canonical حيثما كان مناسبًا. تجنّب القيم المتضاربة في HTML والرؤوس. يجب أن يكون الهدف قابلاً للوصول، وألا يكون استجابة 4xx، وألا يكون عنوانًا يعيد التوجيه أو مرتبطًا بسلسلة إعادة توجيه.
انشر هدف canonical واحد لكل مورد؛ الأهداف المتعددة تجعل التفضيل غير واضح.
استعرض عيّنات الصفحات والرؤوس بعد تغييرات القالب أو CDN أو CMS أو التوجيه وتأكد من الهدف النهائي.
اجعل الإشارات الداعمة متوافقة
اربط داخليًا إلى العنوان المفضل في التنقل، والزلائل (breadcrumbs)، وروابط النص، والتغذيات المولدة. ضَع فقط عناوين URL التي تريد ظهورها في البحث في خريطة الموقع. تضمين خريطة الموقع إشارة أضعف، لكنه يعزز الاختيار عندما يتوافق مع إعادة التوجيهات والتعليقات canonical.
ولّد عناوين خريطة موقع مؤهلة بالكامل (fully qualified) بنفس المضيف، والبروتوكول، ونمط الشرطة المائلة مثل canonical. أزل النسخ المعادة التوجيه والمعلمات. اختبر خرائط الموقع المولدة تلقائيًا بعد تغييرات في الروابط الدائمة (permalinks)، أو النطاق، أو اللغة، أو منصة التجارة الإلكترونية.
استبدل الروابط إلى عناوين متتبعة أو قديمة أو على مضيف بديل بالـ canonical المختار.
حافظ على اتساق إعادة توجيه HTTPS، وأهداف canonical، وخرائط الموقع، والروابط؛ فالأخطاء في الشهادة أو تحويل HTTPS->HTTP ترسل إشارات متضاربة.
عامِل المعلمات والترقيم واللغات حسب الغرض
المعلمات ليست تكرارات تلقائيًا. قد تترك معلمات التحليلات المحتوى دون تغيير، بينما قد تغيّر عوامل التصفية والفرز مجموعة النتائج. اختبر مجموعات ممثلة. احتفظ بأي معلمة مطلوبة لعربة التسوق، أو تسجيل الدخول، أو الموافقة، أو الإعداد؛ يجب ألا يكسر canonical تدفق الزائر.
لا تقنّن كل صفحة من سلسلة مُرقَّمة (pagination) إلى الصفحة الأولى: الصفحات اللاحقة عادةً تحتوي على محتوى لا تملكه الصفحة الأولى. بالنسبة لعناوين اللغة أو البلد، سمِّ الصفحة بنفس اللغة كـ canonical عندما توجد، واستخدم hreflang للبدائل. التدويل (localization) لا يُستبدل بالتعريف بـ canonical.
وثّق أي فلاتر عبارة عن صفحات هبوط مميزة وأيها مجرد إعادة ترتيب مكررة حتى تظل تغييرات المنتج والهندسة متوافقة.
استخدم عرضًا واحدًا فقط عندما يكون مجموعة محتوى قابلة للاستخدام فعلًا؛ اختبر تحميله والتنقل فيه قبل اختياره.
استكشاف تعارضات الدليل المفهرس والحالي
في Search Console، فَحْص العنوان المتأثر وقارن canonical الذي اختارتها Google المَفهرَسة مع القيمة المعلنة من جانب المستخدم. فَحْص الهدف المرشح أيضًا. تقرير الفهرس يعكس ما عالجته Google آخر مرة؛ الاختبار الحي مفيد للـ fetch الحالي، والصفحة المُعالجة (rendered)، والرؤوس، والموارد، لكنه لا يتنبأ بالاختيار النهائي للـ canonical.
إذا اختلفت القيم، فاعتبر ما إذا كانت Google قد اختارت الممثل الأفضل. وإلا تتبّع إعادة التوجيهات، وتعليقات HTML وترويسات HTTP، والمخرجات المرسومة، والروابط، وإدخالات خريطة الموقع، وhreflang، وتشابه المحتوى. أصلح الاختلاف، وسجل التغيير، ومنح الوقت لإعادة التقييم.
تحقق من القوالب، والرؤوس، وتوجيه المضيف، والتغييرات الأمنية. canonical أو إعادة توجيه عبر نطاق غير مبرر يستدعي تحقيقًا أمنيًا.
قارن المصدر والرؤوس المسلمة بإعدادات CMS؛ قد تصدر إضافة أو قاعدة منصة قيمة مختلفة.
أضف فحوصات canonical إلى تشديد الإصدار في SIU
قبل إصدارات النطاق، أو HTTPS، أو CDN، أو CMS، أو القالب، أو الكتالوج، خزّن عينات من الصفحة الرئيسية، وصفحات المحتوى والمنتج، ومسار بمعامل، ولغة، وعنوان قديم، ومستند منشور. سجل الحالة، والعنوان النهائي، وهدف canonical، وتضمين خريطة الموقع، ومثال رابط داخلي.
اجعل الإصلاحات قابلة للتراجع: سجّل الخريطة الحالية، وغيّر مجموعة قاعدة واحدة، وتحقق من المسارات المتأثرة، واحتفظ بخطة تراجع. هذا يدعم تحسين وقت التشغيل الاستباقي بحماية المسارات العامة الثابتة أثناء التغيير؛ لكنه لا يوفر كشفًا عن انقطاع الخدمة ولا يضمن الفهرسة.
وزّع قواعد canonical بين فرق التسويق والهندسة وسجل القالب أو إعادة التوجيه أو خريطة الموقع أو تغيير المنصة وراء كل تحديث.
أرفق عيّنة صغيرة قبل-وبعد من عنوان URL ورؤوس في تذكرة الإصدار لتسريع الإصلاح.