العرض الديناميكي

الخلاصة — يكون العرض الديناميكي عندما يستخدم موقع الويب عنوانًا واحدًا، لكنه يرسل إلى الهواتف صفحة مختلفة عن التي يرسلها إلى أجهزة سطح المكتب؛ ينظر الخادم إلى نوع الجهاز ويعيد HTML مختلفًا. ينجح ذلك، لكن Google تفضّل التصميم المتجاوب، أي صفحة واحدة تعيد ترتيب نفسها وفق حجم الشاشة، لأن الخطأ في العرض الديناميكي سهل. وإذا استخدمته فعلى الخادم إرسال ترويسة Vary: User-Agent حتى لا تعطي ذاكرة التخزين النسخة الخطأ للشخص الخطأ.

ما العرض الديناميكي؟

هناك ثلاث طرق يتعامل بها الموقع مع زوار الجوال:

1. التصميم المتجاوب — صفحة واحدة ومجموعة HTML واحدة، ويعيد التخطيط ترتيب نفسه ليلائم الشاشة. وهذا ما توصي به Google.
2. العرض الديناميكي — عنوان ويب واحد، لكن الخادم يرسل HTML مختلفًا إلى الهواتف وأجهزة سطح المكتب. العنوان نفسه والصفحة الكامنة مختلفة.
3. عناوين URL منفصلة — موقع جوال منفصل بالكامل على عنوانه، مثل m.example.com.

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

ترويسة Vary: User-Agent

هنا المشكلة: لأن الصفحة تتغير حسب الجهاز بينما لا يتغير عنوان URL، فقد يحفظ أي وسيط يخزن الصفحات مؤقتًا — المتصفح أو CDN أو مزود الإنترنت — نسخة سطح المكتب ثم يعطيها للزائر التالي الذي يستخدم هاتفًا. لمنع ذلك يجب أن يرسل الخادم مع كل استجابة ملاحظة هي Vary: User-Agent، ومعناها أن محتوى الصفحة يعتمد على الجهاز فلا يجوز إعادة استخدام نسخة مخزنة بين أجهزة مختلفة. إذا نسيت الترويسة فقد يرى الناس وGoogle النسخة الخطأ.

لماذا توصي Google بعدم استخدامه؟

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

الالتباس الشائع

لا تخلط العرض الديناميكي بـ«العرض المسبق الديناميكي». الاسمان متشابهان وكلاهما يتضمن فحص وكيل المستخدم، لكنهما يحلان مشكلتين مختلفتين. العرض الديناميكي يرسل إلى الهواتف وأجهزة سطح المكتب HTML مختلفًا. أما العرض المسبق الديناميكي فيرسل إلى برامج زحف محركات البحث نسخة مبنية مسبقًا من صفحة ثقيلة بـJavaScript. مفهوم مختلف ومستندات Google مختلفة؛ وستجد المزيد في تبويب Advanced.

في 2026، العرض الديناميكي شيء ترثه غالبًا في موقع قديم أو مؤسسي كبير، لا شيء يوصى ببنائه من الصفر. وللتفاصيل عن وظيفتي Vary وكلفة CDN التي تتجاهلها أدلة كثيرة ومسألة التمويه وكيفية اكتشاف هذا الإعداد، انتقل إلى تبويب Advanced.

الخلاصة — العرض الديناميكي = عنوان URL نفسه مع HTML/CSS مختلف حسب وكيل المستخدم، يُكتشف على الخادم ويُعلَن بترويسة الاستجابة Vary: User-Agent. وهو أحد إعدادات الجوال الثلاثة إلى جانب التصميم المتجاوب الذي توصي به Google وعناوين URL المنفصلة من نوع m-dot. تؤدي Vary وظيفتين: تمنع ذاكرات التخزين من تقديم نسخة الجهاز الخطأ، وساعدت Googlebot تاريخيًا في اكتشاف نسخة الجوال. لكنها تكلف أيضًا؛ فهي تجزّئ مفاتيح ذاكرة CDN عبر كل سلسلة UA مختلفة وتضاعف حمل المصدر. واكتشاف وكيل المستخدم عرضة للأخطاء، وقد يجعل خطأ الاكتشاف أو غياب Vary Google ترى نسخة خاطئة أو مكسورة، وهنا تنشأ مخاطرة التمويه. لا تخلطه بـالعرض المسبق الديناميكي لصفحات JS أمام الزواحف. في 2026 هو نمط قديم ينبغي تدقيقه والتخلص منه، لا بناؤه من جديد.

ما العرض الديناميكي تحديدًا؟

تعريف Google في مستند أفضل ممارسات الفهرسة المعتمدة على الجوال أولًا هو: “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (ترجمة) «العرض الديناميكي: يستخدم عنوان URL نفسه بصرف النظر عن الجهاز. يعتمد هذا الإعداد على تحسس وكيل المستخدم وترويسة استجابة HTTP ‏Vary: user-agent لتقديم نسخة مختلفة من HTML إلى الأجهزة المختلفة.» وصاغت صفحة Google المخصصة والمتقاعدة الأمر بوضوح أكبر: “a setup where the server responds with different HTML (and CSS) on the same URL depending on which user agent requests the page (mobile, tablet, or desktop).” (ترجمة) «إعداد يستجيب فيه الخادم بـHTML وCSS مختلفين على عنوان URL نفسه، تبعًا لوكيل المستخدم الذي يطلب الصفحة: جوال أو جهاز لوحي أو سطح مكتب.»

