إعادة التوجيه عبر Meta Refresh
ما إعادة التوجيه عبر meta refresh، ولماذا تقع بين تحويلات الخادم وJavaScript في ترتيب تفضيلات Google، والفرق بين التحديث الفوري والمتأخر، ولماذا لا يُنصح بها.
اللغات
إعادة التوجيه عبر meta refresh هي وسم HTML بصيغة <meta http-equiv="refresh"> (أو ترويسة HTTP المكافئة Refresh)، وليست رمز حالة HTTP. يعيد الخادم 200 عادية، ولا ينفذ المتصفح التحويل إلا بعد اعتبار الصفحة محملة وفق معيار HTML؛ ولذلك هي أضعف من تحويل الخادم. تقرأ Google الصيغة الفورية (content="0") كتحويل دائم شبيه بـ301، والمتأخرة (content أكبر من 0) كمؤقتة، والتأخير هو السمة المرتبطة تاريخيًا برسائل صفحات المدخل المزعجة. يقول John Mueller إنها «ينبغي أن تعمل فحسب» لكنه لا يوصي بها لسببين: إبقاء الصفحة في سجل المتصفح «على حد علمه»، واضطرار Google إلى تحميل الصفحة وتحليلها قبل رؤية التحويل. لا تستخدمها إلا ملاذًا أخيرًا عند انعدام وصول الخادم، وفضّل صفر ثانية، واستبدلها بـ301 حقيقية بأسرع ما يمكن.
الخلاصة — إعادة توجيه meta refresh سطر HTML — وسم
Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable<meta http-equiv="refresh">— يطلب من المتصفح الانتقال إلى عنوان URL آخر بعد تحميل الصفحة. وهي ليست رمز حالة HTTP مثل 301؛ إذ يعيد الخادم صفحة عادية أولًا، ثم ينفذ المتصفح إعادة التوجيه. تعمل هذه الآلية، لكنها أبطأ وأقل سلاسة من إعادة التوجيه الحقيقية من جانب الخادم، لذلك لا تستخدمها إلا عند غياب أي خيار آخر.
ما إعادة توجيه meta refresh؟
تحدث معظم عمليات إعادة التوجيه على الخادم. تطلب عنوان URL، وقبل أن تستلم أي صفحة يجيب الخادم: «انتقلت الصفحة — اذهب إلى هنا بدلًا منها» (وهذه 301 أو 302). أما meta refresh فتعمل بصورة مختلفة تمامًا. يعيد الخادم صفحة عادية سليمة (200 OK)، وداخل HTML الصفحة تعليمة تطلب من المتصفح الانتقال إلى مكان آخر:
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">يوضع هذا الوسم في <head> الصفحة. يحدد الرقم السابق للفاصلة المنقوطة عدد ثواني الانتظار، ويحدد الجزء url= وجهة الزائر. ولأن المتصفح — لا الخادم — هو الذي ينفذ التعليمة، تسمى هذه إعادة توجيه من جانب العميل.
الفورية مقابل المتأخرة
لهذه الآلية نوعان فعليًا، والفرق بينهما هو ذلك الرقم فقط:
- فورية —
content="0;url=...". ينتقل المتصفح فور انتهاء تحميل الصفحة. هذه هي الصيغة التي ينبغي استخدامها إن اضطررت أصلًا إلى meta refresh. تتعامل معها Google كإعادة توجيه دائمة (شبيهة بـ301). - متأخرة —
content="5;url=..."(أي رقم أكبر من 0). يعرض المتصفح الصفحة بضع ثوان، ثم ينتقل. تتعامل Google معها كإعادة توجيه مؤقتة، والتأخير هو السمة التي أكسبت meta refresh تاريخيًا سمعتها السيئة المرتبطة بالرسائل المزعجة.
لماذا يوصي الناس بتجنبها؟
تعمل meta refresh، لكنها أضعف من إعادة توجيه الخادم لأن المتصفح لا ينفذ تعليمة الانتقال إلا بعدما تُعد الصفحة مكتملة التحميل — وهو شرط التشغيل في معيار HTML نفسه — لا قبل ذلك. أما إعادة التوجيه من جانب الخادم فتحدث فورًا قبل تحميل أي صفحة. وترتب إرشادات Google إعادة التوجيه من جانب الخادم أولًا، ثم meta refresh، ثم JavaScript أخيرًا.
إذًا القاعدة بسيطة: استخدم 301 حقيقية متى استطعت. لا تلجأ إلى meta refresh إلا على استضافة لا تتيح فعلًا إعداد إعادة توجيه من الخادم (كما في بعض الاستضافات الثابتة). وحتى حينها استخدم الصيغة الفورية (0)، واستبدلها بـ301 صحيحة بمجرد أن يصبح ذلك ممكنًا.
هل تريد الصورة الكاملة — نص Google الدقيق، وجانب إمكانية الوصول، وطريقة اكتشاف هذه التحويلات على موقعك؟ انتقل إلى تبويب متقدم.
الخلاصة — meta refresh وسم HTML بصيغة
Evidence for this claim Google supports instant and delayed meta refresh redirects but recommends server-side permanent redirects when possible. Scope: Google redirect processing and implementation preference. Confidence: high · Verified: Google Search Central: Redirects Evidence for this claim Timed redirects can create accessibility problems, particularly when users cannot control the time limit. Scope: WCAG timing guidance; not a search-ranking claim. Confidence: high · Verified: W3C WCAG: Timing Adjustable<meta http-equiv="refresh">(أو ترويسةRefreshالتي يضيفها الخادم)، وليست رمز حالة3xx. يعيد الخادم200، ولا ينتقل المتصفح إلا بعد اكتمال تحميل الصفحة. تقرأ Google الصيغة الفورية (content="0") كتحويل دائم شبيه بـ301/308، والمتأخرة (> 0) كمؤقتة. تقع بين إعادة التوجيه من جانب الخادم وJavaScript في ترتيب Google للموثوقية بسبب اعتمادها على اكتمال تحميل الصفحة. يقول Mueller إنها «ينبغي أن تعمل فحسب»، لكنه لا يوصي بها (سجل زر الرجوع + كلفة وقت التحليل). لا تستخدمها إلا عند انعدام وصولك الحقيقي إلى الخادم، وفضّل0، واقرنها بـrel=canonicalورابط احتياطي ظاهر، ثم استبدلها بـ301 حقيقية بأسرع ما يمكن.
ليست رمز حالة
هذه أهم حقيقة يجب ضبطها. meta refresh ليست استجابة HTTP من نوع 3xx. يعيد الخادم 200 OK عادية مع جسم صفحة كامل، وتوجد في <head> تلك الصفحة تعليمة HTML ينفذها المتصفح بعد تحميل الصفحة:
<!-- Instant: treated by Google as permanent -->
<meta http-equiv="refresh" content="0;url=https://example.com/newlocation">ولها مكافئ يضاف من جانب الخادم هو ترويسة HTTP المسماة Refresh؛ يؤدي الوظيفة نفسها، لكن شيفرة الخادم تضيفه بدل وجوده في الترميز:
HTTP/1.1 200 OK
Refresh: 0; url=https://www.example.com/newlocationلاحظ أن نسخة الترويسة أيضًا تعيد 200 لا 3xx. وفي الحالتين هذه إعادة توجيه من جانب العميل: المتصفح ينفذ الانتقال، لا الخادم.
الفورية مقابل المتأخرة — تقسيم Google
ترسم Google الحد عند عدد الثواني. ففي وثائق عمليات إعادة التوجيه وبحث Google تقول إنها “differentiates between two kinds of meta refresh redirects” (ترجمة) «تميز بين نوعين من عمليات إعادة التوجيه عبر meta refresh»:
- الفورية (
content="0") — «تُشغّل بمجرد تحميل الصفحة… يفسر بحث Google عملياتmeta refreshالفورية على أنها عمليات إعادة توجيه دائمة». لذلك تقع، من ناحية التوحيد القياسي، في الفئة نفسها مع 301/308: تتبعها Google وتستخدمها إشارة إلى أن الوجهة ينبغي أن تكون العنوان الأساسي. - المتأخرة (
contentأكبر من 0) — «لا تُشغّل إلا بعد عدد عشوائي من الثواني… يفسر بحث Google عملياتmeta refreshالمتأخرة على أنها عمليات إعادة توجيه مؤقتة». ومثل 302/303/307 قد تُفهرس الوجهة بإشارات أخرى، لكن إعادة التوجيه نفسها لا تُفهم كإشارة انتقال دائم.
يعكس ترتيبي الخاص في دليل Ahrefs عن 11 نوعًا من إعادة التوجيه هذا التقسيم: للانتقالات الدائمة أرتبها 308 / 301 ← meta refresh 0 ← JavaScript ← crypto، بينما تهبط meta refresh المتأخرة إلى المستوى المؤقت إلى جانب 302/303/307.
موضعها في ترتيب تفضيلات Google
تنشر وثائق Google جدول تفضيل حرفيًا، «مرتبًا بحسب مدى احتمال قدرة Google على تفسير [إعادة التوجيه] تفسيرًا صحيحًا». وترتيب التحويلات الدائمة هو: HTTP 301 ← HTTP 308 ← meta refresh (0 seconds) ← JavaScript location ← crypto. تقع meta refresh في الدرجة الوسطى — أدنى من الخادم وأعلى من JavaScript.
تصرح Google بالحدين. ففي الحد الأعلى: «إذا تعذر تنفيذ عمليات إعادة التوجيه من جانب الخادم على منصتك، فقد تكون عمليات meta refresh بديلًا صالحًا». وفي الحد الأدنى: «لا تستخدم عمليات إعادة التوجيه عبر JavaScript إلا إذا تعذر عليك استخدام إعادة التوجيه من جانب الخادم أو meta refresh». هاتان الجملتان تلخصان السلم كله، ويتطابق ذلك مع الصياغة في محور عمليات إعادة التوجيه، الذي يوضح أن JavaScript وmeta refresh المتأخرة أضعف لاعتمادهما على العرض.
ترتيبان مختلفان — لا تخلط بينهما
ثمة تفصيل دقيق يربك المطورين. تنشر MDN ترتيبًا مختلفًا لعمليات إعادة التوجيه، لكنه يتناول ترتيب التنفيذ في المتصفح عندما تتراكم آليات عدة على صفحة واحدة، لا موثوقية SEO. ترتيب MDN هو: تحويلات HTTP أولًا، ثم JavaScript، ثم meta refresh أخيرًا، لأن «إعادة التوجيه عبر <meta> تحدث بعد اكتمال تحميل الصفحة، أي بعد تنفيذ جميع النصوص البرمجية».
وهكذا «تسبق» JavaScript meta refresh في ترتيب التوقيت لدى MDN، بينما «تسبق» meta refresh JavaScript في ترتيب الموثوقية لدى Google. كلاهما صحيح لأنهما يجيبان عن سؤالين مختلفين. تسأل MDN: «أيها يعمل أولًا في المتصفح؟» (تعمل JavaScript المتزامنة أثناء التحميل قبل مؤقت meta refresh الذي يبدأ بعده). وتسأل Google: «أيها أرجح أن أفسره صحيحًا للبحث؟» (تُقرأ meta refresh مباشرة من HTML المحلل، بينما تحتاج إعادة توجيه JavaScript إلى نجاح مرحلة العرض المنفصلة لدى Google). افصل المحورين يختفِ التناقض الظاهري.
لماذا تعتمد على تحميل الصفحة — ولماذا يضعفها ذلك؟
لا يمكن تشغيل meta refresh حتى يكتمل تحميل الصفحة. ووفق مرجع MDN لـ<meta http-equiv>، «يبدأ المؤقت عندما يكتمل تحميل الصفحة، بعد تشغيل الحدثين load وpageshow». ويصح ذلك حتى مع content="0": فـ«فورية» تعني صفر تأخير إضافي بعد التحميل، لا صفر وقت منقضٍ. تؤخر الصفحة البطيئة حتى تحديث الصفر ثانية بطريقة لا تحدث مع 3xx من الخادم، لأن الخادم يرسل التحويل قبل تحميل أي صفحة.
وللدقة: لا تُعالج meta refresh في مرحلة العرض لدى Google (تنفيذ JS) مثل إعادة توجيه window.location، بل تُقرأ مباشرة من <head> في HTML المحلل. ضعفها ليس خط أنابيب العرض، بل الاعتماد على تحميل الصفحة كلها (اكتمال الشبكة والموارد الحاجبة للعرض)، إضافة إلى انتظار اعتباطي في الصيغ المتأخرة.
ما الذي يحدده معيار HTML فعلًا؟
تقدم خوارزمية التحديث التصريحي في معيار HTML وصفًا أدق من «تنتظر تحميل الصفحة»، وتهم بعض تفاصيلها في التدقيق واستكشاف الأخطاء:
- وقت الاستحقاق. يصبح التحديث مستحقًا بعد وقت اكتمال تحميل المستند، وبالنسبة إلى عنصر
<meta>تحديدًا بعد وقت إدراجه — أيهما يأتي لاحقًا — مع التعديل وفق تفضيلات المستخدم. هذه هي صيغة المواصفة لعبارة «بعد تحميل الصفحة». أما أحداث الشبكة/العرض التي تعد «تحميلًا» في متصفح بعينه فهي تفصيل تنفيذي، ولا يسردها المعيار كتسلسل عالمي للجلب والرسم. - عناوين URL النسبية. تُحلل وجهة التحديث نسبة إلى عنوان المستند نفسه، لذلك استخرج الوجهة المطلقة عند التدقيق بدل الثقة بالنص الحرفي في
url=؛ فقد يقود المسار النسبي إلى مكان غير الذي يوحي به ظاهره. - الأول يفوز. متى وُسم المستند بالفعل لإجراء تحديث تصريحي، تتجاهل الخوارزمية أي تعليمة تحديث لاحقة في الصفحة. وجود وسمَي
<meta refresh>متعارضين (أو وسم مع ترويسةRefresh) ليس خطة احتياطية، بل عيب تأليف، ولا يعمل إلا الأول. - تُرفض وجهات
javascript:. إذا استخدمت الوجهة المحللة مخططjavascript:، تنتهي الخوارزمية بلا انتقال. - التشغيل غير مضمون. يسمح المعيار صراحة بإلغاء الانتقال، أو تعديله بتفضيلات المستخدم أو وكيل المستخدم، أو حجبه بقيود الميزات التلقائية في مستند sandbox، أو عرضه في واجهة المتصفح، أو عدم تنفيذه ببساطة. لا تتعامل مع «سيعيد التوجيه» كحقيقة مطلقة.
- التعامل مع السجل. يحدد المعيار تعامل replace مع سجل انتقال التحديث؛ أي إن نص المواصفة يجعل المتصفح يستبدل قيد السجل الحالي بدل إضافة قيد جديد. يجدر إبراز ذلك مقابل صياغة «يبقي الصفحة القديمة في سجل المتصفح» أدناه: فقد أبلغ متحدث معروف باسم Google عن هذا السلوك الواقعي في 2018، وربما لا يزال يحدث عمليًا، لكنه ليس ما يصفه نص المواصفة الحالي. تعامل مع “meta refresh always leaves the source page in history” (ترجمة) «meta refresh تترك دائمًا صفحة المصدر في السجل» كقول شائع غير مؤكد، لا كسلوك محسوم؛ فإثباته يحتاج اختبارًا خاصًا بكل متصفح وإصدار، وهو خارج ما تثبته هذه المصادر.
لخص John Mueller حجة «لماذا لا نوصي بها» (كما نقلها Search Engine Roundtable، 2018): ينبغي لـmeta refresh «أن تعمل فحسب»، لكن Google لا توصي بها لسببين: تجربة المستخدم (“it keeps the page in browser history, afaik” (ترجمة) «تبقي الصفحة في سجل المتصفح، على حد علمي» — وهذا تحفظه الشخصي)، ووقت المعالجة (يجب أن تحلل Google الصفحة حتى ترى إعادة التوجيه). «وبعد معالجتها تصبح مثل إعادة توجيه فحسب». هذا تفسير أنفع من «قديمة ومزعجة»، لأنه يسمي تكاليف ملموسة غير مرتبطة بالرسائل المزعجة، حتى لو كان نصف السجل ملاحظة منقولة لا ضمانًا موثقًا في المواصفة (انظر أعلاه).
لماذا لا يُنصح بها — الإرث التاريخي
بعيدًا عن سببي تجربة المستخدم ووقت التحليل عند Mueller، تحمل meta refresh سمعة تاريخية. ففي حقبة رسائل الويب المزعجة في الألفينيات كانت وسيلة شائعة لإنشاء صفحات المدخل: ترتب صفحة لاستعلام، ثم تحول الزائر شبه فوريًا بـmeta refresh إلى وجهة أخرى أقل صلة، فتُظهر لمحركات البحث والمستخدمين نتائج مختلفة عمليًا. من هنا جاءت صفة «مزعجة». وللدقة، لا تسمي أي صفحة حالية لسياسات Google لمكافحة المحتوى غير المرغوب فيه «meta refresh» صراحة؛ بل تعرف السياسات «عمليات إعادة التوجيه المخادعة» وإساءة استخدام «صفحات المدخل» كفئات عامة كانت meta refresh تاريخيًا آلية لها. تعامل مع ذلك كسياق تاريخي/صناعي، لا كاستشهاد صريح بسياسة حالية.
وثمة أيضًا نمط فشل ملموس وغير مزعج أشار إليه Mueller في جلسة عام 2018 (عبر Search Engine Journal): موقع كان يحول صفحات القوائم بـmeta refresh إلى صفحة دفع مشتركة. «إذا فعلت ذلك عبر صفحاتك فثمة احتمال كبير أن نتبع إعادة التوجيه ونظن: هذه صفحة الدفع التي تريد فهرستها لا المحتوى الفعلي». وقد يؤدي تحديث صفحات مصدر كثيرة إلى وجهة عامة واحدة إلى فهرسة الوجهة بدل محتواك.
لا يجعل أي من ذلك استخدامًا منفردًا ومشروعًا لـmeta refresh عرضة للعقوبة. تسمي وثائق Google الحالية نفسها هذه الآلية «بديلًا صالحًا» حين تتعذر إعادة التوجيه من جانب الخادم. الخطر في النمط والنية، لا الآلية.
Evidence for this claim Google says meta refresh can be a viable alternative when server-side redirects are not possible, while permanent server-side redirects are recommended whenever possible for a URL move. Scope: meta refresh and HTTP Refresh interpretation Confidence: high · Verified: Redirects and Google Searchإمكانية الوصول: التقسيم نفسه بين الفورية والمتأخرة
يكاد تأطير SEO يطابق إرشادات إمكانية الوصول، مع قيد يجب ذكره أولًا: تقنيات WAI لدى W3C، بكلماتها، أمثلة لطرق تحقيق معايير نجاح WCAG وليست قواعد امتثال إلزامية. لا يعني تحقيق تقنية بعينها أو تفويتها نجاحًا أو فشلًا تلقائيًا؛ المتطلب الفعلي هو معيار النجاح (هنا 2.2.1، قابلية ضبط التوقيت). ومع ذلك يطابق تفضيل W3C إرشادات SEO أعلاه: توصي بإعادة توجيه من جانب الخادم أولًا، وعندما تلزم إعادة توجيه من جانب العميل فعلًا، تطلب تقنيتاها الكافيتان (H76 وG110) عدم وجود تأخير (content="0") وأن يقتصر محتوى صفحة المصدر على معلومات التحويل مع رابط ظاهر إلى الوجهة. هذا أضيق من «كل تحديث بصفر ثانية ينجح تلقائيًا»؛ النمط الكافي الموثق هو «صفر تأخير، ومحتوى خاص بالتحويل، ورابط احتياطي». أما meta refresh المتأخرة التي لا يمكن إيقافها أو تمديدها أو تعطيلها فقد تفشل 2.2.1، لأنها قد تنقل المستخدم قبل أن ينتهي مستخدم قارئ الشاشة أو ضعيف البصر من القراءة. لكن تحديد فشل تحديث بعينه يتطلب تقييم WCAG لكل حالة، ولا يحسمه رقم التقنية وحده. تصف ملاحظة إمكانية الوصول في MDN الخطر نفسه: فترات التحديث القصيرة جدًا قد تجعل مستخدمي التقنيات المساعدة «غير قادرين على قراءة محتوى الصفحة وفهمه قبل إعادة توجيههم تلقائيًا».
وهكذا يصل محرك البحث وهيئة المعايير إلى القاعدة نفسها: الفورية مقبولة، والمتأخرة محفوفة بالمخاطر. وهذا تعزيز مفيد وسبب إضافي لتفضيل content="0" إذا استخدمت meta refresh أصلًا.
متى تكون ملاذًا أخيرًا مشروعًا؟
لا تستخدم meta refresh إلا عندما يتعذر عليك فعلًا إعداد إعادة توجيه من جانب الخادم. ومن الحالات الواقعية:
- استضافات ثابتة بلا إعداد للخادم — مثل GitHub Pages، حيث لا يمكنك إضافة قواعد
.htaccess/nginx. - مولدات مواقع ثابتة تُخرج ميزة «الأسماء البديلة» فيها meta refresh لا 301. وHugo مثال معروف؛ إذ تولد
aliases:في بياناته الأمامية ملفات HTML صغيرة تستخدم meta refresh، لا تحويلات خادم حقيقية. (مزيد في Hugo SEO.) - صادرات منصات no-code/منشئات المواقع وبعض مولدات الوثائق التي لا تتيح إلا إخراج HTML ثابت.
إذا اضطررت إليها، فنفذها جيدًا:
- فضّل الفورية (
content="0") على أي تأخير؛ فهي إشارة دائمة وتجتاز عتبة إمكانية الوصول. - اقرنها بـ
rel="canonical"يشير إلى الوجهة، لتكون نية التوحيد صريحة حتى قبل أن تعالج Google التحديث. - أضف رابطًا احتياطيًا ظاهرًا وقابلًا للنقر في الجسم لحالة المتصفح أو إعداد التقنية المساعدة النادر الذي يعطل التحديث التلقائي.
- لا تضعها داخل سلسلة إعادة توجيه؛ فإذا أضيف لاحقًا تحويل من الخادم إلى عنوان صفحة meta refresh نفسها، تكون قد أنشأت سلسلة (انظر سلاسل إعادة التوجيه).
- استبدلها بـ301 حقيقية بمجرد حصولك على وصول إلى الخادم. meta refresh جسر لا وجهة.
اكتشاف meta refresh على موقعك
تظهرها برامج الزحف عادة كتنبيه بشدة منخفضة إلى متوسطة لا كخطأ حرج؛ وتبلغ عنها Screaming Frog وSitebulb وAhrefs Site Audit وSemrush. إذا اقتصرت على بضعة عناوين URL منفردة فهي مسألة «أصلحها عند التيسر» لا حالة طارئة؛ أما استخدامها على مستوى الموقع أو في صفحات مهمة فيستحق الأولوية. لفحص عنوان واحد يدويًا، اعرض المصدر أو اجلب الصفحة بـcurl وابحث عن http-equiv="refresh" في <head> (توجد مقتطفات جاهزة في عدسة النصوص البرمجية).
احذر الادعاءات في كلا الاتجاهين بشأن قيمة الروابط. تستحق عبارة مركز مساعدة Ahrefs أن meta refresh “does not pass much or any link juice” (ترجمة) «لا تمرر قدرًا كبيرًا من link juice أو لا تمرر شيئًا» التشكيك؛ فجدول Google يصنف meta refresh الفورية في فئة تفسير التحويل الدائم نفسها مع 301. هذه إشارة إلى طريقة قراءة Google للتحويل وتوحيده، لا وعدًا بتطابق PageRank أو قيمة الروابط أو انتقال الترتيب. لا تقدم وثائق Google للتحويلات ولا معيار HTML ادعاء صريحًا عن تكافؤ القيمة بين meta refresh و301. لذلك تعامل مع «تمرر القيمة نفسها كـ301» و«تمرر قليلًا أو لا شيء» كادعاءين غير مثبتين بالقدر نفسه، خارج الموثق فعلًا: تصنفها Google دائمة وتعالجها بعد تحميل الصفحة.
لصفحة مصدر meta refresh استجابة HTTP ومستند HTML خاصان بها؛ فلا ينبغي أن يتوقف تدقيقها عند قراءة الوسم. افحص بالترتيب: حالة HTTP وترويسات استجابة عنوان المصدر (بما فيها ترويسة Refresh محتملة)؛ HTML الخام مقابل ما يحلله المتصفح فعلًا؛ تعليمة التحديث الأولى (والفعالة لذلك) ووجهتها المطلقة بعد الحل؛ تصنيف جدول Google لها (فورية/دائمة مقابل متأخرة/مؤقتة)؛ وسم canonical وتوجيهات robots وقابلية الفهرسة في المصدر؛ استجابة الوجهة النهائية؛ إمكان إلغاء التحويل أو التحكم فيه أو تجاوزه بتفضيلات المستخدم/المتصفح؛ سلوك التخزين المؤقت والسجل في المتصفح والإصدار المحددين اللذين تختبرهما، لا كادعاء عالمي؛ الروابط الداخلية التي لا تزال تشير إلى المصدر؛ وأخيرًا خطتك لاستبداله بإعادة توجيه من جانب الخادم. تحوّل عدستا قوائم التحقق والنصوص البرمجية في هذه الصفحة ذلك إلى خطوات وأوامر عملية.
ملخص الذكاء الاصطناعي
خلاصة مكثفة للنسخة المتقدمة:
- ليست رمز حالة. meta refresh وسم HTML بصيغة
<meta http-equiv="refresh">(أو ترويسة HTTP المسماةRefresh). يعيد الخادم200، وينتقل المتصفح بعد اكتمال تحميل الصفحة. إنها إعادة توجيه من جانب العميل. - الفورية مقابل المتأخرة.
content="0"يعني أن Google تعاملها كتحويل دائم (مثل 301/308). وcontent > 0يعني مؤقتًا (مثل 302/303/307)، والتأخير هو السمة المرتبطة برسائل صفحات المدخل القديمة المزعجة. - وسط ترتيب Google. من جانب الخادم ← meta refresh ← JavaScript ← crypto. تقول Google: «إذا تعذرت إعادة التوجيه من جانب الخادم… فقد تكون meta refresh بديلًا صالحًا»، و*«لا تستخدم JavaScript إلا إذا تعذر استخدام الخادم أو meta refresh».*
- «ترتيبان» مختلفان. يضع ترتيب التنفيذ لدى MDN JavaScript قبل meta refresh (لأنها تعمل بعد التحميل وبعد النصوص البرمجية). ويضع ترتيب الموثوقية لدى Google meta refresh فوق JavaScript. كلاهما صحيح؛ فالسؤال مختلف.
- سبب الضعف: تؤجلها خوارزمية وقت الاستحقاق في معيار HTML حتى تحميل الصفحة، حتى مع
0، ويمكن إلغاء الانتقال أو تخطيه بتفضيلات المستخدم/المتصفح؛ فلا ضمان بنسبة 100%. يقول Mueller إنها «ينبغي أن تعمل فحسب» لكنه لا يوصي بها (سجل المتصفح «على حد علمي» + كلفة التحليل). نقطة السجل ملاحظة منقولة عنه وليست مما يقوله نص المواصفة الحالي، الذي يحدد تعامل replace. - قيمة الروابط غير مثبتة في الاتجاهين. يجمع جدول Google meta refresh الفورية مع 301 لأغراض التفسير، لا بوصفه وعدًا موثقًا بتكافؤ PageRank/القيمة؛ فلا تبالغ في أي اتجاه.
- إمكانية الوصول تعكس SEO مع قيد: تفضل W3C تحويلات الخادم أيضًا، وتطلب تقنيتاها الكافيتان H76/G110 صفر تأخير + محتوى خاص بالتحويل + رابطًا احتياطيًا. لكنها أمثلة لتقنيات لا قواعد امتثال إلزامية. قد يفشل التحديث المتأخر بلا تحكم للمستخدم معيار 2.2.1 لقابلية ضبط التوقيت، ويُقيّم ذلك حالة بحالة.
- استخدمها ملاذًا أخيرًا فقط (GitHub Pages وHugo
aliasesوالاستضافة الثابتة/no-code). فضّل0، وأضفrel=canonicalورابطًا احتياطيًا ظاهرًا، وتجنب السلاسل، واستبدلها بـ301 حقيقية بأسرع ما يمكن.
الوثائق الرسمية
وثائق المصادر الأولية عن meta refresh وموضعها.
- عمليات إعادة التوجيه وبحث Google — جدول تفضيل التحويلات، وتعريف الفورية مقابل المتأخرة، وصياغة «البديل الصالح».
- سياسات المحتوى غير المرغوب فيه لبحث Google — تعرف «عمليات إعادة التوجيه المخادعة» وإساءة استخدام «صفحات المدخل» كفئات عامة (ملاحظة: لا تسمي meta refresh صراحة).
MDN
<meta http-equiv>— آلية جانب العميل: المؤقت «يبدأ عندما يكتمل تحميل الصفحة».- ترويسة HTTP المسماة
Refresh— المكافئ الذي يضيفه الخادم. - عمليات إعادة التوجيه في HTTP — ترتيب التنفيذ في المتصفح (وهو مختلف عن ترتيب SEO لدى Google).
W3C / WCAG
- H76: استخدام meta refresh لإنشاء إعادة توجيه فورية من جانب العميل — يفضّل الخادم؛ وعند تعذره يكون نمط الصفر ثانية ذي المحتوى الخاص بالتحويل تقنية كافية (لا قاعدة إلزامية).
- G110: استخدام إعادة توجيه فورية من جانب العميل — النسخة العامة غير الخاصة بـHTML من التقنية نفسها.
- F41: الفشل بسبب استخدام meta refresh بمهلة زمنية — كيف يمكن لتحديث متأخر بلا تحكم أن يفشل معيار 2.2.1 لقابلية ضبط التوقيت؛ إنها صفحة تقنية/فشل وليست بذاتها متطلب الامتثال.
اقتباسات من المصدر
تصريحات موثقة. يقود كل رابط مباشرة إلى موضع النص المقتبس.
Google — وثائق عمليات إعادة التوجيه وبحث Google
- “The following table explains the various ways you can use to set up permanent and temporary redirects, ordered by how likely Google is able to interpret correctly (for example, a server side redirect has the highest chance of being interpreted correctly by Google).” (ترجمة) «يوضح الجدول التالي الطرق المختلفة لإعداد عمليات إعادة توجيه دائمة ومؤقتة، مرتبة بحسب مدى احتمال قدرة Google على تفسيرها تفسيرًا صحيحًا؛ فمثلًا تتمتع إعادة التوجيه من جانب الخادم بأعلى احتمال للتفسير الصحيح.» الانتقال إلى الاقتباس
- “If server-side redirects aren’t possible to implement on your platform, meta refresh redirects may be a viable alternative.” (ترجمة) «إذا تعذر تنفيذ عمليات إعادة التوجيه من جانب الخادم على منصتك، فقد تكون عمليات meta refresh بديلًا صالحًا.» الانتقال إلى الاقتباس
- “Google differentiates between two kinds of meta refresh redirects: Instant meta refresh redirect: Triggers as soon as the page is loaded in a browser. Google Search interprets instant meta refresh redirects as permanent redirects. Delayed meta refresh redirect: Triggers only after an arbitrary number of seconds set by the site owner. Google Search interprets delayed meta refresh redirects as temporary redirects.” (ترجمة) «تميز Google بين نوعين من عمليات meta refresh: الفورية التي تُشغّل بمجرد تحميل الصفحة في المتصفح ويفسرها بحث Google كإعادة توجيه دائمة، والمتأخرة التي لا تُشغّل إلا بعد عدد من الثواني يحدده مالك الموقع ويفسرها بحث Google كإعادة توجيه مؤقتة.» الانتقال إلى الاقتباس
- “Place the meta refresh redirect either in the <head> element in the HTML or in the HTTP header with server-side code.” (ترجمة) «ضع إعادة توجيه meta refresh إما في عنصر <head> في HTML أو في ترويسة HTTP بواسطة شيفرة من جانب الخادم.» الانتقال إلى الاقتباس
- “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (ترجمة) «لا تستخدم عمليات إعادة التوجيه عبر JavaScript إلا إذا تعذر عليك استخدام إعادة التوجيه من جانب الخادم أو meta refresh.» الانتقال إلى الاقتباس
- “While Google attempts to render every URL Googlebot crawled, rendering may fail for various reasons. This means that if you set a JavaScript redirect, Google might never see it if rendering of the content failed.” (ترجمة) «مع أن Google تحاول عرض كل عنوان URL زحف إليه Googlebot، فقد يفشل العرض لأسباب مختلفة. وهذا يعني أن Google قد لا ترى إعادة توجيه JavaScript مطلقًا إذا فشل عرض المحتوى.» الانتقال إلى الاقتباس
John Mueller، Google (تغريدات نقلها Search Engine Roundtable، 2 مارس 2018)
- “A meta refresh type redirect should just work. We don’t recommend it for 2 reasons: UX (it keeps the page in browser history, afaik) & processing time (we need to parse the page to see it). Once processed, it’s just like a redirect.” (ترجمة) «ينبغي لإعادة توجيه من نوع meta refresh أن تعمل فحسب. لا نوصي بها لسببين: تجربة المستخدم (تبقي الصفحة في سجل المتصفح، على حد علمي) ووقت المعالجة (نحتاج إلى تحليل الصفحة لنراها). وبعد معالجتها تصبح مثل إعادة توجيه فحسب.» الانتقال إلى الاقتباس
John Mueller، Google (جلسة Webmaster Central، يوليو 2018، نقلها Search Engine Journal)
- “So if you do this across your pages there’s a big chance we’ll follow this redirect and think ‘Oh, this payment page is actually what you want to have indexed and not the actual content,’ and in that case we won’t have the content indexed.” (ترجمة) «إذا فعلت ذلك عبر صفحاتك فثمة احتمال كبير أن نتبع إعادة التوجيه ونظن أن صفحة الدفع هي التي تريد فهرستها لا المحتوى الفعلي؛ وعندها لن يكون المحتوى مفهرسًا.» الانتقال إلى الاقتباس
MDN
- “The timer starts when the page is completely loaded, which is after the load and pageshow events have both fired.” (ترجمة) «يبدأ المؤقت عندما يكتمل تحميل الصفحة، بعد تشغيل الحدثين load وpageshow.» قراءة الوثيقة
- “When possible, use HTTP redirects and don’t add <meta> element redirects.” (ترجمة) «استخدم عمليات إعادة التوجيه عبر HTTP متى أمكن، ولا تضف عمليات إعادة توجيه بعنصر <meta>.» قراءة الوثيقة
أي إعادة توجيه ينبغي أن أستخدم؟
meta refresh خيار احتياطي لا خيار أول. ابدأ بأقوى حل يمكنك تنفيذه فعلًا وانتقل نزولًا.
Choosing a redirect when meta refresh is on the table
خرافات وأخطاء meta refresh
مفاهيم خاطئة شائعة، وما هو صحيح فعلًا.
«meta refresh إعادة توجيه HTTP / رمز حالة 3xx.»
لا. إنها وسم HTML (أو ترويسة HTTP المسماة Refresh) ينفذه المتصفح بعد استجابة 200 عادية وتحميل الصفحة كاملًا، وليست رمز حالة يرسله الخادم قبل أي محتوى.
«تعمل meta refresh بصفر ثانية فورًا قبل تحميل الصفحة.»
لا. وفق MDN، المؤقت «يبدأ عندما يكتمل تحميل الصفحة». تعني content="0" صفر تأخير إضافي بعد التحميل، لا صفر وقت منقضٍ. وهذا بالتحديد سبب ذكر Mueller «وقت المعالجة (نحتاج إلى تحليل الصفحة لنراها)» حتى للصيغة الفورية.
«meta refresh هي عمليًا إعادة توجيه JavaScript نفسها.» ليس تمامًا. كلتاهما من جانب العميل، لكن meta refresh معلنة في HTML وتُقرأ مباشرة من المستند المحلل، بينما تحتاج إعادة توجيه JS إلى تنفيذ النص البرمجي. ترتب Google meta refresh فوق JS في الموثوقية، ويضع ترتيب التنفيذ في MDN JavaScript المتزامنة قبل meta refresh. كلاهما صحيح لأن السؤال مختلف.
«meta refresh لا تمرر أي قيمة روابط / PageRank.» القول غير مدعوم، وكذلك نقيضه. يضع جدول Google meta refresh الفورية في فئة تفسير التحويل الدائم نفسها مع 301/308، وهذا يتعلق بكيفية تصنيف Google للإشارة وتوحيدها. لا تقدم وثائق Google ولا معيار HTML تصريحًا صريحًا عن التكافؤ في PageRank أو قيمة الروابط أو الترتيب بين الآليتين؛ فلا تدّعِ التكافؤ في أي اتجاه خارج التصنيف الموثق.
«meta refresh مزعجة دائمًا وستعاقب موقعي.» خطأ كتعميم. لها صلة تاريخية برسائل صفحات المدخل المزعجة، لكن استخدامها المشروع مرة واحدة، مثل استضافة ثابتة بلا وصول إلى الخادم، ليس إشارة محتوى مزعج. تسميها وثائق Google الحالية «بديلًا صالحًا». الخطر في النمط والنية (الإخفاء أو تحويل صفحات كثيرة إلى محتوى غير ذي صلة)، لا الآلية.
«تأخير بضع ثوان مجاملة لطيفة في تجربة المستخدم، لا مشكلة حقيقية.» الإجابة مختلطة. يخفض أي تأخير أكبر من 0 التصنيف لدى Google إلى مؤقت، وتعد تقنيات W3C لإمكانية الوصول التأخير غير القابل للتحكم نمطًا ينبغي تجنبه. لكن تفويت تقنية لا يعني وحده انتهاك WCAG تلقائيًا؛ الحاسم هو تحقيق معيار النجاح الفعلي (2.2.1، قابلية ضبط التوقيت). ونمط «بضع ثوان ليقرأ المستخدم رسالة» بلا إمكان الإيقاف أو التمديد أو التخطي هو بالضبط ما قد يفشل ذلك المعيار.
«أبلغ برنامج الزحف عن وسم meta refresh؛ إنها مشكلة حرجة يجب إصلاحها الآن.» هذا مبالغ فيه للحالات المنفردة. تصنف أدوات مثل Screaming Frog المسألة تحذيرًا منخفض الشدة. يستحق استبدالها بـ301 حقيقية عند توفر وصول الخادم، لكنها ليست في درجة إلحاح التحويلات المعطلة أو الحلقات أو إشارات الفهرسة المفقودة، إلا إن كانت على مستوى الموقع أو في صفحات عالية القيمة.
قائمة تحقق عند الاضطرار إلى شحن meta refresh
لا تستخدم هذه القائمة إلا بعد تأكيد عدم توفر إعادة توجيه من جانب الخادم فعلًا:
- تأكدت من عدم وجود خيار تحويل من جانب الخادم (فحصت إعدادات الاستضافة، ووصول
.htaccess/nginx، وقواعد CDN، وإعداد إطار العمل). - استخدمت الصيغة الفورية —
content="0"— لا المتأخرة. - يوجد الوسم في
<head>، وقيمةurl=هي الوجهة النهائية (لا تحويلًا آخر؛ تجنب بناء سلسلة). - أضفت
rel="canonical"يشير إلى عنوان URL الوجهة. - أضفت رابطًا احتياطيًا ظاهرًا وقابلًا للنقر في الجسم لمن يعطل إعداد المتصفح/التقنية المساعدة لديه التحديث التلقائي.
- تعيد الوجهة
200سليمة (وليست 404 أو تحويلًا أو خطأ). - سجلت متابعة لاستبدالها بـ301 حقيقية عند توفر وصول الخادم.
تدقيق meta refresh عبر الموقع
- شغلت زحفًا (Screaming Frog / Sitebulb / Ahrefs Site Audit / Semrush) وصدّرت كل عناوين URL الموسومة كتحويلات meta refresh.
- فحصت لكل عنوان حالة HTTP وترويسات الاستجابة (ومنها ترويسة
Refreshمحتملة)، لا HTML وحده. - حددت تعليمة التحديث الأولى (الفعالة) عند وجود أكثر من واحدة، وحللت وجهة
url=إلى عنوان URL مطلق. - صنفتها فورية أو متأخرة لتوقع معاملة Google الدائمة/المؤقتة، وفحصت منفصلًا وسم canonical وتوجيهات robots وقابلية الفهرسة في صفحة المصدر.
- تحققت هل هي منفردة (أولوية منخفضة) أم على مستوى الموقع / في صفحات عالية القيمة (أولوية أعلى).
- بحثت عن نمط صفحة الدفع: صفحات مصدر كثيرة تتحول إلى وجهة عامة واحدة قد تُفهرس بدل محتواك.
- وسمت كل التحديثات المتأخرة كمشكلة SEO وإمكانية وصول معًا.
ورقة غش meta refresh
النوعان
| النوع | الصيغة | معاملة Google | إمكانية الوصول |
|---|---|---|---|
| فورية | content="0;url=..." | دائمة (مثل 301/308) | تقنية كافية (H76/G110) |
| متأخرة | content="5;url=..." (أي > 0) | مؤقتة (مثل 302/303/307) | قد تفشل 2.2.1 (نمط F41) |
تفضيل Google للتحويلات الدائمة، من الأقوى إلى الأضعف
| الرتبة | الطريقة | ملاحظات |
|---|---|---|
| 1 | 301 / 308 (من جانب الخادم) | الأفضل؛ تعمل قبل تحميل أي صفحة |
| 2 | meta refresh 0 | تُقرأ كدائمة، لكنها أبطأ وأقل سلاسة (تحتاج تحميلًا كاملًا) |
| 3 | JavaScript location | تحتاج العرض؛ وقد لا تُرى إذا فشل العرض |
| 4 | تحويل crypto | ملاذ أخير حقيقي؛ لا تدعمه كل برامج الروبوت |
ترتيبان، فلا تخلط بينهما
| السؤال | الترتيب |
|---|---|
| Google — موثوقية SEO | من جانب الخادم ← meta refresh ← JavaScript ← crypto |
| MDN — توقيت التنفيذ في المتصفح | HTTP ← JavaScript ← meta refresh |
حقائق سريعة
- ليست رمز حالة؛ يعيد الخادم
200وينتقل المتصفح بعد التحميل الكامل. - ترويسة HTTP المسماة
Refresh:هي المكافئ الذي يضيفه الخادم (ولا تزال200). - «فورية» تعني صفر تأخير بعد التحميل، لا صفر وقت منقضٍ.
- سببا «عدم التوصية» عند Mueller: سجل المتصفح (قوله المنقول «على حد علمي») + كلفة وقت التحليل. ويحدد المعيار نفسه تعامل replace مع السجل.
- التكافؤ مع 301 في قيمة الروابط/PageRank غير موثق في الاتجاهين؛ فلا تدّعه.
- توسِمها برامج الزحف بشدة منخفضة إلى متوسطة لا حرجة.
- لا تستخدمها إلا بلا وصول إلى الخادم (GitHub Pages وHugo
aliasesوالاستضافة الثابتة/no-code).
اكتشاف وسوم meta refresh وقراءتها
فحص عنوان URL واحد من سطر الأوامر
# Fetch the page and look for the meta refresh tag in the HTML
curl -s https://example.com/old-page/ | grep -i 'http-equiv=["'"'"']*refresh'
# Also check for the server-side Refresh header (case-insensitive)
curl -sI https://example.com/old-page/ | grep -i '^refresh:'تعيد صفحة meta refresh الرمز 200 (لا 3xx)، لذلك سيفوّتها أمر curl -I العادي الذي لا يفحص إلا رموز الحالة؛ يجب أن تفحص الجسم وترويسة Refresh تحديدًا.
استخراج الوجهة بتعبير نمطي
تجمع سمة content التأخير وعنوان URL في N;url=.... يستخرج هذا الأمر كليهما:
curl -s https://example.com/old-page/ \
| grep -io 'content=["'"'"']*[0-9]\+; *url=[^"'"'"'>]*'
# → content="0;url=https://example.com/newlocation"إذا كان الرقم الأول 0 فهي فورية (دائمة لدى Google)، وأي رقم أكبر من 0 يعني متأخرة (مؤقتة).
XPath (لـDOM معروض أو محلل XML/HTML)
//meta[translate(@http-equiv,'REFSH','refsh')='refresh']/@contentتحول translate() السمة إلى أحرف صغيرة لتطابق Refresh أو REFRESH أو refresh.
وحدة تحكم Chrome DevTools — فحص الصفحة الحالية
// Is there a meta refresh on this page, and where does it point?
const m = document.querySelector('meta[http-equiv="refresh" i]');
console.log(m ? m.getAttribute('content') : 'no meta refresh');Bookmarklet — وسم meta refresh في أي صفحة تعرضها
javascript:(()=>{const m=document.querySelector('meta[http-equiv="refresh" i]');alert(m?('Meta refresh: '+m.getAttribute('content')):'No meta refresh tag on this page');})();احفظه كإشارة مرجعية؛ سيخبرك النقر عليه في أي صفحة هل توجد meta refresh وما قيمة content فيها. وهذا مفيد لفحص عنوان URL سريعًا قبل أن ينقلك التحديث بعيدًا.
ترتيبان وسؤالان مختلفان
تظهر meta refresh في ترتيبين للتحويلات يبدوان متناقضين إلى أن تسمي المحور المقاس.
| الترتيب | السؤال | التسلسل | المعنى |
|---|---|---|---|
| تنفيذ المتصفح | أي آلية تعمل أولًا عند وجود عدة آليات؟ | تحويل HTTP ← JavaScript ← meta refresh | تنتظر meta refresh تحميل الصفحة، وقد تعمل JavaScript المتزامنة أولًا |
| موثوقية Google | أي آلية أرجح أن تفسرها Google صحيحًا؟ | 301/308 من الخادم ← meta refresh فورية ← JavaScript | HTML المحلل أوثق من تحويل يتطلب نجاح عرض JavaScript |
استخدم هذا الإطار في ثلاث خطوات:
- حدد السؤال. استكشاف ما فعله المتصفح مشكلة ترتيب تنفيذ، واختيار آلية هجرة SEO مشكلة ترتيب موثوقية.
- لا تحول التوقيت إلى تزكية. عمل JavaScript قبل meta refresh لا يجعلها طريقة Google المفضلة للتحويل.
- اختر أقوى طبقة متاحة. تبقى إعادة التوجيه الدائمة الحقيقية من جانب الخادم الخيار الافتراضي. وعندما يتعذر الوصول إلى الخادم فعلًا، استخدم meta refresh فورية (
0ثانية) مع canonical ورابط احتياطي ظاهر، ثم استبدلها عند توفر التحكم في الخادم.
ويفسر الفصل نفسه لماذا لا تكون meta refresh «الفورية» فورية على الشبكة: فهي تضيف صفر تأخير فقط بعد تحميل المستند، بينما يصل تحويل الخادم قبل جسم المستند.
اختبر نفسك: عمليات إعادة التوجيه عبر meta refresh
خمسة أسئلة سريعة عن عمل meta refresh وموضعها. اختر إجابة لكل سؤال ثم تحقق.
موارد تستحق وقتك
كتاباتي ذات الصلة
- 11 نوعًا من إعادة التوجيه وتأثيرها في SEO (Ahrefs، مع Joshua Hardwick) — سلّم التحويلات الكامل لدي، بما فيه موضع meta refresh 0 بين الخادم وJavaScript.
- مشكلات SEO في JavaScript وأفضل الممارسات (Ahrefs) — جانب العرض وسبب وقوع تحويلات JS دون meta refresh في الموثوقية.
- ما إعادة توجيه meta refresh ولماذا تعد مشكلة حرجة؟ (مركز مساعدة Ahrefs) — تأطير Site Audit لجمهور تنبيهات الزحف (ملاحظة: عبارة “doesn’t pass link juice” (ترجمة) «لا تمرر link juice» غير مدعومة بوثائق Google في أي اتجاه؛ راجع العدسة المتقدمة لسبب تجنب الادعاءين).
محاضراتي
- كيف يعمل البحث (SlideShare) — شرحي للزحف والعرض والفهرسة والترتيب، وهو خط الأنابيب الذي يجب أن تنجو منه إعادة توجيه من جانب العميل. (إخلاء مسؤولية دائم: «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا بنسبة 100%.»)
من المجال
- عمليات إعادة التوجيه وبحث Google (Google Search Central) — المصدر الأولي للتقسيم بين الفورية والمتأخرة وترتيب التفضيل.
- Google تقول إن meta refresh تعمل جيدًا لكنها غير موصى بها (Search Engine Roundtable) — نقل Barry Schwartz تغريدة Mueller «ينبغي أن تعمل فحسب» وسببيه لعدم التوصية.
- Google تحذر من أن meta refresh قد تؤدي إلى فهرسة محتوى خاطئ (Search Engine Journal) — نمط فهرسة صفحة الدفع بدل المحتوى.
- عمليات إعادة التوجيه في HTTP (MDN) — ترتيب أسبقية التنفيذ في المتصفح، وهو مختلف عن ترتيب SEO لدى Google.
- عمليات إعادة التوجيه باستخدام Meta refresh (Sitebulb) — سير عمل أداة التدقيق للعثور عليها وفرزها.
- إعادة التوجيه الداخلية (Meta Refresh) (Screaming Frog) — كيف يبلغ عنها الزاحف وبأي شدة.
- تحويل موقع GitHub Pages بحيلة HTTP هذه (Opensource.com) — مثال واقعي لـmeta refresh على استضافة ثابتة بلا وصول إلى الخادم.
سجل التغييرات
تم التحديث في 22 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 10 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 18 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.