اللغات

تحويلات JavaScript

دليل لتحويلات JavaScript: لماذا يكون تحويل 301 من الخادم أكثر موثوقية، وكيفية التنفيذ والكشف والتحقق.

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

لا تعالج Google تحويل JavaScript إلا بعد العرض. استخدم تحويلات الخادم 301 أو302 أو307 أو308 أولًا، ثم meta refresh، واجعل JavaScript ملاذًا أخيرًا. لخطأ SPA يمكن التحويل إلى 404 حقيقي.

الخلاصة — تحويل JavaScript تحويل من جانب العميل، مثل window.location.replace() و.href و.assign()، ولا تعالجه Google إلا بعد العرض، أي المرحلة الثالثة من الزحف ثم العرض ثم الفهرسة. يظهر 301 من الخادم وقت الزحف، بينما ينتظر تحويل JS قائمة العرض بلا مدة ثابتة منشورة، وقد يفشل العرض كليًا. ترتيب Google الموثق هو الخادم ثم meta refresh ثم JavaScript، وتقول الوثائق ألا تستخدم JS إلا عند تعذر الخيارين الآخرين. بعد تفسيره بنجاح تصبح الوجهة إشارة توحيد أساسية دائمة، وقد استخدمته Google في مدونتها عندما تعذرت البدائل، لكن ذلك لا يثبت تطابق PageRank أو نتائج الترتيب مع 301؛ فهو ملاذ أخير لا إشارة إزعاج. من الاستخدامات المشروعة المنصات المقيدة بلا إعداد خادم وصفحات خطأ SPA التي تشير إلى 404 حقيقي. نفذه بواسطة window.location.replace() داخل <head>، واحذف المصدر من خريطة الموقع، وأعد توجيه الروابط الداخلية، وتأكد من قدرة Googlebot على جلب JS. أما meta refresh فمن HTML، حيث 0 ثانية دائمة وأي تأخير مؤقت، وhistory.pushState() وreplaceState() ليسا تحويلين.

ما الذي يُعد تحويل JavaScript؟

يعتمد التنقل البرمجي على العرض والتنفيذ، لذا لا يكافئ تحويل HTTP على مستوى البروتوكول. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: JavaScript redirects المعالجة ممكنة لكنها لا تضمن توقيتًا دقيقًا أو فهرسة. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search

ينقل تحويل JavaScript المتصفح إلى عنوان URL جديد بواسطة شيفرة من جانب العميل. وهذه الطرق الشائعة وفروقها:

  • window.location.replace("url") — ينقل ويحذف عنوان URL الأصلي من سجل الجلسة. وهو الخيار المفضل؛ إذ يتجاوز زر الرجوع مصدر التحويل بدل إعادة المستخدم إليه مباشرة.
  • window.location.href = "url" — ينقل لكنه يبقي الأصل في السجل، فيعيد زر الرجوع إلى صفحة التحويل وقد ينشئ حلقة. ويتصرف document.location.href وwindow.location.assign("url") بالطريقة نفسها.
  • history.pushState() وhistory.replaceState() — ليسا تحويلين. يعيدان كتابة شريط العنوان بلا تنقل أو إشارة HTTP، فلا تعاملهما برامج الزحف كتحويل. تستخدمهما SPA لتغييرات URL داخل التطبيق، وتحتاج إلى روابط <a href> حقيقية أو تنقلات فعلية كي تكون قابلة للزحف.

الحد الفاصل المهم هو أن .replace() و.href و.assign() تطلق جميعها تنقلًا حقيقيًا للمستند، ولا يختلف بينها سوى سجل الجلسة، بينما لا ينقل pushState() وreplaceState() إطلاقًا؛ فهما يغيران حالة السجل وشريط العنوان فقط. ولا يمثل أي منها HTTP 301؛ فكلمة «تحويل» هنا اختصار للتنقل من جانب العميل لا لرمز حالة.

غالبًا ما يُجمع meta refresh ‏(<meta http-equiv="refresh" content="0;url=...">) مع تحويلات JS، لكنه توجيه HTML يُحلل قبل تشغيل JavaScript، ولذلك هو فئة مستقلة أكثر موثوقية يغطيها قسم لاحق.

كيف تعالج Google تحويل JavaScript؟