وهو أحد إعدادات الجوال الثلاثة، ويوضحه جدول من ثلاثة صفوف:

يعتمد اثنان من الإعدادات الثلاثة على Vary. وتوضح Google أن العناوين المنفصلة “like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers.” (ترجمة) «تعتمد، مثل العرض الديناميكي، على وكيل المستخدم وترويسات HTTP ‏Vary». أما التصميم المتجاوب وحده فلا يضم نسختين قد تفقدان التزامن، ولهذا توصي به Google. راجع التصميم المتجاوب وكيف تجتمع الإعدادات في محور SEO للجوال.

كيف يعمل: اكتشاف وكيل المستخدم وترويسة Vary

يفحص الخادم سلسلة وكيل المستخدم الواردة، وهي المعرّف الذي يرسله كل عميل، ويقرر إن كان الجهاز هاتفًا أو جهازًا لوحيًا أو سطح مكتب، ثم يعيد HTML المناسب. ولأن عنوان URL واحد للجميع، يجب أن يعلن الخادم أن الاستجابة تختلف حسب وكيل المستخدم. هذه هي Vary: User-Agent، وتذكر إرشادات Google المؤرشفة أنها تؤدي وظيفتين منفصلتين:

“It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps Googlebot discover your mobile-optimized content faster, as a valid Vary HTTP header is one of the signals we may use to crawl URLs that serve mobile-optimized content.” (ترجمة) «تشير إلى خوادم التخزين المؤقت لدى مزودي خدمة الإنترنت وغيرها بأن تراعي وكيل المستخدم عند تقرير تقديم الصفحة من الذاكرة المؤقتة. ومن دون ترويسة Vary HTTP قد تقدم الذاكرة لمستخدمي الجوال نسخة HTML الخاصة بسطح المكتب أو العكس. كما تساعد Googlebot على اكتشاف المحتوى المحسن للجوال أسرع، لأن ترويسة Vary HTTP الصالحة إحدى الإشارات التي قد نستخدمها لزحف عناوين URL التي تقدم محتوى محسنًا للجوال.»

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

HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710

إذا كان الخادم يرسل Vary أصلًا لشيء آخر مثل Accept-Encoding، فأضف User-Agent إلى القائمة بدل استبدالها.

ومن المهم الفصل: Vary نفسها آلية HTTP عادية للتخزين المؤقت وليست اختراعًا في SEO. فهي تخبر الذاكرة بأي ترويسات طلب تدخل في مفتاح التخزين كي تحفظ المتغير الصحيح؛ ولا تكتشف الأجهزة ولا تفهم SEO. منطق وكيل المستخدم على خادمك يفعل ذلك منفصلًا، واستخدام Google للترويسة في اكتشاف الزحف هو وصف Google لإشارة تراقبها، لا شرطًا بروتوكوليًا تتبعه كل ذاكرة بالطريقة نفسها. أرسلها باتساق لعنوان URL، بما في ذلك استجابات 304 Not Modified وأي استجابة افتراضية أو احتياطية، وإلا قد تحفظ الذاكرة بيانات وصفية غير متسقة.

الكلفة التي تتجاهلها أدلة كثيرة: تجزئة ذاكرة CDN

Vary: User-Agent ليست مجانية؛ إنها تجزّئ الذاكرة المؤقتة. يعتمد مفتاح الذاكرة جزئيًا على الترويسات المذكورة في Vary، ولذلك تعني الترويسة نسخة مخزنة منفصلة لكل سلسلة وكيل مستخدم تزور الموقع: كل إصدار متصفح وبنية نظام تشغيل وروبوت. تصبح آلاف المتغيرات لمحتوى لا يضم فعليًا إلا نسختين أو ثلاثًا. لكن مقدار فقد إعادة الاستخدام يعتمد على تعامل CDN نفسه مع مفاتيح التخزين؛ فبعضها يطبّع السلاسل أو يجمع المتشابه، ومعظمها لا يفعل. لذلك لا توجد خسارة واحدة عامة لمعدل الإصابة، وأي مُضاعف محدد، بما فيه تقدير SiteGround أدناه، تقدير مورّد لا رقم مضمون لبنيتك.

وصفت SiteGround الكلفة عمليًا: “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” (ترجمة) «مع تفعيل ترويسة User-Agent سيحتفظ النظام بنسخ مختلفة لكل تركيبة من نظام التشغيل وإصدار المتصفح التي تزور موقعك… سيكون لديك 5–30 طلبًا ديناميكيًا لكل 100 زيارة، ولذلك سيستخدم الموقع نفسه موارد أكثر 5–30 مرة.» ويؤثر ذلك في الزواحف بقوة: “If such [a] bot starts crawling your site and you have the Vary: User-Agent header, each request it makes to your site would be a dynamic one and will eat up your resources.” (ترجمة) «إذا بدأ روبوت كهذا زحف موقعك وكانت لديك ترويسة Vary: User-Agent، فسيكون كل طلب يرسله إلى موقعك ديناميكيًا وسيستهلك مواردك.»

