ابدأ بالصفحات المقصودة والأدلة القابلة لإعادة الاستخدام
سجّل الصفحات العامة التي تريد أن يعثر عليها الباحثون: المنتجات الرئيسية، المقالات، التصنيفات، والروابط المنقولة. لكل صفحة، سجّل عنوان URL المفضّل، الاستجابة المتوقعة، قابلية الفهرسة، القالب، المالك، والأولوية. احتفظ بالإستثناءات المشروعة منفصلة.
التقط استجابة غير مصدّق عليها، الرؤوس، مسار إعادة التوجيه، مصدر الصفحة، العرض المُصاغ (rendered view)، حالة الروابط الداخلية، وحالة خريطة الموقع لعناوين URL ممثلة. عيّن عينات لكل قالب ونمط URL. الدليل مؤرخ: إعداد CDN، نشر، طبقة الموافقة (consent)، أو التخصيص يمكن أن يغيّر الحالة لاحقًا.
نجاح الصفحة الرئيسية لا يثبت أن صفحات القوائم، متغيرات المنتج، أو المسارات المترجمة تعمل.
احتفظ بالرؤوس والدلائل المؤرخة حتى يمكن مقارنة الإصلاحات والتراجعات اللاحقة.
اجعل قابيلة الفهرسة قرارًا مُتعمدًا
قابلية الفهرسة تعني أن الصفحة قد تُضمَّن في فهرس البحث؛ وهي ليست نفسها الزحف أو الترتيب. افحص توجيهات meta robots داخل HTML ورؤوس الاستجابة X-Robots-Tag. توجيه noindex يخبر محركات البحث بعدم عرض صفحة؛ وX-Robots-Tag ينطبق أيضًا على ملفات غير HTML مثل PDF.
راجع robots.txt بشكل منفصل. يجب أن يتمكن الزاحف من الوصول إلى الصفحة ليرى توجيه noindex، لذا قد يمنع حظر ذلك الرؤية. افحص الاستجابة المنشورة للعامة لأن إعدادات CMS وعوامل البيئة قد تضيف قواعد. noindex ليست تحكماً في الوصول: احمِ المواد الحساسة بالمصادقة ومراجعة أمنية مناسبة.
علّم صفحات intended-index التي تحتوي على noindex، استجابات تسجيل الدخول، إشارات إلى بيئات staging، وأصول أساسية محظورة.
قد يحمل رأس استجابة HTTP توجيهًا حتى عندما لا يوجد HTML في الجزء العلوي.
اجعل عنوان URL المفضّل واحدًا ومتسقًا
التقنين (canonicalization) يحدد عنوان URL المفضّل بين نسخ مكررة أو متشابهة جداً، مثل HTTP وHTTPS، المضيفات المختلفة، معلمات التتبع، الفلاتر، أو صفحات الطباعة. قارن عنصر canonical، الروابط الداخلية، عنوان URL في خريطة الموقع، وهدف إعادة التوجيه. لصفحة قابلة للفهرسة، ينبغي أن تشير هذه الإشارات عادةً إلى نفس عنوان URL المطلق المفضّل.
استخدم إعادة توجيه دائمة على مستوى الخادم عند إيقاف تكرار. تصف Google أن إعادة التوجيه الدائمة وrel=canonical هما إشارتان قويّتان، بينما إدراج الخريطة أضعف؛ إشارات متسقة تعزز التفضيل. لا تستخدم robots.txt للتقنين أو لإعطاء صفحة منافسة canonicals. يساعد canonical الذي يشير إلى نفسه في بيان النسخة المفضلة، لكن اختيار محرك البحث يبقى خارج سيطرتك.
وثّق المتغيرات، الهدف المفضّل، التحكم المطلوب، ومالكاً.
اختبر خرائط القديم-إلى-الجديد قبل الهجرة واحتفظ بخيار تراجع لإعادة التوجيه قابلاً للتنفيذ.
افحص رموز الحالة وسلوك إعادة التوجيه
رموز الحالة تخبر المتصفحات والزواحف بما حدث. يجب أن تُرجع الصفحات الحيّة المهمة استجابة 2xx ذات محتوى مقصود. يجب أن تعود الصفحة التي لا تملك بديلاً ذا صلة بإرجاع 404 أو 410 حقيقي؛ يجب أن يصل المحتوى المنقول إلى أقرب بديل ذي صلة. قد تُعامل صفحة 200 التي تعرض فقط خطأ على أنها soft 404.
سجّل كل قفزة إعادة توجيه. تتبع Google عمومًا حتى 10 قفزات للزحف العام، لكن السلاسل تضيف زمن وصول وهشاشة. تقول Google إن استجابات 5xx و429 يمكن أن تبطئ الزحف مؤقتًا وأن الأخطاء الخادمية المستمرة قد تزيل عناوين URL المفهرسة في نهاية المطاف. حقق في الفشل المتكرر مع مالك الهندسة عبر طبقات التطبيق، CDN، المنشأ، التخزين المؤقت، التبعيات، والنشر.
احفظ عنوان URL الأصلي، القفزات، الرموز، العنوان النهائي والحالة المتوقعة.
أزل قواعد CMS أو CDN أو المضيف أو اللغة المكررة بدلاً من إضافة قفزة أخرى.
تحقق من العرض (rendering) وطرق التوجيه في JavaScript
افحص كل من HTML الأولي والعرض المصاغ للقوالب الرئيسية. أكد وجود المحتوى الرئيسي، العناوين، الروابط، canonical، توجيهات الروبوتس، والحالة بعد العرض. تصف Google مراحل منفصلة: الزحف، العرض، والفهرسة، وتقول إن المحتوى غير المرئي في HTML المعروض لا يمكن فهرسته.
استخدم عناصر anchor ذات href للتنقّل. المسارات المعتمدة على fragment فقط التي تُحمّل محتوى مميزًا ليست موثوقة للاكتشاف. اطلب مباشرةً المنتجات أو المقالات أو عناوين URL المُصفاة غير الموجودة. تحتاج التطبيقات الجانبية (client-side) إلى حالة خطأ حقيقية؛ توثّق Google توجيه المسارات إلى 404 خادمي أو إضافة noindex لتجنّب soft 404s. يمكن أن تساعد العرض من جهة الخادم أو prerendering، لكن تحقق من الاستجابة المنشورة.
افحص HTML المستجيب، HTML المُصاغ، والعرض البشري في المتصفح لأي اختلافات مادية.
فضّل HTML المصدر؛ إن كان JavaScript يضبطه فتأكد من وجود canonical واحد غير متضارب.
حافظ على خرائط المواقع والروابط الداخلية نظيفة
خريطة الموقع هي خريطة اكتشاف، وليست أمرًا بالفهرسة. تضمّن عناوين URL المفضّلة الناجحة والمقصودة؛ استبعد إعادة التوجيه، الأخطاء، صفحات noindex، تكرارات المعلمات، والروابط المحمية. توصي Google بعناوين URL مطلقة كاملة وتتعامل مع إدراج الخريطة كمؤشر canonical وليس كضمان.
تحقق من صحة خريطة الموقع وقارنها مع قائمة intended-index والملاحة. توثّق Google الترميز UTF-8 والحد 50 ميغابايت غير مضغوط أو 50,000 عنوان URL لكل خريطة. للمواقع الأكبر، قسّم إلى مجموعات مفيدة واستخدم فهرس خرائط المواقع. حدّث lastmod فقط للتغييرات الجوهرية والقابلة للتحقق.
تحقق من الفروقات المهمة بين عناوين URL المقصودة، إدخالات خريطة الموقع، والروابط الداخلية.
تحقق من خريطة الموقع المولدة وعينة من العناوين المدرجة بعد تغييرات التوجيه أو CMS.
قِس الأداء واجعل التدقيق مؤسساتي
استخدم بيانات الحياة الحقلية حيثما توفّرت والاختبارات المختبرية المسيطر عليها للتحقيق في Core Web Vitals: Largest Contentful Paint (LCP) للتحميل، Interaction to Next Paint (INP) للتجاوب، وCumulative Layout Shift (CLS) للاستقرار البصري. قسّم حسب نوع الصفحة والجهاز لأن المتوسطات قد تخفي قالبًا عالي القيمة تعطل.
تتبّع التسليم البطيء أو غير المستقر عبر الصور، CSS وJavaScript، علامات الجهات الخارجية، الخطوط، المحتويات المضمنة، والتخزين المؤقت. أجرِ تغييرًا مقاسًا واحدًا ثم أعد فحص العرض وتدفقات المستخدم. تعكس بيانات الحقل المستخدمين الحقيقيين؛ تساعد بيانات المختبر على إعادة الإنتاج. لا يتنبأ أي منهما بكل زاحف أو زائر مستقبلي. كرّر فحص تراجع مركّز بعد الإصدارات الخطرة وتدقيقًا أوسع بعد الهجرات أو تغييرات المنصة.
اصل الأخطاء في القوالب الحرجة للإيراد أو ذات الاستخدام العالي قبل السعي لتحسينات درجات صغيرة في أماكن أخرى.
أعد فحص الاستجابة، canonical، المحتوى المعروض، حالة خريطة الموقع، ودلائل الأداء ذات الصلة قبل الإغلاق.