اللغات

وسم Canonical

طريقة تنفيذ rel=canonical بصورة صحيحة: عنصر HTML، وترويسة HTTP لملفات PDF، والعناوين المطلقة، وتصريح واحد لكل صفحة، والأخطاء الشائعة.

نُشر أول مرة: 23 يونيو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2
دليل واحد في هذه الصفحة

يحدد وسم canonical عنوان URL المفضل بين النسخ المكررة. وهو إشارة قوية لا توجيهًا ملزمًا. ضعه مرة واحدة داخل head بعنوان مطلق، واستخدم ترويسة HTTP لملفات PDF، واجعل الصفحات المفضلة والصفحات المرقمة تشير إلى نفسها. لا تجمعه مع noindex أو حظر robots.txt، وافحص HTML الخام وDOM المعروض وURL Inspection.

الخلاصة — rel=canonical إشارة لا قاعدة، وقد تتجاوزها Google. طرق التصريح الصحيحة هي عنصر HTML داخل <head> (أما في <body> فيُتجاهل)، وترويسة HTTP Link: rel="canonical" لملفات PDF وغيرها من الملفات غير HTML، والإدراج في خريطة الموقع كإشارة أضعف. استخدم علاقة canonical واحدة واضحة لكل صفحة؛ فالتصريحات المتعددة أو المتعارضة قد تعطي نتائج غير متوقعة. استخدم عناوين مطلقة، واجعل الصفحات المفضلة تشير إلى نفسها، ولا توحّد صفحات الترقيم مع الصفحة الأولى. لا تجمع canonical مع noindex أو حظر robots.txt أو استجابة 4XX. اختبر المصدر في مقابل DOM المعروض، واستخدم curl -I للترويسة وURL Inspection في GSC لمقارنة ما صرحت به بما اختارته Google.

canonical تصريح، لا قرار

افصل بين مفهومين: التوحيد القياسي هو العملية التي تختار بها Google عنوانًا ممثلًا من مجموعة مكررة بعد موازنة إشارات كثيرة. أما وسم canonical فليس إلا إشارة واحدة تعبر عن تفضيلك. تشرح هذه الصفحة طريقة التصريح الصحيح، بينما توجد عملية الاختيار نفسها في مركز canonicalization.

هذا الفرق هو أساس الدقة هنا، لأن Google تقول صراحة إن تفضيل canonical «إشارة وليس قاعدة». إنها إشارة قوية؛ وقد شرحت في دليلي المتعمق عن التوحيد القياسي أنها «تُعد إشارة قوية» وأن Google تتجاهلها إذا كانت الإشارات الأخرى أقوى. لكنها ليست توجيهًا ملزمًا. فإذا صرحت بأن A هو canonical بينما تشير الروابط الداخلية وخريطة الموقع والتحويلات إلى B، فقد تختار Google العنوان B. وهذه حالة «Duplicate, Google chose a different canonical than user» في Search Console. Evidence for this claim Canonicalization methods communicate a preferred URL, but Google can choose a different canonical when signals conflict. Scope: Google Search canonical selection; applies to duplicate or very similar pages. Confidence: high · Verified: Google: URL canonicalization

ثلاث طرق غير التحويل للتصريح بعنوان canonical

إلى جانب التحويلات، توثق Google ثلاث طرق غير تحويلية للإشارة إلى canonical، ولكل منها قوة مختلفة: Evidence for this claim Alongside redirects, Google documents three non-redirect ways to indicate a canonical: an HTML link element, an HTTP Link header, and sitemap inclusion. Scope: The three non-redirect canonical declaration approaches covered in this article; Google also documents redirects as a canonicalization method. Confidence: high · Verified: Google: Specify a canonical URL

  • عنصر HTML <link rel="canonical"> داخل <head> — «إشارة قوية إلى أن عنوان URL المحدد ينبغي أن يصبح canonical». وهي الطريقة المعتادة لصفحات HTML.
  • ترويسة الاستجابة HTTP Link: rel="canonical" — للمستندات التي لا يمكن وضع عنصر <link> فيها. وتوضح Google إمكان استخدام ترويسة HTTP ذات هدف rel=“canonical” وفق RFC5988 لتحديد العنوان لمستندات البحث، ومنها ملفات PDF غير HTML. عنصر HTML لا يعمل إلا في صفحات HTML؛ ولـPDF استخدم ترويسة HTTP.
  • الإدراج في خريطة الموقع — «إشارة ضعيفة تساعد العناوين المدرجة في خريطة الموقع على أن تصبح canonical». وهي أضعف الطرق الثلاث.