هذه هي النقطة المحورية. يعمل مسار Google على مراحل، ويلتقط تحويل JS وتحويل الخادم في مرحلتين مختلفتين:

  1. الزحف — يجلب Googlebot عنوان URL ويقرأ HTML الخام. ويظهر 301 أو302 أو307 أو308 من الخادم هنا مباشرة.
  2. قائمة العرض — تنتظر الصفحات التي تعيد 200 دورها للعرض. تقول وثائق Google إن الصفحة “may stay on this queue for a few seconds, but it can take longer than that.” (ترجمة) «قد تبقى في القائمة بضع ثوان، لكن الأمر قد يستغرق أطول». لا تنشر Google مدة خدمة ثابتة، لذا عامل الانتظار كغير متوقع بدل افتراض عدد معين من الأيام أو الأسابيع.
  3. العرض والفهرسة — يشغل Chromium بلا واجهة JavaScript. وهذه أول لحظة يوجد فيها تحويل JS من منظور Google.

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

والخطر حقيقي. تقول Google: “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 عرض كل عنوان يزحف إليه Googlebot، قد يفشل العرض لأسباب مختلفة. وهذا يعني أن Google قد لا ترى تحويل JavaScript مطلقًا إذا فشل عرض المحتوى» (Google Search Central). وقبل معالجة التحويل، أو دائمًا إذا فشل العرض، قد تبقي Google صفحة المصدر الفارغة في فهرسها.

ترتيب التفضيل الرسمي لدى Google

تعرض وثائق التحويلات تسلسلًا من الأكثر إلى الأقل موثوقية:

  1. تحويلات الخادم — 301 و308 للدائم، و302 و307 للمؤقت. هي الأفضل لكل شيء: تظهر وقت الزحف ولا لبس فيها.
  2. Meta refresh — على مستوى HTML. يُعامل زمن 0 ثانية كتحويل دائم مثل 301، وأي تأخير كتحويل مؤقت.
  3. تحويلات JavaScript — الملاذ الأخير.

تقول Google: “Only use JavaScript redirects if you can’t do server-side or meta refresh redirects.” (ترجمة) «لا تستخدم تحويلات JavaScript إلا إذا تعذر تحويل الخادم أو meta refresh». تمرر التحويلات الدائمة إشارة التوحيد إلى الوجهة، وتبقي المؤقتة الأصل في النتائج. وتجد تفاعل ذلك مع اختيار النسخة الأساسية في التوحيد الأساسي.

هل تنتقل قيمة الروابط؟

تسرد وثائق Google تنقل JavaScript بالموقع ضمن طرق التحويل الدائم، وتقول إن الوجهة تصبح إشارة التوحيد بعد تفسير Google للتحويل؛ لذلك فالقول “JS redirects don’t pass PageRank” (ترجمة) «تحويلات JS لا تمرر PageRank» خرافة خاطئة. لكن الوثائق لا تثبت تطابق النتيجة أو فوريتها أو موثوقيتها مع 301 من الخادم؛ فهي تصف الإشارة الأساسية ولا تضمن تدفق PageRank أو الترتيب أو التوقيت نفسه. الصياغة الصادقة: يمرر 301 الإشارة وقت الزحف بيقين عال، بينما يمررها JS فقط إذا نجح العرض ومتى نجح، ولا تعد Google بمطابقة النتيجة واحدًا لواحد. هذه الفجوة، لا ضياع القيمة، هي تكلفة JavaScript الحقيقية.

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

متى يكون تحويل JavaScript الأداة المناسبة؟

هناك حالات مشروعة:

  • المنصات المقيدة. لا تمنح بعض إعدادات الاستضافة المشتركة أو CDN أو CMS وصولًا إلى قواعد تحويل الخادم. يكون JS بديلًا صالحًا، وقد استخدمته Google في مدونة مشرفي المواقع لأن Gary Illyes قال: “that was the only thing we could use for 1:1 redirects, and it works on Google” (ترجمة) «كان الشيء الوحيد الذي استطعنا استخدامه لتحويلات واحد إلى واحد، وهو يعمل في Google» (OnCrawl).
  • معالجة أخطاء SPA. تؤيد Google ذلك صراحة: “Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code.” (ترجمة) «استخدم تحويل JavaScript إلى عنوان يستجيب له الخادم برمز HTTP ‏404» (Google Search Central). تستطيع SPA التي تحل مسارًا سيئًا التحويل إلى نقطة 404 حقيقية كي تعالج Google الخطأ بدل فهرسة soft 404.