ليست المشكلة جديدة. ففي 2013 حذرت Cindy Krum في Search Engine Land من أن شبكات CDN المؤسسية تعامل الترويسة إشارةً إلى أن المحتوى “cannot be cached or served from the CDN and must be fetched directly from your server” (ترجمة) «لا يمكن تخزينه أو تقديمه من CDN ويجب جلبه مباشرة من خادمك»، بما قد يؤدي إلى “rendering your CDN completely useless” (ترجمة) «جعل CDN عديمة الفائدة تمامًا» للصفحات المعروضة ديناميكيًا. تغير سلوك الموردين المحدد منذ 2013، لكن التوتر الأساسي، وهو تجزئة مفاتيح التخزين، ما زال حقيقيًا تقنيًا وكان سببًا مهمًا لتراجع هذا النمط. وتضيف SiteGround أن “most of the sites don’t actually serve different HTML for their mobile versions. It’s the responsive CSS that does all the heavy lifting” (ترجمة) «معظم المواقع لا تقدم HTML مختلفًا فعلًا لنسخ الجوال، بل تنجز CSS المتجاوبة العمل كله»، أي إن ترويسة Vary: User-Agent في حالات كثيرة مجرد إعداد قديم متبقٍ في موقع متجاوب.

هل يُعد العرض الديناميكي تمويهًا؟

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

“Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” (ترجمة) «توخ الحذر الشديد من التمويه عند اكتشاف وكلاء المستخدم… لا ينبغي أن يبحث المنطق عن Googlebot تحديدًا. تعرّف كل وكلاء Googlebot أنفسهم بوصفهم أجهزة جوال محددة، وينبغي معاملتهم تمامًا كما تعامل تلك الأجهزة.»

ويظهر المبدأ الموازي في مستند العرض المسبق الديناميكي: “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking,” (ترجمة) «ما دام العرض المسبق الديناميكي ينتج محتوى مشابهًا، فلن يعدّه Googlebot تمويهًا»، بينما “serving completely different content to users and crawlers can be considered cloaking.” (ترجمة) «قد يُعد تقديم محتوى مختلف تمامًا للمستخدمين والزواحف تمويهًا». وينطبق المنطق نفسه هنا: المحتوى المتشابه جوهريًا لكل جهاز مقبول، أما الإعداد الخاطئ الذي يبدو تمويهًا فهو الخطر الحقيقي.

العرض الديناميكي مقابل العرض المسبق الديناميكي

هذا أوضح موضع تخطئ فيه الصفحات المنافسة، لذلك يلزم خط فاصل صريح:

• العرض الديناميكي = اختلاف حسب الجهاز: عنوان URL نفسه وHTML مختلف للجوال وسطح المكتب. وهو موضوع هذه الصفحة، وقد دمجت Google إرشاداته في مستند الفهرسة المعتمدة على الجوال أولًا.
• العرض المسبق الديناميكي = اختلاف في عرض JavaScript للروبوتات: تقديم نسخة معروضة مسبقًا أو على الخادم من صفحة ثقيلة بـJavaScript للزواحف، بينما يحصل المستخدمون على النسخة المعروضة في العميل. له مستند Google مستقل لا يزال منشورًا، وتغطيه Bing في منشورها عن bingbot لعام 2018: “Dynamic rendering is about detecting user agent and rendering content differently for humans and search engine crawlers” (ترجمة) «العرض المسبق الديناميكي هو اكتشاف وكيل المستخدم وعرض المحتوى بصورة مختلفة للبشر وزواحف محركات البحث»؛ وهذا عن عرض JS لـbingbot، لا العرض القائم على الجهاز.

يسهل الخلط لأن الاثنين يستخدمان اكتشاف وكيل المستخدم ويثيران سؤال التمويه، لكنهما مشكلتان مختلفتان ولهما مستندات مختلفة.

اكتشاف وكيل المستخدم عرضة للأخطاء فعلًا

تذكر إرشادات Google المؤرشفة أعطالًا لا تزال قائمة: تحتاج قوائم وكلاء المستخدم إلى صيانة مستمرة ولا تطابق الوكلاء الجدد؛ ومن السهل الخطأ، “sometimes detecting a desktop user agent as a mobile one or detecting a mobile user agent as a desktop” (ترجمة) «فتكتشف أحيانًا وكيل سطح مكتب على أنه جوال أو وكيل جوال على أنه سطح مكتب»؛ والخطأ الكلاسيكي هو “a common mistake for sites is to inadvertently treat tablet devices as smartphones.” (ترجمة) «من الأخطاء الشائعة أن تعامل المواقع الأجهزة اللوحية بوصفها هواتف ذكية من غير قصد». وتلخص Google الأمر: “Use the Vary HTTP header to signal your changes depending on the user agent. Detect user agent strings correctly.” (ترجمة) «استخدم ترويسة Vary HTTP للإشارة إلى التغييرات بحسب وكيل المستخدم، واكتشف سلاسله بطريقة صحيحة». تبدو بسيطة، لكنها عبء الصيانة كله في جملتين.

تعالج Google هذه الأخطاء منذ عقد. ففي يناير 2015 أشار Pierre Far من Google إلى أبرز مشكلات التنفيذ التي رآها، والمتعلقة بمعالجة متغيرات JavaScript وCSS والصور عبر الأجهزة، لا ترويسة Vary وحدها؛ فتذكّر أن «أضف الترويسة» لم يكن القصة كاملة قط.

لماذا أصبح التصميم المتجاوب هو الافتراضي؟

