تصميم الويب المتجاوب

ما هو التصميم المتجاوب، ولماذا توصي Google به بدلاً من التقديم الديناميكي أو عناوين URL المنفصلة للجوال، وكيف يعمل وسم viewport الوصفي، وخرافة الترتيب.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات

يقدم تصميم الويب المتجاوب نفس HTML على نفس عنوان URL لكل جهاز ويستخدم استعلامات وسائط CSS لتكييف التخطيط مع منفذ العرض. إنه تكوين الجوال الموصى به من Google - ليس لأنه يحصل على ترتيب أفضل (لا يحصل؛ لقد صرحت Google بذلك صراحة) ولكن لأنه يوجد عنوان URL واحد ومجموعة واحدة من HTML للزحف والفهرسة، مما يجعله الأسهل في التنفيذ والصيانة. يتطلب وسم viewport صحيحًا ليعمل على الإطلاق - بدونه، تزيف الهواتف منفذ عرض بعرض سطح المكتب ولا تعمل استعلامات الوسائط أبدًا. يتناقض مع التقديم الديناميكي (نفس عنوان URL، HTML مختلف عبر رأس Vary) وعناوين URL المنفصلة (m-dot). التصميم المتجاوب ليس سريعًا تلقائيًا: تكييف التخطيط ليس أداءً، لذا لا تزال Core Web Vitals بحاجة إلى اهتمام منفصل.

الخلاصة — التصميم المتجاوب يقدم نفس HTML على نفس URL لجميع الأجهزة ويستخدم استعلامات وسائط CSS لتكييف التخطيط مع منفذ العرض. توصي Google به — “the easiest design pattern to implement and maintain” (ترجمة): «أسهل نمط تصميم للتنفيذ والصيانة» — لكنها صراحةً لا تضعه فوق التقديم الديناميكي أو عناوين URL المنفصلة. ميزته الحقيقية تشغيلية: عنوان URL واحد، مجموعة واحدة من HTML، لذا تكافؤ المحتوى تلقائي وقائمة فهرسة الجوال أولاً من Google “only applies to dynamic serving and separate URL configurations.” (ترجمة): «تنطبق فقط على التقديم الديناميكي وتكوينات عناوين URL المنفصلة.» يتطلب وسم viewport صحيحًا ليعمل — بدونه تفترض الهواتف منفذ عرض بعرض سطح المكتب (980 px iOS / 800 px أندرويد قديم) ولا تعمل استعلامات الوسائط أبدًا. المقارنة: التقديم الديناميكي (نفس URL، HTML مختلف عبر Vary: User-Agent) وعناوين URL منفصلة (m-dot). المتجاوب يتحكم في التخطيط، وليس السرعة — يمكن أن يفشل موقع متجاوب في Core Web Vitals.

Evidence for this claim Responsive design differs from dynamic serving, which changes HTML by user agent at one URL, and separate mobile URLs, which use distinct URLs. Scope: mobile and desktop rendered web documents Confidence: high · Verified: Mobile-first indexing best practices Evidence for this claim Responsive design serves the same HTML at the same URL while CSS adapts display to screen size. Scope: Google definition of responsive web design. Confidence: high · Verified: Google Search Central: Responsive design Evidence for this claim Google recommends responsive design because it is the easiest mobile pattern to implement and maintain. Scope: Google configuration recommendation. Confidence: high · Verified: Google Search Central: Mobile configurations

التعريف، بدقة