أما ترحيل عناوين URL الدائمة فليس هذا أداته؛ استخدم 301. أكرر النقطة نفسها في ترحيل المواقع: تحويل JavaScript ملاذ أخير وقد لا تراه Google.

مولدات المواقع الثابتة: فخ aliases في Hugo

مفاجأة شائعة: أنشأت خاصية aliases: في frontmatter لدى Hugo تاريخيًا صفحات HTML تستخدم meta refresh، لا تحويلات 301 من الخادم، وفعلت مولدات ثابتة أخرى شيئًا مشابهًا. تتغير الإعدادات الافتراضية بين الإصدارات، لذا افحص الناتج المنشور فعليًا. إذا لم تنتج aliases: تحويلات 301، فأنت تحتاج قواعد على مستوى المنصة، مثل _redirects في Netlify أو Cloudflare Workers أو vercel.json في Vercel، ومع Hugo استخدم disableAliases: true. أغطي ذلك في SEO لـHugo.

أفضل ممارسات التنفيذ

إذا كان تحويل JavaScript خيارك الوحيد فعلًا:

  • استخدم window.location.replace() لا .href. تقول Search Engine Journal إن تحويلات JS “typically use window.location.replace() function rather than window.location.href to avoid UX redirect loops” (ترجمة) «تستخدم عادة دالة replace بدل href لتجنب حلقات التحويل في تجربة المستخدم» (SEJ).
  • ضعه في <head> لا <body>. تحلل المتصفحات HTML بالتسلسل وتشغل النصوص عند الوصول إليها؛ لذا “position JavaScript redirects in the <head> tag rather than <body> to minimize delay” (ترجمة) «ضع تحويلات JavaScript في head بدل body لتقليل التأخير» (OnCrawl).
  • حوّل إلى الوجهة النهائية بقفزة واحدة. تحويل JS إلى صفحة تحول بدورها 301 ينشئ سلسلة تهدر ميزانية الزحف وقد تظهر في GSC كـخطأ تحويل.
  • احذف المصدر من خريطة XML. يجب أن تسرد الخرائط عناوين أساسية قابلة للفهرسة لا عناوين محولة.
  • أعد توجيه الروابط الداخلية مباشرة إلى الوجهة.
  • تأكد من قدرة Googlebot على جلب JS. إذا كان النص الخارجي محجوبًا بواسطة robots.txt فلن تستطيع Google عرضه ولن ترى التحويل.

كيفية اكتشاف تحويلات JavaScript

لا تعلن عن نفسها في رأس مثل 301، لذا يجب إجراء العرض:

  • زاحف مع تفعيل عرض JS. توصي OnCrawl بالزحف مع “JavaScript rendering enabled (5-second timeout minimum)” (ترجمة) «تفعيل عرض JavaScript بمهلة لا تقل عن خمس ثوان»؛ ويستطيع Screaming Frog وAhrefs Site Audit العرض. من دونه تبدو الصفحة كـ200 عادية.
  • Chrome DevTools. يعرض تبويب Network مع Preserve log التنقل من جانب العميل، وتكشفه إضافة Redirect Path أيضًا.
  • في Search Console يظهر تحويل JS المعالج بنجاح تحت Page with redirect، وهي الحالة الطبيعية نفسها لأي مصدر غير أساسي. لكن الملصق غير مضمون في كل فحص؛ فهو يعكس ما جلبته Google وعرضته وفسرته ووحدته في لحظة العينة، وقد يظهر عنوان بحالة أخرى أو بلا حالة تحويل بعد من دون خطأ لديك.

ما الذي سأفعله فعليًا؟

الخادم أولًا دائمًا. ثم meta refresh بزمن 0 عندما تستطيع تعديل HTML لا الخادم. وJavaScript فقط عند تعذر كليهما، باستخدام window.location.replace() في <head> وخريطة نظيفة وفحص أن Googlebot يعرض التحويل. لكل شيء دائم أو عالي القيمة، تستحق موثوقية 301 الإضافية أي جهد تقريبًا.

Add an expert note

Pin an expert quote

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