جعل عاملان العرض الديناميكي نمطًا قديمًا. أولًا، توصي Google بالتصميم المتجاوب “because it’s the easiest design pattern to implement and maintain” (ترجمة) «لأنه أسهل نمط تصميم في التنفيذ والصيانة» منذ 2015 على الأقل: نسخة واحدة ولا مخاطرة اكتشاف أجهزة. ثانيًا، اكتملت الفهرسة المعتمدة على الجوال أولًا في 2023–2024، فرفعت كلفة الخطأ؛ نسخة الجوال هي التي تزحف إليها Google وتفهرسها وترتبها أساسًا. لذلك لا يقدم الخطأ صفحة جوال سيئة فحسب، بل يقدم محتواك الأساسي المفهرس على نحو خاطئ. وينطبق الدفع بعيدًا عن الإعدادات الخاصة بالأجهزة، بما فيها عناوين m-dot المنفصلة، على العرض الديناميكي أيضًا: وحّد الصفحة في عنوان متجاوب واحد فتختفي فئة المشاكل بأكملها.

وللصورة الكاملة عن تكافؤ المحتوى ومؤشرات Core Web Vitals على الجوال وقابلية الاستخدام والنوافذ البينية ووضع AMP، راجع محور SEO للجوال وقائمة تدقيق SEO للجوال.

كيف تعرف إن كان الموقع يستخدم العرض الديناميكي؟

الاختبار مباشر وسريع: اطلب عنوان URL نفسه مرتين بسلسلتي وكيل مستخدم مختلفتين وقارن. إذا اختلف HTML وحملت الاستجابة Vary: User-Agent فهذا عرض ديناميكي. وإذا تطابق HTML وأعاد ترتيب نفسه عبر CSS فهو تصميم متجاوب. يضم تبويب Scripts نسخ curl وDevTools وbookmarklet. والإشارة التي ينبغي مراقبتها هي اختلاف HTML حسب الجهاز مع غياب Vary؛ فهذا الخلل الذي يهدد بتقديم النسخة الخطأ من الذاكرة إلى المستخدمين والزواحف.

ملخص للذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

التعريف: يعيد العرض الديناميكي HTML/CSS مختلفًا من عنوان URL واحد بحسب وكيل المستخدم، ويعلن الاختلاف بترويسة Vary: User-Agent. موضعه بين إعدادات الجوال:

• التصميم المتجاوب: عنوان واحد وHTML واحد؛ وهذا ما توصي به Google.
• العرض الديناميكي: عنوان واحد وHTML مختلف حسب الجهاز.
• عناوين URL المنفصلة: عناوين وHTML منفصلة، وغالبًا على m-dot. لماذا تهم Vary: تمنع ذاكرة التخزين من تسريب نسخة جهاز إلى جهاز آخر، واستخدمتها Google تاريخيًا إشارة لاكتشاف محتوى الجوال. وهي آلية تخزين HTTP لا أداة اكتشاف؛ يجب أن يختار الخادم النسخة الصحيحة أولًا. المخاطر الأساسية: اكتشاف وكيل المستخدم قديم أو خاطئ، وانحراف المحتوى والبيانات المنظمة والروابط بين نسختي سطح المكتب والجوال، وغياب الترويسة، وتجَزُّؤ ذاكرة CDN إلى نسخ كثيرة، ومعاملة Googlebot معاملة خاصة بما يخلق مخاطرة التمويه. الكلفة الخفية: قد ينشئ Vary: User-Agent مفتاحًا منفصلًا لكل سلسلة متصفح أو نظام أو روبوت. تعتمد الخسارة الفعلية على CDN، ولذلك فإن تقدير SiteGround البالغ 5–30 ضعفًا لطلبات المصدر تقدير مورّد لا قاعدة عامة. الفرق عن العرض المسبق الديناميكي: العرض الديناميكي يختلف حسب جهاز المستخدم؛ أما العرض المسبق الديناميكي فيقدم نسخة JS معروضة مسبقًا للزواحف. الاسمان لا يصفان التقنية نفسها. توصية 2026: لا تبدأ مشروعًا جديدًا بهذا النمط. استخدم التصميم المتجاوب، ودقّق العرض الديناميكي الموروث، واختبر تكافؤ الجوال، وصحة Vary، وعزل ذاكرة CDN بالطلبات المتكررة. توصي Google بالتصميم المتجاوب منذ نحو 2015، وقد اكتملت الفهرسة المعتمدة على الجوال أولًا في 2023–2024، ما رفع كلفة أي خلل في العرض الديناميكي.

الوثائق الرسمية

وثائق أولية من محركات البحث.

Google

• أفضل ممارسات الفهرسة المعتمدة على الجوال أولًا — حيث توجد الآن تعريفات العرض الديناميكي وعناوين URL المنفصلة، بعد دمج الصفحة المخصصة في هذا المستند، وحيث تذكر Google توصيتها بالتصميم المتجاوب.
• العرض الديناميكي (المستند الأصلي المخصص — مؤرشف) — الصفحة المتقاعدة والأكثر تفصيلًا، وآخر تحديث لها في يناير 2021. وهي مصدر شرح «وظيفتي ترويسة Vary» وأعطال اكتشاف وكيل المستخدم. يعيد عنوان URL الحي الآن التوجيه بحالة 301 إلى دليل الفهرسة المعتمدة على الجوال أولًا، الذي أسقط معظم هذه التفاصيل.
• العرض المسبق الديناميكي بوصفه حلًا مؤقتًا — مفهوم عرض JavaScript المرتبط لكنه مختلف، ويتضمن توضيح أن المحتوى المتشابه لا يُعد تمويهًا. يرد هنا فقط لبيان الفرق.
• إعلان الفهرسة المعتمدة على الجوال أولًا للويب كله (مارس 2020) — سياق يوضح لماذا أصبح العرض حسب الجهاز أهم اليوم.

