حل مشكلة خطأ إعادة التوجيه في بلوجر: التشخيص قبل الإصلاح - عرب أكواد

إذا ظهر لك تنبيه خطأ إعادة التوجيه في بلوجر (Redirect error) داخل Google Search Console، فلا تبدأ بإضافة سكربت إلى القالب أو تغيير إعدادات النطاق. الخطوة الصحيحة هي تحديد الرابط المتأثر، وفهم ما إذا كان Google قد واجه تحويلًا معطوبًا بالفعل أم أن التنبيه مرتبط بطريقة بلوجر في توجيه زوار الهاتف إلى عناوين تنتهي بـ ?m=1.

الإجابة المختصرة: خطأ إعادة التوجيه قد يكون مشكلة فعلية مثل حلقة تحويل لا تنتهي أو وجهة غير صالحة. لكن ظهور الرسالة مع بعض روابط Blogger لا يعني تلقائيًا وجود خلل يجب إصلاحه. افحص مسار الرابط، ونتيجة الزحف السابقة، والنسخة الأساسية (Canonical) أولًا؛ ثم اتخذ الإجراء المناسب للحالة التي ثبتت لديك.

" width="1672" height="941" loading="eager" fetchpriority="high" decoding="async" alt="خطأ إعادة التوجيه في بلوجر داخل Google Search Console وطريقة التشخيص قبل الإصلاح" title="حل مشكلة خطأ إعادة التوجيه في بلوجر" />

خطأ إعادة التوجيه في بلوجر: تحديد السبب قبل إجراء أي تعديل.

ما معنى خطأ إعادة التوجيه في Google Search Console؟

إعادة التوجيه (Redirect) تعني أن طلب عنوان URL يقود إلى عنوان آخر. وهي عملية طبيعية عند الانتقال إلى HTTPS أو تغيير عنوان صفحة أو توجيه المستخدم إلى النسخة الملائمة لجهازه. أما حالة Redirect error في تقرير فهرسة الصفحات فتعني أن Google واجه مشكلة أثناء متابعة أحد مسارات التحويل.

وفق توثيق Google الرسمي لتقرير فهرسة الصفحات، تشمل أسباب الخطأ سلسلة تحويل طويلة جدًا، أو حلقة تحويل، أو رابطًا غير صالح أو فارغًا في السلسلة، أو مسارًا ينتهي بعنوان يتجاوز الطول المقبول.

الفرق بين الحالات المتشابهة في التقرير

الحالة	ماذا تعني؟	هل تستدعي الإصلاح؟
Redirect error	تعذر على Google إكمال مسار التحويل في أثناء الزحف.	تحتاج إلى تشخيص؛ وقد تكون مشكلة حقيقية أو حالة مرتبطة بسلوك بلوجر.
Page with redirect	العنوان يحوّل الزائر إلى عنوان آخر، لذلك لا يُفهرس عادةً بوصفه عنوانًا مستقلًا.	لا، إذا كانت الوجهة المقصودة صحيحة وقابلة للفهرسة.
Alternate page with proper canonical tag	نسخة بديلة تشير إلى نسخة أساسية صحيحة يفترض أن تمثل المحتوى في البحث.	لا، إذا كانت النسخة الأساسية المختارة صحيحة.

لا يكفي ظهور كلمة «غير مفهرسة» للحكم على وجود مشكلة. فقد يكون عدم فهرسة رابط بديل أو رابط مُحوَّل سلوكًا متوقعًا، بينما تكون الصفحة الأساسية هي التي ينبغي التحقق من حالتها.

لماذا يظهر خطأ إعادة التوجيه في بلوجر؟

كيف تعمل روابط ?m=1 وتحويلات 302؟

تستخدم Blogger في بعض حالات عرض الهاتف عنوانًا منفصلًا يضيف الوسيط ?m=1 إلى رابط المقال. عند التعرف على زائر أو زاحف بوصفه مستخدمًا للهاتف، قد ترسل المنصة تحويلًا مؤقتًا من نوع 302 إلى النسخة المخصصة له.

على سبيل المثال، قد ينتقل الطلب من:

https://example.com/2026/10/sample-post.html

إلى:

https://example.com/2026/10/sample-post.html?m=1