كلمات Google نفسها: التصميم المتجاوب “serves the same HTML code on the same URL regardless of the users’ device (for example, desktop, tablet, mobile, non-visual browser), but can display the content differently based on the screen size.” (ترجمة): «يقدّم رمز HTML نفسه على عنوان URL نفسه بصرف النظر عن جهاز المستخدم (مثل سطح المكتب أو الجهاز اللوحي أو الهاتف أو المتصفح غير المرئي)، لكنه يستطيع عرض المحتوى بصورة مختلفة بحسب حجم الشاشة.» تحتوي هذه الجملة على الفكرة كاملة:

  • نفس HTML — حمولة ترميز واحدة، وليست خاصة بجهاز معين.
  • نفس الرابط — لا إعادة توجيه إلى m.example.com، ولا تفرع حسب وكيل المستخدم.
  • عرض مختلف حسب حجم الشاشة — عبر استعلامات وسائط CSS.

هذا هو الخط الذي يفصله عن التكوينين الآخرين اللذين توثقهما Google. التقديم الديناميكي “uses the same URL regardless of device… 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 إلى الأجهزة المختلفة.» روابط منفصلة “serves different HTML to each device, and on separate URLs,” (ترجمة): «يقدّم HTML مختلفًا لكل جهاز وعلى عناوين URL منفصلة»، مع إعادة توجيه المستخدمين إلى النسخة المناسبة للجهاز. التصميم المتجاوب هو الوحيد من بين الثلاثة الذي يحتوي على مصدر HTML واحد.

Evidence for this claim Responsive design differs from dynamic serving, which changes HTML by user agent at one URL, and separate mobile URLs, which use distinct URLs. Scope: mobile and desktop rendered web documents Confidence: high · Verified: Mobile-first indexing best practices

لماذا توصي به Google — البساطة، وليس ميزة ترتيب

Google مباشرة: إنها “recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (ترجمة): «توصي بتصميم الويب المتجاوب لأنه أسهل نمط تصميم في التنفيذ والصيانة.» لاحظ ما هو وما ليس هذا السبب — إنها حجة تشغيلية (قاعدة كود واحدة، أجزاء متحركة أقل)، وليست حجة ترتيب.

Evidence for this claim Google recommends responsive design because it is the easiest mobile pattern to implement and maintain. Scope: Google configuration recommendation. Confidence: high · Verified: Google Search Central: Mobile configurations

السطر الأكثر فائدة — والأكثر إهمالًا — في مستند أفضل الممارسات للجوال أولاً من Google هو ملاحظة النطاق: “The contents of this guide only apply to dynamic serving and separate URL configurations. In case of responsive design, the content and the metadata are the same on the mobile and desktop version of the pages.” (ترجمة): «تنطبق محتويات هذا الدليل فقط على إعدادات التقديم الديناميكي وعناوين URL المنفصلة. أما في التصميم المتجاوب، فالمحتوى والبيانات الوصفية متماثلان في نسختي الصفحات للجوال وسطح المكتب.» اقرأ ذلك مرة أخرى. تخبرك Google أن معظم قائمة التحقق الطويلة للجوال أولاً — مطابقة البيانات المنظمة عبر الإصدارات، مطابقة وسوم robots meta، مطابقة النص البديل، تعيين رؤوس Vary، ربط تعليقات rel=alternate/canonicalببساطة لا تنطبق عليك إذا كنت متجاوبًا، لأن هناك نسخة واحدة فقط يجب إتقانها. هذه هي أقوى حجة عملية لصالح RWD، ولا يكاد أحد يصوغها بهذه الطريقة.

الفوائد المترتبة تتدفق جميعها من “رابط واحد، HTML واحد”:

  • لا خطر محتوى مكرر أو تكافؤ بين example.com/page و m.example.com/page — لا يوجد شيء ليتباعد.
  • لا هشاشة Vary: User-Agent كما يحمل التقديم الديناميكي (ذاكرة تخزين مؤقت تتجاهل الرأس يمكن أن تقدم HTML خاطئًا لجهاز خاطئ — أو إلى Googlebot).
  • لا سلاسل إعادة توجيه أو تقسيم رصيد الروابط عبر روابط سطح المكتب والجوال.
  • لا آلية تعليقات (rel=alternate على سطح المكتب، rel=canonical على الجوال) للحفاظ عليها وارتكاب أخطاء فيها.