Bing / Microsoft

• سلسلة bingbot: JavaScript والعرض المسبق الديناميكي والتمويه (أكتوبر 2018) — إرشادات Bing عن العرض المسبق الديناميكي، أي JavaScript للروبوتات، لا العرض الديناميكي حسب الجهاز. ولا يبدو أن Bing ينشر مستندًا مخصصًا للعرض حسب الجهاز أو Vary مثل مستند Google التاريخي؛ وهو يفضل عمومًا الإعدادات المتجاوبة ذات عنوان URL الواحد.

اقتباسات من المصدر

تصريحات موثقة من Google ومن أطراف في المجال. تقود روابط مستندات Google الحية مباشرة إلى المقاطع المقتبسة، مع تمييز المصادر المؤرشفة والمنقولة.

Google — التعريف والتوصية (مستند حي)

• “Dynamic serving: Uses the same URL regardless of device. This configuration relies on user-agent sniffing and the Vary: user-agent HTTP response header to serve a different version of the HTML to different devices.” (ترجمة) «العرض الديناميكي: يستخدم عنوان URL نفسه بصرف النظر عن الجهاز. ويعتمد هذا الإعداد على تحسس وكيل المستخدم وترويسة استجابة HTTP ‏Vary: user-agent لتقديم نسخة مختلفة من HTML إلى الأجهزة المختلفة.» — مستندات Google Search Central. انتقل إلى الاقتباس
• “Separate URLs: Serves different HTML to each device, and on separate URLs. Like dynamic serving, this configuration relies on the user-agent and Vary HTTP headers to redirect users to the device-appropriate version of the site.” (ترجمة) «عناوين URL منفصلة: تقدم HTML مختلفًا لكل جهاز وعلى عناوين منفصلة. وتعتمد، مثل العرض الديناميكي، على وكيل المستخدم وترويسات HTTP ‏Vary لإعادة توجيه المستخدمين إلى نسخة الموقع المناسبة للجهاز.» انتقل إلى الاقتباس
• “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (ترجمة) «توصي Google بتصميم الويب المتجاوب لأنه أسهل نمط تصميم في التنفيذ والصيانة.» انتقل إلى الاقتباس

Google — وظيفتا ترويسة Vary (المستند المخصص المؤرشف، آخر تحديث في يناير 2021)

• “The Vary HTTP header has two important and useful implications: It signals to caching servers used in ISPs and elsewhere that they should consider the user agent when deciding whether to serve the page from cache or not. Without the Vary HTTP header, a cache may mistakenly serve mobile users the cache of the desktop HTML page or vice versa. It helps Googlebot discover your mobile-optimized content faster.” (ترجمة) «لترويسة Vary HTTP نتيجتان مهمتان ومفيدتان: فهي تنبه خوادم التخزين المؤقت لدى مزودي خدمة الإنترنت وغيرها إلى مراعاة وكيل المستخدم عند تقرير تقديم الصفحة من الذاكرة. ومن دونها قد تقدم الذاكرة لمستخدمي الجوال نسخة HTML الخاصة بسطح المكتب أو العكس. كما تساعد Googlebot على اكتشاف المحتوى المحسن للجوال بسرعة أكبر.» — Google Search Central، العرض الديناميكي (مؤرشف).
• “Be very careful of cloaking when detecting user agents… it should not be looking specifically for Googlebot. All Googlebot user agents identify themselves as specific mobile devices, and you should treat these Googlebot user agents exactly like you would treat these devices.” (ترجمة) «احذر التمويه بشدة عند اكتشاف وكلاء المستخدم… فلا ينبغي للمنطق البحث عن Googlebot تحديدًا. تعرّف جميع وكلاء Googlebot أنفسهم كأجهزة جوال معينة، وعليك معاملتهم كما تعامل تلك الأجهزة نفسها تمامًا.» — Google Search Central، العرض الديناميكي (مؤرشف).

Google — العرض المسبق الديناميكي (المفهوم المختلف) (مستند حي)

• “As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking.” (ترجمة) «ما دام العرض المسبق الديناميكي ينتج محتوى متشابهًا، فلن يعدّه Googlebot تمويهًا.» انتقل إلى الاقتباس

SiteGround — كلفة CDN لترويسة Vary: User-Agent (مصدر من المجال)

• “With the User-Agent [header] enabled, the system will keep different copies for each combination of OS and browser version visiting your site… you will have 5-30 dynamic requests for the same 100 visits. So the very same site will use 5-30 times the resources.” (ترجمة) «عند تفعيل ترويسة User-Agent يحتفظ النظام بنسخ مختلفة لكل تركيبة من نظام التشغيل وإصدار المتصفح التي تزور الموقع… ويصبح لكل 100 زيارة ما بين 5 و30 طلبًا ديناميكيًا، فيستهلك الموقع نفسه موارد أكثر بما بين 5 و30 مرة.» — SiteGround، «كيف يمكن أن تكون ترويسة Vary HTTP سيئة»

أي إعداد للجوال ينبغي أن أستخدم؟

ابدأ بالسؤال إن كنت تبني موقعًا جديدًا أم تدقق موقعًا قائمًا. في البناء الجديد يكون التصميم المتجاوب هو الاختيار. وفي الموقع القائم قارن HTML للعنوان نفسه عبر وكيل سطح مكتب ووكيل جوال، ثم اتبع الشجرة.