هذا مثال توضيحي، وليس رابطًا حقيقيًا لمقال. يختلف 302، بوصفه تحويلًا مؤقتًا، عن 301 الذي يشير إلى انتقال دائم. وتتعامل أنظمة Google معهما بوصفهما إشارتين مختلفتين لاختيار العنوان الأساسي؛ راجع شرح Google لأنواع إعادة التوجيه.

" width="1672" height="941" loading="lazy" decoding="async" alt="مخطط يوضح تحويل 302 من رابط مقال بلوجر إلى نسخة الهاتف m=1 وعلاقة Canonical بالرابط الأساسي" title="شرح تحويلات m=1 و302 في بلوجر" />

مثال توضيحي لمسار تحويل الهاتف في بلوجر وعلاقته بالرابط الأساسي.

ما علاقة Googlebot Smartphone وCanonical؟

تعتمد Google أساسًا على نسخة الهاتف من محتوى الصفحة في الفهرسة (Mobile-first indexing). وفي إعداد بلوجر المعتاد، قد تُقدَّم نسخة ?m=1 للهاتف، بينما تشير علامة rel="canonical" إلى رابط المقال الأساسي دون ذلك الوسيط.

تشرح إرشادات مجتمع دعم Blogger، التي كتبها أحد خبراء المنتجات، أن بعض تقارير Redirect error تنشأ من تعامل Google مع تحويلات الهاتف المعتادة في المنصة، ولا تعني بالضرورة وجود إعداد خاطئ. هذه إرشادات مجتمعية متخصصة وليست ضمانًا بأن كل حالة مشابهة آمنة.

مهم: لا تعتبر وجود ?m=1 دليلًا كافيًا على سلامة الصفحة. إذا كان رابط الهاتف يعرض صفحة خطأ، أو يتضمن noindex غير مقصود، أو يحوّل إلى مقال آخر، فهذه حالة تستحق معالجة مستقلة.

كيف تتحقق من وجود خطأ إعادة توجيه حقيقي؟

1. افتح تقرير فهرسة الصفحات وحدد الرابط المتأثر

1. افتح موقعك في Google Search Console وانتقل إلى الفهرسة ← الصفحات.
2. ابحث ضمن أسباب عدم الفهرسة عن خطأ في إعادة التوجيه (Redirect error).
3. افتح أمثلة الروابط وحدد عنوان مقال مهم تظهر معه المشكلة.
4. تحقق هل الرابط ينتهي بـ ?m=1، أم أنه عنوان المقال المعتاد، أم رابط نطاق قديم.

تذكّر أن التقرير يعرض عناوين وأسبابًا اكتشفتها Google في زيارات سابقة؛ وقد تختلف الحالة الحالية إذا تغيّر الموقع بعد آخر زحف.

2. افحص النسخة المخزنة في فهرس Google

استخدم أداة فحص عنوان URL، ثم راجع تاريخ آخر زحف، ونوع الزاحف إذا ظهر، وحالة جلب الصفحة، والعنوان الأساسي الذي حدده الموقع والعنوان الذي اختارته Google عند توفر البيانات. هذه المعلومات تساعدك على فهم ما حدث للعنوان المحدد، لا مجرد ظهور رسالة عامة في التقرير.

3. شغّل الاختبار المباشر وقارن النتائج

اضغط اختبار عنوان URL المنشور (Test Live URL)، ثم قارن نتيجته بنتيجة الفهرسة السابقة. إذا نجح الاختبار المباشر وبقي التنبيه، فقد يكون الفحص الحالي قد وصل إلى الوجهة النهائية بنجاح، أو تكون المشكلة قد تغيّرت منذ آخر زحف.

توضح وثائق أداة فحص العناوين أن الاختبار المباشر لا يتنبأ باختيار Canonical ولا يضمن الفهرسة. وهو يتبع التحويل إلى وجهته النهائية في حالات الاختبار المباشر، لذلك لا يطابق بالضرورة سجل الزحف السابق للعنوان الأصلي.

4. افتح العنوان في الهاتف والحاسوب

اختبر رابط المقال دون ?m=1، ثم افتح النسخة التي تحتوي عليه. تحقق من أن كل نسخة تعرض المقال الصحيح بالمحتوى الأساسي نفسه، وأن الروابط لا تنقلك إلى الصفحة الرئيسية أو إلى مقال غير ذي صلة. اختبر أيضًا روابط http وhttps وwww عند وجود نطاق مخصص، لكن لا تغيّر إعداداتها قبل معرفة الوجهة المتوقعة.