هذا هو بالضبط السبب، في دليلي في Ahrefs حول فهرسة الجوال أولاً، “استخدم التصميم المتجاوب” هي أول نصيحة من النصائح العشر لبناء موقع متوافق مع الجوال — فهي تزيل فئات كاملة من المشكلات قبل أن تبدأ.

هل يحسن التصميم المتجاوب الترتيب مباشرة؟ لا.

هذه هي الأسطورة التي يجب قتلها مبكرًا. قالت زينب آيت باحجي من Google بوضوح: Google لا ترتب المواقع ذات التصميم المتجاوب أفضل من المواقع التي تستخدم تكوينات أخرى (مواقع جوال منفصلة أو تقديم ديناميكي). Google لا تزال تفضل RWD — لأنه أسهل في الصيانة، وصديق للمستقبل، وترى أخطاء تكوين أقل معه — لكن “أخطاء أقل” ليس مثل “مكافأة ترتيب.” موقع تقديم ديناميكي أو m-dot منفذ جيدًا يحافظ على التكافؤ يمكن أن يرتب بشكل مماثل؛ الخطر مع تلك هو أنها تنحرف، والانحراف هو ما يضرك.

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

كيف يعمل: وسم viewport meta هو شرط أساسي، وليس رفاهية

تدرج معظم الأدلة وسم meta لـ viewport كأحد النقاط ضمن نصائح CSS العديدة. لكنه ليس مجرد نصيحة — بل هو ما يجعل التصميم المتجاوب يعمل من الأساس. منشور Google لعام 2012 في Search Central الذي يشرح لماذا تحولت Google نفسها إلى التصميم المتجاوب كان صريحًا في السبب: “By default, smartphone browsers pretend to be high-resolution desktop browsers, and lay out a page as if you were viewing it on a desktop monitor… The default viewport width for the default Android browser is 800px, and 980px for iOS, regardless of the number of actual physical pixels on the screen.” (ترجمة): «افتراضيًا، تتظاهر متصفحات الهواتف الذكية بأنها متصفحات سطح مكتب عالية الدقة، وتنسق الصفحة كما لو كنت تشاهدها على شاشة سطح مكتب… عرض viewport الافتراضي لمتصفح Android الافتراضي هو 800 px، و980 px لنظام iOS، بغض النظر عن عدد البكسلات الفيزيائية الفعلية على الشاشة.»

هذا هو نمط الفشل: بدون وسم viewport، يعرض الهاتف صفحتك على لوحة بعرض 980 px ثم يقلص كل شيء ليلائم الشاشة — نص صغير، «وضع نظرة عامة»، واستعلام الوسائط max-width: 479px الذي كتبته بعناية لا يعمل أبدًا، لأن المتصفح يعتقد أن عرضه 980 px. الحل هو سطر واحد: “In order to trigger the browser to render your page at a more readable scale, you need to use the viewport meta element: <meta name="viewport" content="width=device-width, initial-scale=1">.” (ترجمة): «لكي تجعل المتصفح يعرض الصفحة بمقياس أوضح للقراءة، يجب استخدام عنصر viewport meta المذكور في الاقتباس.» ويعني ضبط width=device-width أيضًا أن التخطيط يتحدّث عند تدوير الجهاز، وهذا ما يتيح لاستعلامات الوسائط الاستجابة للاتجاه. أما التفاصيل الأعمق — initial-scale ومشكلتا الإتاحة user-scalable/maximum-scale — فترد في المقالة المخصصة لوسم viewport meta.

كيف يعمل: استعلامات وسائط CSS

مع ضبط viewport بشكل صحيح، يتكيف التخطيط باستعلامات وسائط CSS — وهي قواعد تُطبق فقط عند عروض viewport معينة:

<style>
/* Base styles apply everywhere */
@media screen and (max-width: 479px) {
  /* Portrait smartphones: stack columns, hide the sidebar, grow tap targets */
}
@media screen and (min-width: 480px) and (max-width: 1024px) {
  /* Tablets */
}
</style>

تعامل مع قيم البكسل أعلاه على أنها توضيحية، وليست قائمة تحقق لنسخها. الممارسة الدائمة — التي تكرر في مرجع استعلامات الوسائط في MDN ودورة التصميم المتجاوب في web.dev — هي التعامل مع نقاط التوقف كقرار تخطيطي، وليس كقائمة أجهزة: عيّنها حيث ينكسر المحتوى الخاص بك فعليًا (التنقل يلتف بشكل سيئ، الأعمدة تصبح ضيقة جدًا، النص يصبح بأسطر قصيرة)، واختبر النطاقات بين نقاط التوقف أيضًا، وليس فقط حفنة من أحجام الشاشات المسماة. عروض viewport للأجهزة تتغير كل دورة منتج؛ نقاط التوقف المبنية على المحتوى لا تحتاج إلى تحديث عندما تتغير.

منشور Google لعام 2012 أشار أيضًا إلى انضباط CSS الذي يمنع التخطيط المتجاوب من الانهيار: “Instead of specifying width for container elements, we started using max-width instead. In place of height we used min-height, so larger fonts or multi-line text don’t break the container’s boundaries.” (ترجمة): «بدلاً من تحديد width لعناصر الحاويات، بدأنا باستخدام max-width بدلاً منه. وبدلاً من height استخدمنا min-height، حتى لا تكسر الخطوط الأكبر أو النص متعدد الأسطر حدود الحاوية.» مبادئهم التوجيهية الثلاثة كانت بسيطة بالمثل: يجب أن تُعرض الصفحات بشكل مقروء عند أي دقة، ويجب أن تكون مجموعة المحتوى الواحدة قابلة للعرض على أي جهاز، ويجب أن “never show a horizontal scrollbar, whatever the window size.” (ترجمة): «لا تظهر أبدًا شريط تمرير أفقي، مهما كان حجم النافذة.» التحسينات الحديثة (clamp() للنص المرن، استعلامات الحاويات، srcset/<picture> للصور المناسبة للجهاز) تقع فوق هذا الأساس — وهي ليست مطلوبة لتكون “متجاوبة حقًا”. للتعمق في التنفيذ خارج إطار SEO، فإن دورة Learn Responsive Design من web.dev الخاصة بـ Google هي المكان المناسب.

التصميم المتجاوب مقابل التقديم الديناميكي مقابل عناوين URL منفصلة

التكوينات الثلاثة التي توثقها Google، جنبًا إلى جنب:

التصميم المتجاوبالتقديم الديناميكيعناوين URL منفصلة (m-dot)
URLعنوان URL واحدعنوان URL واحدعناوين URL مختلفة (m.example.com)
HTMLنفس HTML للجميعHTML مختلف لكل جهازHTML مختلف لكل جهاز
كيف يتكيفاستعلامات وسائط CSSفحص user-agent من الخادمإعادة توجيه إلى موقع خاص بالجهاز
متطلب إضافيوسم viewport metaترويسة Vary: User-Agentrel=alternate + rel=canonical، hreflang عبر الإصدارات
خطر التكافؤمنخفض — نسخة واحدةمتوسط — سهل الانحرافمرتفع — موقعان للمزامنة
موقف Googleموصى بهمدعوممدعوم، الأقل توصية

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

زاوية Bing: معايير، وليس بنية