الخلاصة: التصميم المتجاوب هو الجواب في كل الحالات تقريبًا. العرض الديناميكي وm-dot نمطان تقلل الاعتماد عليهما في المواقع التي ورثتهما، لا خياران تبدأ بهما.

قائمة تدقيق العرض الديناميكي

• اطلب عنوان URL نفسه بوكلاء مستخدم ممثلين لسطح المكتب والجوال، وتأكد هل يختلف HTML عمدًا.
• أرسل Vary: User-Agent مع كل استجابة يتغير تمثيلها حسب فئة الجهاز، بما في ذلك الاستجابات المخزنة واستجابات الخطأ حيث ينطبق.
• حافظ على تكافؤ النص الأساسي والعناوين والروابط الداخلية والصور ونصوصها البديلة والبيانات الوصفية وتوجيهات الروبوت والبيانات المنظمة بين النسخ.
• اختبر أن Googlebot للهاتف الذكي يحصل على تمثيل الجوال نفسه الذي يحصل عليه متصفح هاتف عادي؛ ولا تعامل الزاحف معاملة خاصة.
• افحص مفاتيح ذاكرة CDN وسلوك الإصابة حتى لا تحصل فئة جهاز على مستند فئة أخرى المخزن.
• كرر كل طلب مرات عدة عبر CDN أو حافة التخزين، لا من المصدر مرة واحدة فقط، مستخدمًا وكلاء سطح المكتب والجوال والجهاز اللوحي والروبوت؛ فعطل تسميم الذاكرة لا يظهر إلا بعد تهيئة المتغير وإعادة طلبه.
• ضمّن الأجهزة اللوحية والوكلاء غير المألوفين والطلبات بلا ترويسة وكيل مستخدم في مصفوفة الاختبار الاحتياطية.
• أزل Vary: User-Agent عندما يصبح الموقع متجاوبًا فعلًا ولا تعود الاستجابة تتغير.
• احتفظ بمسار موثق للانتقال إلى التصميم المتجاوب عندما يكون العرض الديناميكي إرثًا لا ضرورة.

ورقة مرجعية للعرض الديناميكي

التعريف: عنوان URL نفسه وHTML/CSS مختلف حسب وكيل المستخدم، ويُعلن بترويسة Vary: User-Agent.

إعدادات الجوال الثلاثة

وظيفتا ترويسة Vary: User-Agent

1. صحة التخزين المؤقت — تمنع المتصفحات وشبكات CDN ومزودي الإنترنت من تقديم نسخة الجهاز الخطأ.
2. اكتشاف الزحف — ساعدت Googlebot تاريخيًا في العثور على نسخة الجوال.

شكلها

HTTP/1.1 200 OK
Vary: User-Agent

الكلفة الخفية

• تجزّئ Vary: User-Agent مفاتيح ذاكرة CDN عبر كل سلسلة UA، أي كل متصفح ونظام وروبوت.
• تقدير SiteGround: 5–30 ضعفًا لطلبات المصدر للزيارات نفسها.
• إذا كان HTML متطابقًا بين الأجهزة فالترويسة إعداد قديم متبقٍ؛ أزلها.

قاعدة التمويه

• تقديم محتوى مناسب للجهاز مقبول.
• الخطر الحقيقي هو أن يقدم خطأ الاكتشاف أو غياب Vary نسخة خاطئة إلى Googlebot.
• لا تعامل Googlebot معاملة خاصة؛ عامل جهازه المعلن مثل أي جهاز.

أخطاء الاكتشاف الشائعة

• قوائم سلاسل وكيل مستخدم قديمة لا تعرف الأجهزة الجديدة.
• فهم سطح المكتب على أنه جوال أو العكس.
• معاملة الأجهزة اللوحية كهواتف ذكية.

لا تخلطه بـ: العرض المسبق الديناميكي، أي عرض JS مسبقًا للروبوتات، وهو مفهوم مختلف.

واقع 2026: نمط قديم. توصي Google بالتصميم المتجاوب منذ نحو 2015، وقد اكتملت الفهرسة المعتمدة على الجوال أولًا في 2023–2024 ورفعت كلفة الخطأ. دققه وخطط للانتقال عنه؛ لا تبنِ به جديدًا.

اكتشاف العرض الديناميكي على أي عنوان URL

الاختبار الأساسي: اطلب عنوان URL نفسه بوكيل سطح مكتب ثم بوكيل جوال، وقارن HTML وافحص Vary: User-Agent. إذا اختلف HTML فهو عرض ديناميكي، أو m-dot إذا تغير العنوان. وإذا اختلفت الاستجابة بلا ترويسة Vary فهذا خلل يجب الإبلاغ عنه.

curl — مقارنة استجابتي سطح المكتب والجوال في macOS أو Linux

URL="https://example.com/"
DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

# Fetch both, hash the body — different hashes = different HTML per device
curl -sA "$DESKTOP" "$URL" | shasum
curl -sA "$MOBILE"  "$URL" | shasum

# Is the site even sending Vary: User-Agent? (headers only)
curl -sI "$URL" | grep -i '^vary:'

curl — انتحال Googlebot للهاتف الذكي والتحقق مما يحصل عليه الزاحف

GBOT="Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -sA "$GBOT" "https://example.com/" | shasum
# Compare to the $MOBILE hash above — they should match. If Googlebot gets the
# desktop version, that's the misconfiguration that can look like cloaking.

Windows (PowerShell) — المقارنة نفسها

$Url = "https://example.com/"
$Desktop = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Safari/537.36"
$Mobile  = "Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0 Mobile Safari/537.36"