5. افحص مسار التحويل وأكواد HTTP

يمكن للمستخدم المتقدم فحص حالة العنوان النهائي وعدد التحويلات باستخدام curl. المثال التالي مناسب لنظام Linux أو macOS بعد استبدال الرابط بعنوان مقال تملكه:

curl -sS -L -o /dev/null \
  -w 'HTTP: %{http_code}\nRedirects: %{num_redirects}\nFinal: %{url_effective}\n' \
  'https://example.com/2026/10/sample-post.html'

وعلى Windows PowerShell استخدم curl.exe مع NUL بدل /dev/null:

curl.exe -sS -L -o NUL -w "HTTP: %{http_code} | Redirects: %{num_redirects} | Final: %{url_effective}\n" "https://example.com/2026/10/sample-post.html"

يعرض الأمر رمز استجابة الوجهة النهائية وعدد التحويلات والعنوان النهائي. لعرض ترويسات الاستجابات المتتابعة يمكن إضافة -D -، مع الانتباه إلى أن نتيجة curl العادي لا تطابق بالضرورة تجربة Googlebot Smartphone؛ فقد يتغير السلوك بحسب الجهاز أو User-Agent أو الشبكة.

6. افصل بين مشكلة التحويل ومشكلة الفهرسة

إذا وصلت إلى المقال الصحيح وكانت الصفحة قابلة للوصول، لكن Google لم يفهرسها، فتحقق من أسباب عدم الفهرسة الأخرى: اختيار عنوان أساسي مختلف، وجود noindex، صعوبة اكتشاف الصفحة أو تقييم Google للمحتوى. إصلاح تحويل واحد لا يضمن أن الصفحة ستُقبل في الفهرس.

حلول أخطاء إعادة التوجيه الحقيقية في بلوجر

إصلاح رابط مكسور أو تحويل مخصص غير صحيح

إذا كنت قد أنشأت تحويلًا يدويًا داخل Blogger، ووجدت أنه يشير إلى رابط محذوف أو يعيد الزائر إلى المصدر، فراجع الإعدادات ← الأخطاء وعمليات إعادة التوجيه ← عمليات إعادة التوجيه المخصصة. صحح الوجهة لتصل إلى الصفحة المناسبة، ولا تنشئ تحويلًا متبادلًا بين رابطين.

يمكن استخدام تحويل دائم عند نقل مقال نهائيًا إلى عنوان جديد مناسب، وفق إرشادات إعدادات Blogger. لا تستخدم التحويلات المخصصة لمحاولة إزالة جميع روابط الهاتف ?m=1.

مراجعة HTTPS والنطاق المخصص

إذا ظهر الخطأ بعد ربط نطاق جديد أو تغيير إعدادات HTTPS، افحص الوجهة النهائية لكل من http:// وhttps:// وصيغتي النطاق مع www وبدونه. المطلوب أن تصل المسارات المعتمدة إلى عنوان صحيح دون دوران بين النسخ، وليس فرض سلسلة تحويلات جديدة دون حاجة.

راجع إعدادات HTTPS availability وHTTPS redirect في لوحة Blogger، وتحقق من أن إعدادات النطاق تتوافق مع طريقة ربطه الحالية. احتفظ بنسخة من إعداداتك قبل أي تعديل.

التحقق من Cloudflare عند استخدامه

إذا كان نطاق بلوجر يمر عبر Cloudflare، افحص قواعد Redirect Rules وPage Rules الموجودة، وإعدادات SSL/TLS، وأي قواعد تعتمد على User-Agent. قد تنشأ حلقة تحويل عندما تفرض جهة الاتصال الأصلية HTTPS بينما يطلب منها Cloudflare الاتصال عبر HTTP في وضع Flexible؛ وقد وثقت Cloudflare هذا السيناريو في شرح وضع Flexible.

لا يعني ذلك أن Cloudflare سبب الخطأ في كل موقع يستخدمه، ولا ينبغي تغيير وضع التشفير عشوائيًا؛ تحقق أولًا من إعدادات الاتصال بالأصل وشهادة HTTPS وتكوين النطاق قبل اختيار إعداد بديل.

ماذا لو نجح فحص الرابط لكنه لم يُفهرس؟