تتفق Bing مع النتيجة ولكنها تؤطرها بشكل مختلف. إنها لا تؤيد “تصميم الويب المتجاوب” بالاسم كما تفعل Google؛ بدلاً من ذلك، يقيّم اختبار ملاءمتها للجوال معايير قابلة للاختبار — تكوين منفذ العرض والتحكم في التكبير، وعرض محتوى الصفحة، وسهولة قراءة النص، وتباعد الروابط وأهداف النقر الأخرى، واستخدام المكونات الإضافية غير المتوافقة. توصي بنفس علامة منفذ العرض التي توصي بها Google، وقاعدة عرض المحتوى الخاصة بها هي أن “the content width should not exceed the screen width” (ترجمة): «ينبغي ألا يتجاوز عرض المحتوى عرض الشاشة» — يتم وضع علامة على التجاوز كـ “Page content does not fit device width.” (ترجمة): «محتوى الصفحة لا يلائم عرض الجهاز.» لذا من الآمن القول إن Bing وGoogle تكافئان العرض الملائم للجوال؛ فقط انسب اللغة الصريحة للتكوين الموصى به إلى Google تحديدًا.

التصميم المتجاوب وفهرسة الجوال أولاً (بعد يوليو 2024)

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

المتجاوب ≠ سريع تلقائيًا

أكبر فخ. يتحكم التصميم المتجاوب في التخطيط، وليس الأداء. يمكن لموقع متجاوب أن يرسل صورة رئيسية بحجم 3 MB لسطح المكتب تقوم الهواتف بتصغيرها فقط عبر CSS، أو يرسل JavaScript بحجم سطح المكتب إلى جهاز محمول — ويفشل في LCP أو CLS بشكل سيئ. “المتجاوب” ليس ممرًا لـ Core Web Vitals. التحسين الحقيقي يعني تقديم أصول بأحجام مناسبة لكل نقطة توقف (هذا ما تستخدمه srcset/<picture> والصور المتجاوبة)، وليس مجرد ترك CSS يصغر الأصول الكبيرة. أصلح الأداء بشكل منفصل — راجع محتوى Core Web Vitals ومواد الصور المتجاوبة لمعرفة كيفية ذلك.

الأداء ليس الافتراض الوحيد الذي لا يتحقق تلقائيًا. لا تضمن قاعدة الشفرة الواحدة عرضًا متطابقًا أو إمكانية وصول أو عرضًا موحدًا في نتائج البحث أيضًا — لا تزال المتصفحات والأجهزة تختلف بما يكفي في كيفية تعاملها مع CSS والخطوط والتخطيط المعتمد على JavaScript بحيث يظل الاختبار عبر الأجهزة والمتصفحات جزءًا من المهمة، تمامًا كما سيكون تحت أي تكوين آخر. “المتجاوب” يصف بنية، وليس نتيجة مُتحققًا منها؛ اختبره كما تختبر أي شيء آخر.

القليل من التاريخ

يستحق فقرة واحدة، لأنه يعيد تأطير “أفضل ممارسة” بأكملها. لم توصِ Google بالتصميم المتجاوب أولاً ثم تتبناه لاحقًا — بل جعلت مواقعها الخاصة متجاوبة أولاً، لأسباب هندسية، وجاءت التوصية بعد ذلك. كما يوضح منشورها لعام 2012، واجهت Google “faced a stark choice between creating mobile specific websites, or adapting existing sites… Creating two sites would allow us to better target specific hardware, but maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses.” (ترجمة): «واجهت خيارًا حاسمًا بين إنشاء مواقع مخصصة للجوال أو تكييف المواقع القائمة… وكان إنشاء موقعين سيتيح استهداف أجهزة معينة بصورة أفضل، لكن الحفاظ على موقع مشترك واحد يصون عنوان URL الأساسي، ويتجنب عمليات إعادة التوجيه المعقدة، ويبسط مشاركة عناوين الويب.» الحفاظ على عنوان URL الأساسي، وعدم تعقيد إعادة التوجيه، ومشاركة أبسط — كانت تلك هي الأسباب قبل أن يسميها أي شخص أفضل ممارسة لتحسين محركات البحث، وما زالت هي الأسباب.

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

Add an expert note

Pin an expert quote

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