هناك نقطتان مهمتان بشأن تفاعل هذه الطرق:

  • تتراكم الإشارات. تقول Google إن هذه الطرق يمكن جمعها فتزداد فاعليتها. إن اجتماع وسم ذاتي الإشارة وخريطة نظيفة وروابط داخلية متسقة أقوى من أي إشارة منفردة.
  • لا واحدة منها إلزامية. تشجع Google استخدامها، لكنها تقول إن الموقع قد يعمل جيدًا من دون تحديد تفضيل canonical. التصريح يزيل الغموض، وغيابه ليس خطأ بذاته.

وبصورة منفصلة، يُعد تحويل 301 إشارة تجميع أقوى من rel=canonical، لكنه أداة مختلفة؛ وستأتي المقارنة بين canonical و301 وnoindex أدناه.

ترويسة HTTP ولماذا تحتاج إليها ملفات PDF

لا يحتوي PDF على <head>، فلا مكان لعنصر <link>. الحل هو إرسال canonical في ترويسة استجابة HTTP على مستوى الخادم. وتكون بهذا الشكل:

Link: <https://www.example.com/downloads/whitepaper.pdf>; rel="canonical"

تضبطها في الخادم، مثل Apache .htaccess أو Nginx، أو في CDN/الحافة. راجع تبويب Scripts لأمثلة Apache وNginx وأمر curl -I الذي يثبت إرسال الترويسة. تعمل الترويسة أيضًا مع HTML، لكن عنصر <link> أبسط هناك؛ استخدمها عندما لا توجد شيفرة قابلة للتعديل، مثل PDF والصور والملفات غير HTML.

يجب أن يكون داخل <head>: فخ الانتقال إلى body

هذا أكثر أنماط الفشل إضرارًا وغالبًا يحدث مصادفة. تقول Google: «The rel=“canonical” link element is only accepted if it appears in the <head> section of the HTML, so make sure at least the <head> section is valid HTML.» (ترجمة) «لا يُقبل عنصر rel=canonical إلا داخل قسم head، لذا تأكد من صحة هذا القسم على الأقل». وفي منشور «5 أخطاء شائعة» لعام 2013: «When we encounter a rel=canonical designation in the <body>, it’s disregarded.» (ترجمة) «عندما نجده في body يُتجاهل». والخلاصة: «rel=canonical designations in the <head> are processed, not the <body>.» (ترجمة) «تُعالج التصريحات في head لا body». Evidence for this claim Google accepts an HTML rel=canonical link element only in a valid head section and disregards a canonical placed in the body. Scope: HTML link-element canonicals in Google Search; HTTP-header canonicals are a separate method. Confidence: high · Verified: Google: Common rel=canonical mistakes

الفخ أن تكتب canonical داخل <head> في المصدر، لكن أثناء بناء الصفحة قد ينغلق head مبكرًا بسبب وسم غير مغلق أو JavaScript محقون أو <iframe>. حينها يصل الوسم في DOM المعروض إلى <body> فيُتجاهل. شرحت ذلك في دليل JavaScript SEO: قد تنهي الوسوم غير المغلقة أو JavaScript المحقون قسم head قبل أوانه وتدفع canonical إلى body، حيث لا يُحترم.

المشكلة أن view-source لا يكشف ذلك؛ فقد يبدو HTML الخام صحيحًا. يجب مقارنة HTML الخام مع DOM المعروض في لوحة Elements أو HTML المعروض في URL Inspection لمعرفة الموضع النهائي للوسم.

في JavaScript، تنصح Google باختيار طريقة واحدة: “If you can’t set the canonical URL in the HTML source code, leave it out and only set it with JavaScript.” (ترجمة) «إذا تعذر ضبط canonical في مصدر HTML، فاتركه واضبطه عبر JavaScript فقط». وإذا حقنته فتأكد من دخوله إلى <head>، ولا تعرض وسمًا مختلفًا في الخادم.

صرّح بعلاقة canonical واحدة لكل صفحة

ينبغي أن توجد علاقة واحدة واضحة لكل صفحة. تحذر إرشادات Google الحالية من أن جمع الطرق قد يسبب أخطاء ونتائج غير متوقعة، ولا تحدد فوز الوسم الأول أو الأخير. قال منشور Google لعام 2013 إن التصريحات المتعددة يُرجح تجاهلها؛ اعتبر ذلك سياقًا تاريخيًا لا عقدًا دائمًا للمحلل. النتيجة الآمنة اليوم: اكشف كل تصريحات HTML وHTTP، وسجل التعارض، وأصلح القالب.

السبب المعتاد ليس خطأ كتابيًا، بل تكدس الأنظمة: يحقن CMS وسمًا، والقالب آخر، وإضافة SEO ثالثًا. أشرت إلى هذا في دليلي عن canonicalization: غالبًا ما يحدث تعدد الوسوم لأن CMS والقالب والإضافات تدرجها في نقاط مختلفة. عند تشخيص وسم «لا يعمل»، ابدأ بعدّ الوسوم في DOM المعروض.