نجاح الاختبار المباشر يخبرك أن Google استطاع فحص الوجهة التي وصل إليها الآن، لكنه ليس شهادة بأن الرابط الأصلي مفهرس أو أن Google سيختاره بوصفه Canonical. راجع آخر زحف مسجل وسبب عدم الفهرسة، ثم افحص عنوان المقال الأساسي دون الوسيط ?m=1.

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

أخطاء شائعة يجب تجنبها

• إزالة ?m=1 بسكربت جاهز: قد يؤدي إلى تعطيل سلوك الهاتف أو إنشاء تحويلات إضافية بدل حل المشكلة.
• حظر روابط الهاتف عشوائيًا في robots.txt: قد يمنع Google من الوصول إلى نسخة يحتاج إلى فحصها، كما أن الحظر ليس بديلًا مناسبًا عن ضبط Canonical أو noindex.
• إضافة noindex دون فهم موضعه: قد يمنع فهرسة النسخة التي يعتمد عليها Google في الزحف عبر الهاتف.
• تغيير DNS أو قواعد Cloudflare فورًا: قد ينشئ عطلًا جديدًا إذا كانت إعادة التوجيه الأصلية طبيعية.
• الاعتقاد أن 301 أفضل دائمًا من 302: يختلف النوع المناسب بحسب ما إذا كان الانتقال دائمًا أو مؤقتًا.
• الثقة بوعود «إصلاح الخطأ خلال 24 ساعة»: لا توجد مدة ثابتة تضمن إعادة الزحف أو الفهرسة بعد أي تعديل.

جدول القرار: متى تحتاج إلى إصلاح خطأ إعادة التوجيه؟

ما الذي لاحظته؟	الإجراء المنطقي
تحويل 302 من رابط المقال إلى ?m=1، والمحتوى سليم والعنوان الأساسي صحيح.	لا تعدّل التحويل تلقائيًا؛ راقب حالة الصفحة الأساسية.
عنوان قديم يتحول إلى مقال جديد صحيح.	تحقق من فهرسة الوجهة؛ عدم فهرسة العنوان القديم قد يكون طبيعيًا.
الرابط يدور بين عنوانين أو يتوقف عند وجهة غير صالحة.	أصلح قاعدة التحويل أو الإعداد الذي يسبب المسار المكسور.
نسخة الهاتف لا تعرض المقال، أو تحتوي على noindex غير مقصود.	راجع القالب وإعدادات الفهرسة وعلاقة النسخة الأساسية بالبديلة.
الاختبار المباشر ناجح والتقرير القديم ما زال يعرض خطأ.	قارن تاريخ الزحف، وافحص النسخة الأساسية، ولا تستنتج نجاح الفهرسة من الاختبار وحده.
بدأت حلقة التحويل بعد تغيير SSL/TLS أو إعداد نطاق.	راجع إعدادات الطرفين وتسلسل التحويل قبل إجراء تعديل جديد.

أسئلة عملية مرتبطة بخطأ إعادة التوجيه

هل أضغط «التحقق من الإصلاح» بعد اختفاء المشكلة؟

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

هل تغيير قالب بلوجر يمكن أن يؤثر في الحالة؟

نعم، إذا كان القالب المعدل يزيل علامات Canonical أو يضيف قواعد noindex أو إعادة توجيه غير صحيحة. افحص القالب بعناية، خصوصًا عند استخدام قالب طرف ثالث، لكن لا تعدّله لمجرد رؤية رسالة واحدة في Search Console.

الخلاصة: شخّص السبب قبل أن تغيّر إعدادات بلوجر

أفضل طريقة للتعامل مع خطأ إعادة التوجيه في بلوجر هي البدء بعنوان URL المتأثر، ثم مقارنة بيانات آخر زحف بالاختبار المباشر، والتحقق من مسار التحويل ومن نسخة الهاتف والعنوان الأساسي. إذا ثبت وجود حلقة تحويل أو وجهة خاطئة فأصلح السبب المحدد. أما إذا كان التحويل إلى ?m=1 جزءًا من عمل Blogger وكانت النسخ سليمة، فلا تُنشئ مشكلة جديدة بمحاولة «إصلاح» سلوك طبيعي.

للتوسع يمكنك الرجوع إلى دليل Google لفهرسة الهاتف أولًا ومرجع حالات فهرسة الصفحات.