(Invoke-WebRequest $Url -UserAgent $Desktop).RawContentLength
(Invoke-WebRequest $Url -UserAgent $Mobile ).RawContentLength
(Invoke-WebRequest $Url -Method Head).Headers["Vary"]

Chrome DevTools — بلا طرفية

1. افتح DevTools عبر F12 أو Cmd+Opt+I، ثم افتح تبويب Network conditions من ⋮ ← More tools ← Network conditions.
2. ألغ تحديد “Use browser default” واختر UA للجوال، أو ألصق سلسلة Googlebot للهاتف الذكي، ثم أعد التحميل. قارن الصفحة، وافحص Response Headers لطلب المستند في لوحة Network بحثًا عن Vary.
3. عُد إلى UA لسطح المكتب وأعد التحميل؛ اختلاف HTML على العنوان نفسه هو العلامة.

مقتطف وحدة تحكم المتصفح — فحص Vary للصفحة الحالية

// Paste in the DevTools Console on the page you're testing
fetch(location.href, { method: "HEAD", cache: "no-store" })
  .then(r => console.log("Vary:", r.headers.get("vary") || "(none)"));

Bookmarklet — فحص Vary بنقرة

javascript:(async()=>{const r=await fetch(location.href,{method:"HEAD",cache:"no-store"});alert("Vary: "+(r.headers.get("vary")||"(none set)"));})();

ملاحظة: لا يكشف fetch ترويسات الاستجابة للطلبات عبر المصادر إلا إذا سمح الخادم بها عبر CORS، لذا يكون فحص وحدة التحكم أو bookmarklet أوثق على المصدر نفسه الذي تعرضه. وللقراءة الحاسمة استخدم curl -I أو لوحة Network في DevTools.

أدوات تدقيق الاستجابات المعتمدة على الجهاز

• curl: كرر الطلب نفسه بوكلاء سطح مكتب وجوال وGooglebot للهاتف الذكي، وقارن الترويسات والحالة وحجم جسم الاستجابة وبصمات تجزئة المحتوى.
• لوحة Network في Chrome DevTools: غيّر وكيل المستخدم يدويًا وعطّل الذاكرة المؤقتة، وافحص استجابة المستند الحقيقية بدل افتراض أن محاكاة الجهاز تغيرها.
• URL Inspection في Search Console: افحص HTML المعروض الذي تلقته Googlebot للهاتف الذكي لعينة من العناوين.
• زاحف يسمح بضبط وكيل المستخدم: شغّل زحفًا للجوال وآخر لسطح المكتب، ثم قارن العناوين والعناوين الرئيسية والعناوين الأساسية canonical والتوجيهات والبيانات المنظمة والروابط الداخلية على نطاق واسع.
• تحليلات ذاكرة CDN: قسّم مرات نجاح الجلب من الذاكرة المؤقتة وإخفاقه ومفاتيح التخزين حسب فئة الجهاز لاكتشاف التجزئة أو التسريب بين الأجهزة.

الأنماط المضادة في العرض الديناميكي

هذه الأعطال تحول النمط من «يعمل» إلى «يؤذيك فعليًا»:

1. تقديم HTML مختلف بلا ترويسة Vary: User-Agent. هذا الخطأ الأكبر. فمن دونها قد تحفظ الذاكرة نسخة سطح المكتب وتعطيها لهاتف، أو تعطي Googlebot للهاتف الذكي صفحة سطح المكتب. يتغير المحتوى ولا شيء يخبر الذاكرة أو الزاحف بذلك. إذا قدمت HTML حسب الجهاز فلا غنى عن الترويسة.

2. إضافة Vary: User-Agent إلى موقع متجاوب فعلًا. الخطأ العكسي شائع أيضًا. إذا تطابق HTML بين الأجهزة فلا تقدم الترويسة فائدة وتجزّئ ذاكرة CDN لكل سلسلة وكيل مستخدم، مع تقدير SiteGround البالغ 5–30 ضعفًا للطلبات. لا تضفها «للاحتياط»؛ استخدمها فقط عندما يختلف HTML حقًا.

3. معاملة “Googlebot” معاملة خاصة في منطق الاكتشاف. اكتشاف فئة الجهاز مقبول، أما تحسس Googlebot تحديدًا وتقديم شيء مختلف له فهو طريق إلى تمويه غير مقصود. يعرّف Googlebot نفسه بوصفه جهازًا محددًا؛ عامله مثل ذلك الجهاز بالضبط.

4. السماح بانحراف HTML سطح المكتب والجوال عن التكافؤ. نسختان تعنيان شيئين يجب إبقاؤهما متزامنين. وتحت الفهرسة المعتمدة على الجوال أولًا تكون نسخة الجوال هي المفهرسة؛ لذلك فإن المحتوى والبيانات المنظمة والصور والنصوص البديلة والروابط الموجودة على سطح المكتب وحده تصبح غائبة لأغراض الفهرسة.

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

6. التعامل مع العرض الديناميكي كخيار جديد مكافئ. ليس واحدًا من ثلاثة خيارات متساوية في 2026. توصي Google بالمتجاوب منذ نحو 2015، ورفعت الفهرسة المعتمدة على الجوال كلفة الخطأ. إذا كنت تختار جديدًا فاختر المتجاوب؛ العرض الديناميكي دين تقني قديم ينبغي تقليله.