استخدم عناوين URL مطلقة لا نسبية

تقول Google: «Use absolute paths rather than relative paths with the rel=“canonical” link element. Even though relative paths are supported by Google, they can cause problems in the long run.» (ترجمة) «استخدم المسارات المطلقة بدل النسبية؛ فرغم دعم النسبية قد تسبب مشكلات لاحقًا». يقبل عنصر <link> النوعين، لكن href نسبيًا مثل /page/ يُحل بالنسبة إلى العنوان الحالي وقد يشير إلى مكان غير مقصود. اكتب العنوان الكامل دائمًا:

<!-- Good -->
<link rel="canonical" href="https://www.example.com/dresses/green/green-dress.html">

<!-- Bad: relative path -->
<link rel="canonical" href="/dresses/green/green-dress.html">

ينطبق المنطق نفسه على المضيف والبروتوكول: أشر إلى النسخة النهائية الفعلية، مثل https:// بدل http:// والمضيف المعتمد. ولا تستخدم جزء URL بعد # بوصفه canonical؛ فـGoogle لا تدعم الأجزاء عمومًا.

الإشارة الذاتية وترقيم الصفحات

من الصحيح والموصى به أن تسمي الصفحة نفسها canonical للنسخة المفضلة، فهذا يزيل الغموض عندما لا تتطابق بقية الإشارات. وإذا قال الفحص إن الصفحة «لا تملك canonical مختلفًا»، فإن الإشارة الذاتية تحقق الشرط؛ فهي تصريح بالعنوان نفسه وليست هدفًا منافسًا.

ترقيم الصفحات هو أكثر مواضع الخطأ. لا تجعل الصفحات 2 و3 و4 تشير إلى الصفحة 1. تقول Google: «Specifying a rel=canonical from page 2 (or any later page) to page 1 is not correct use of rel=canonical.» (ترجمة) «الإشارة من الصفحة الثانية أو التالية إلى الأولى استخدام غير صحيح». فالصفحة الثانية ليست نسخة من الأولى، ولذلك يجب أن تشير كل صفحة مرقمة إلى نفسها.

ومن أخطاء الإفراط أيضًا أن تشير صفحة فئة أو هبوط إلى مقال مميز واحد؛ فالصفحتان ليستا المحتوى نفسه، لذا لا يصلح canonical بينهما.

لا تحجب رؤية canonical ولا توجهه إلى هدف معطوب

لا يعمل canonical إلا إذا استطاعت Google زحف الصفحة وقراءة الوسم ولم تجد تعليمات مناقضة. هذه مشكلة صحة في صفحة المصدر، أي هل تستطيع Google رؤية الوسم على العنوان المكرر أصلًا. وهناك ثلاث طرق شائعة لإفشاله:

  • حظر العنوان في robots.txt. إذا استخدمت Disallow فلن تزحف Google العنوان المكرر ولن ترى canonical، وقد تفهرس العنوان المحظور من دون محتواه. لا تستخدم robots.txt للتوحيد.
  • وضع noindex على العنوان المكرر. هاتان تعليمتان متناقضتان: noindex تعني الإزالة وcanonical يعني التجميع. اختر إحداهما حسب الهدف.
  • إرجاع 4XX من العنوان المكرر. لا تستطيع Google قراءة الوسم، فلا يمكنها نقل الإشارات.

ولا تصرح بعناوين canonical متعارضة بين الطرق. تقول Google: «Don’t specify different URLs as canonical for the same page using different canonicalization techniques» (ترجمة) «لا تحدد عناوين مختلفة للصفحة نفسها بطرق توحيد مختلفة»؛ مثل عنوان في الخريطة وآخر في rel=canonical.

هناك مشكلة منفصلة في الهدف الذي تشير إليه: يجب أن يكون وجهة سليمة. ينصح RFC 6596 بعدم اختيار هدف يحوّل إلى غيره، أو يشير canonical منه إلى عنوان ثالث، أو يعيد خطأ. وتضيف قائمة Google التحقق من عدم وجود noindex. لذلك افحص بصورة مستقلة أن الهدف يعيد 200 مباشرة، بلا تحويل ولا noindex ولا canonical مختلف.

عند استخدام hreflang، يجب أن يشير canonical إلى صفحة باللغة نفسها، أو إلى أفضل لغة بديلة إذا لم توجد صفحة canonical بتلك اللغة.

canonical في مقابل 301 وnoindex