7. الخلط بينه وبين العرض المسبق الديناميكي. استخدام مستندات العرض المسبق لـJS، أو منشور Bing عن bingbot، لإعداد عرض قائم على الجهاز يخلط مشكلتين وحلين مختلفين وينتج إرشادًا لا يناسب أيًا منهما.

أعطال العرض الديناميكي الشائعة

يحصل مستخدمو الجوال أحيانًا على صفحة سطح المكتب

العَرَض: تظهر استجابة الجوال الصحيحة في الطلب البارد، ثم يظهر HTML سطح المكتب بعد جلب الاستجابة من الذاكرة المؤقتة. السبب المرجح: تختلف الاستجابة حسب وكيل المستخدم بلا مفتاح تخزين مطابق أو Vary: User-Agent. الإصلاح: صحح ترويسة المصدر وإعداد CDN، وأزل العناصر المتأثرة من الذاكرة المؤقتة، ثم كرر الطلبات بين الأجهزة على عناصر سبق تخزينها مؤقتًا.

يرى Googlebot المخصص للهواتف الذكية محتوى أقل

العَرَض: لا يعرض URL Inspection نصًا أو روابط أو بيانات منظمة أو صورًا متاحة على سطح المكتب. السبب المرجح: انحرفت قوالب الجوال أو وجه اكتشاف الجهاز Googlebot خطأ. الإصلاح: استعد التكافؤ من مصدر المحتوى المشترك واختبر وكيل الزاحف الدقيق إلى جانب وكيل هاتف عادي.

موقع متجاوب ذو كفاءة تخزين ضعيفة

العَرَض: يتطابق HTML بين الأجهزة لكن CDN يخزن متغيرات كثيرة لوكلاء المستخدم. السبب المرجح: بقيت Vary: User-Agent قديمة بعد الانتقال إلى المتجاوب. الإصلاح: تحقق أن الاستجابة لا تتغير، وأزل الترويسة، وافرغ المتغيرات، ثم أكد توحيد الذاكرة.

التحقق من تغيير في العرض الديناميكي

اختبار اتفاق التمثيل والترويسة

الاختبار: اطلب العنوان نفسه بوكيلي سطح مكتب وجوال وسجل بصمات تجزئة جسم الاستجابة وترويسة Vary. النتيجة المتوقعة: تعلن أجسام الاستجابة المختلفة عمدًا Vary: User-Agent، ولا تحمل الأجسام المتجاوبة المتطابقة اختلافًا غير ضروري. تفسير الفشل: سلوك المصدر وإشارة التخزين غير متفقين. نافذة المراقبة: فورية. محفز التراجع: إمكان مشاركة جسمي استجابة مختلفين عنصر تخزين مؤقت واحدًا لا يميّز بينهما.

اختبار عزل الذاكرة الدافئة

الاختبار: هيئ العنوان بفئة جهاز، ثم اطلبه بالفئة الأخرى وبالترتيب المعكوس. النتيجة المتوقعة: تحصل كل فئة على تمثيلها في كل مرة. تفسير الفشل: يتجاهل مفتاح CDN اختلاف الجهاز. نافذة المراقبة: فور تغييرات CDN أو الترويسة. محفز التراجع: حصول طلب جوال على HTML سطح المكتب أو العكس.

اختبار تكافؤ محتوى الجوال

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

اختبر نفسك: العرض الديناميكي

خمسة أسئلة سريعة عن العرض الديناميكي وترويسة Vary. اختر إجابة لكل سؤال ثم تحقق.

موارد تستحق وقتك

كتاباتي ذات الصلة

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

محاضراتي

• How Search Works (SlideShare) — شرح للزحف والعرض والفهرسة والترتيب، بما في ذلك زحف Googlebot بصفته هاتفًا ذكيًا، وهو سبب خطورة أخطاء العرض حسب الجهاز تحت الفهرسة المعتمدة على الجوال أولًا. (تنبيه دائم: “This is my understanding of systems… not going to be 100% complete or accurate.” (ترجمة) «هذا فهمي للأنظمة… ولن يكون كاملًا أو دقيقًا بنسبة 100%.»)

من الصناعة

• أفضل ممارسات الفهرسة المعتمدة على الجوال أولًا (Google) — الموضع الحالي لتعريفات العرض الديناميكي والعناوين المنفصلة ولتوصية التصميم المتجاوب.
• العرض الديناميكي (مستند Google الأصلي المؤرشف) (Google عبر Wayback Machine) — الصفحة المتقاعدة الأكثر تفصيلًا عن وظيفتي Vary وأعطال اكتشاف وكيل المستخدم.
• العرض المسبق الديناميكي بوصفه حلًا مؤقتًا (Google) — مفهوم عرض JS المنفصل وتوضيح أن المحتوى المتشابه ليس تمويهًا.
• إعداد موقع الجوال وترويسة Vary HTTP (Search Engine Land، Cindy Krum، 2013) — تعارض CDN المؤسسي مع Vary. المصدر قديم لكن توتر تجزئة التخزين ما زال قائمًا.
• كيف يمكن أن تكون ترويسة Vary HTTP سيئة (SiteGround) — شرح مباشر لتجزئة Vary: User-Agent وتقدير كلفة الموارد البالغ 5–30 ضعفًا.
• أبرز ثلاث مشكلات تراها Google في مواقع الجوال ذات العرض الديناميكي (Search Engine Roundtable، 2015) — أخطاء JavaScript وCSS والصور التي أشار إليها Pierre Far، وسجل مبكر لصعوبة التنفيذ.

سجل التغييرات