ليست هذه الأدوات مترادفة؛ راجع جدول القرار في تبويب Cheat Sheets. والخلاصة:

  • rel=canonical — يبقى العنوانان متاحين وقابلين للزحف، وتعبر عن تفضيل وتجمع Google الإشارات على المختار. إنها إشارة، وتناسب النسخ المتطابقة أو شبه المتطابقة التي يجب أن تبقى متاحة، مثل المعلمات ونسخ الطباعة، لا الحل العام للمحتوى المعاد نشره.
  • تحويل 301 — ينقل المستخدمين والزواحف إلى الهدف وهو أقوى إشارة تجميع. استخدمه عندما ينبغي ألا يبقى العنوان المكرر متاحًا.
  • noindex — توجيه يزيل الصفحة من البحث كليًا، مع بقائها قابلة للزحف كي تراه Google. استخدمه للإزالة لا للتجميع.

تفضل Google canonical للنسخ المكررة داخل الموقع: «We don’t recommend using noindex to prevent selection of a canonical page within a single site, because it will completely block the page from Search. rel=“canonical” link annotations are the preferred solution.» (ترجمة) «لا نوصي بـnoindex لمنع اختيار canonical داخل موقع واحد لأنه يحجب الصفحة كليًا؛ وتعليقات rel=canonical هي الحل المفضل». Evidence for this claim Google recommends rel=canonical rather than noindex when the goal is selecting a canonical within one site, because noindex removes the page from Search. Scope: Google Search guidance for duplicate pages within a single site. Confidence: high · Verified: Google: Specify a canonical URL

لماذا تتجاهل Google canonical؟

عندما تختار Google عنوانًا غير الذي صرحت به، يكون السبب غالبًا أحد الآتي: المحتوى ليس متماثلًا فعلًا، أو توجد تصريحات متعددة أو متعارضة، أو الوسم في body، أو العنوان نسبي أو معطوب، أو الصفحة محظورة أو تعيد 4XX، أو تشير إشارات أقوى كالروابط الداخلية والخريطة والتحويلات إلى مكان آخر.

تظهر مشكلة اختلاف المحتوى بقوة في مواقع JavaScript. قال John Mueller: «With JavaScript based sites, the content side is a common reason for this: for example, if you’re using a SPA-type setup where the static HTML is mostly the same, and JavaScript has to be run in order to see any of the unique content, then if that JS can’t be executed properly, then the content ends up looking the same.» (ترجمة) «في مواقع JavaScript يكون المحتوى سببًا شائعًا؛ فإذا كان HTML الثابت متشابهًا ولا يظهر المحتوى الفريد إلا بعد تشغيل JavaScript، فإن فشل التنفيذ يجعل الصفحات تبدو متطابقة». عندها قد تجمع Google الصفحات أو تفصلها بخلاف قصدك.

تعامل Bing rel=canonical بوصفه إشارة وضوح وتوصي به للمحتوى المعاد نشره. وهذا يختلف عن Google: “the canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different.” (ترجمة) «لا يُوصى بعنصر canonical لمنع تكرار شركاء النشر لأن الصفحات غالبًا مختلفة جدًا». Evidence for this claim Google's current troubleshooting guidance does not recommend rel=canonical as the general fix for duplication by syndication partners, because syndicated pages are often materially different from the original. Scope: Google Search guidance for syndicated-content duplication; canonical remains valid where the syndicated copy is a genuine duplicate or superset of the original. Confidence: high · Verified: Google: Fix canonicalization issues توصي Google بأن يمنع الشريك فهرسة نسخته. وتقول Bing إن canonical والتحويلات وhreflang وnoindex وIndexNow تدعم الوضوح. ولمعلمات URL تقدم Bing أداة URL Normalization.

طريقة الاختبار

توجد الخطوات المرقمة في تبويب Checklists، والأوامر في Scripts. أما الخطوات الأساسية فهي:

  1. افحص view-source: هل يوجد عنصر <link rel="canonical"> واحد داخل <head> وبعنوان مطلق؟
  2. قارنه مع DOM المعروض في DevTools أو GSC: هل بقي في head ولم يضف العرض نسخة ثانية؟
  3. استخدم curl -I لفحص ترويسة HTTP Link: rel="canonical"، ولا سيما لملفات PDF.
  4. في GSC URL Inspection قارن User-declared canonical مع Google-selected canonical. قد تتأخر بيانات الفهرس ساعات، والاختبار المباشر يثبت قابلية الجلب فقط ولا يتنبأ باختيار canonical.
  5. ازحف الموقع عبر Ahrefs Site Audit، المجاني للمواقع المثبتة في Ahrefs Webmaster Tools، أو Screaming Frog لاكتشاف الأخطاء على نطاق واسع.

لفهم الطريقة التي تختار بها Google canonical من نحو 40 إشارة، راجع مركز canonicalization. أما المحتوى المكرر ومعلمات URL فهما غالبًا السببان اللذان يدفعانك إلى استخدام canonical.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.