تصميم الويب المتجاوب
ما هو التصميم المتجاوب، ولماذا توصي Google به بدلاً من التقديم الديناميكي أو عناوين URL المنفصلة للجوال، وكيف يعمل وسم viewport الوصفي، وخرافة الترتيب.
اللغات
يقدم تصميم الويب المتجاوب نفس HTML على نفس عنوان URL لكل جهاز ويستخدم استعلامات وسائط CSS لتكييف التخطيط مع منفذ العرض. إنه تكوين الجوال الموصى به من Google - ليس لأنه يحصل على ترتيب أفضل (لا يحصل؛ لقد صرحت Google بذلك صراحة) ولكن لأنه يوجد عنوان URL واحد ومجموعة واحدة من HTML للزحف والفهرسة، مما يجعله الأسهل في التنفيذ والصيانة. يتطلب وسم viewport صحيحًا ليعمل على الإطلاق - بدونه، تزيف الهواتف منفذ عرض بعرض سطح المكتب ولا تعمل استعلامات الوسائط أبدًا. يتناقض مع التقديم الديناميكي (نفس عنوان URL، HTML مختلف عبر رأس Vary) وعناوين URL المنفصلة (m-dot). التصميم المتجاوب ليس سريعًا تلقائيًا: تكييف التخطيط ليس أداءً، لذا لا تزال Core Web Vitals بحاجة إلى اهتمام منفصل.
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 لأنه الأبسط في البناء والصيانة. يتطلب سطرًا برمجيًا صغيرًا واحدًا (وسم viewport) ليعمل، لكنه لا يمنحك تلقائيًا ترتيبًا أعلى.
ما هو التصميم المتجاوب
الموقع المتجاوب هو موقع واحد يكيّف تخطيطه مع حجم الشاشة. الصفحة نفسها وعنوان الويب نفسه، سواء فتحته على هاتف أو جهاز لوحي أو شاشة كمبيوتر مكتبي كبيرة — يُعاد ترتيب الأعمدة وتغيير أحجام الصور وطيّ القائمة، ليظهر الموقع على النحو المناسب دائمًا.
أما الطرق البديلة الأقدم فتقسم موقعك إلى قسمين: موقع منفصل للجوال على عنوان خاص به (مثل m.example.com)، أو خادم يقدّم بصمت صفحات مختلفة للهواتف وأجهزة سطح المكتب من العنوان نفسه. يتجاوز التصميم المتجاوب كل ذلك؛ فهناك نسخة واحدة من كل شيء.
لماذا يُعد الخيار الموصى به
توصي Google بالتصميم المتجاوب لسبب واضح: فهو الأسهل في البناء والصيانة. ولأن هناك صفحة واحدة فقط، فليس لديك سوى نسخة واحدة تحافظ على صحتها. ولا يمكن أن تفقد «نسخة الجوال» و«نسخة سطح المكتب» التزامن، إذ لا توجد نسختان أصلًا.
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 تقرأ الآن نسخة الجوال من صفحتك لتحديد ترتيبها (وهذا هو مفهوم فهرسة الجوال أولًا). وفي الموقع المتجاوب تكون نسختا الجوال وسطح المكتب واحدة، فلا يوجد تكافؤ بين نسختين قد يختل.
السطر الواحد الذي يجعله يعمل
التصميم المتجاوب لا يعمل بمفرده. تحتاج إلى هذا في <head> لصفحتك:
<meta name="viewport" content="width=device-width, initial-scale=1">بدونه، تتصرف الهواتف كما لو كانت شاشات سطح مكتب وتصغّر الصفحة بأكملها إلى نص دقيق يصعب قراءته — ولا يعمل التخطيط المتجاوب. فالوسم ليس اختياريًا، بل هو المفتاح الذي يفعّل التصميم المتجاوب. وتعرض المقالة المخصصة لوسم viewport التفاصيل كاملة.
الشيء الذي يخطئ فيه الناس
التصميم المتجاوب ليس تعزيزًا للترتيب. قالت Google صراحةً إنها لا تضع المواقع المتجاوبة في مرتبة أعلى من المواقع المبنية بالطرق الأخرى. الفائدة هي أنه أبسط وأصعب في الإفساد — وليس أنه يكسبك مراكز.
وكون الموقع «يبدو جيدًا على هاتفي» لا يعني أنه «متجاوب». فالتصميم المتجاوب يكيّف التخطيط فعليًا عبر CSS في صفحة واحدة، لا أن تكون الصفحة مقروءة بالمصادفة.
هل تريد النسخة الكاملة — بما فيها اقتباسات Google الدقيقة، والمقارنة مع التقديم الديناميكي وعناوين URL المنفصلة، وسبب كون وسم viewport شرطًا صارمًا، وكيف يمكن أن يظل الموقع المتجاوب بطيئًا؟ انتقل إلى تبويب المستوى المتقدم.
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الخلاصة — التصميم المتجاوب يقدم نفس 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.
التعريف، بدقة
كلمات 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 واحد.
لماذا توصي به 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-Agent | rel=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، وقائمة التحقق من تحسين محركات البحث للجوال التي تربطها معًا. هذه المقالة هي الجزء الذي يجيب على “كيف يجب أن أقدم محتوى الجوال؟”؛ بينما تغطي المقالات الأخرى الباقي.
ملخص الذكاء الاصطناعي
نظرة مختصرة على النسخة المتقدمة:
- التصميم المتجاوب = نفس HTML، نفس URL، استعلامات وسائط CSS تكيّف التخطيط مع منفذ العرض. وهو أحد تكوينات الجوال الثلاثة الموثقة من Google، إلى جانب التقديم الديناميكي وعناوين URL المنفصلة.
- توصي به Google — “the easiest design pattern to implement and maintain” (ترجمة): «أسهل نمط تصميم للتنفيذ والصيانة» — لكنه ليس ميزة ترتيب. صرحت Google (زينب آيت باحاجي) بأنها لا ترتب المواقع المتجاوبة فوق التكوينات الأخرى.
- الميزة الحقيقية تشغيلية. ملاحظة النطاق الخاصة بـ Google: قائمة التحقق الخاصة بفهرسة الجوال أولًا “only applies to dynamic serving and separate URL configurations… In case of responsive design, the content and the metadata are the same” (ترجمة): «تنطبق فقط على إعدادات التقديم الديناميكي وعناوين URL المنفصلة… أما في التصميم المتجاوب فالمحتوى والبيانات الوصفية متماثلان» — لذا فإن التكافؤ، ورؤوس
Vary، والتعليقات التوضيحية البديلة/الكنسية لا تنطبق في الغالب. - وسم منفذ العرض هو شرط مسبق صارم، وليس نصيحة: بدون
<meta name="viewport" content="width=device-width, initial-scale=1">، تفترض الهواتف منفذ عرض بعرض سطح المكتب (980 px iOS / 800 px أندرويد القديم) ولا تعمل استعلامات الوسائط أبدًا. - التباين: التقديم الديناميكي (نفس URL، HTML مختلف عبر
Vary: User-Agent) وعناوين URL المنفصلة (m-dot، تحتاجrel=alternate/canonical). كلاهما أكثر خطورة لأن النسختين يمكن أن تتباعدا. - Bing يكافئ سهولة استخدام الجوال عبر معايير قابلة للاختبار (منفذ العرض، عرض المحتوى، قابلية القراءة، تباعد أهداف النقر) بدلاً من تأييد RWD بالاسم.
- فهرسة الجوال أولاً مكتملة؛ بالنسبة لموقع متجاوب بالفعل، لا يتغير شيء، لأن المحتوى والبيانات الوصفية متطابقة بالفعل.
- المتجاوب ≠ السريع. يتحكم في التخطيط، وليس الأداء — يمكن أن يفشل موقع متجاوب في Core Web Vitals إذا لم يتم تحسين الأصول وJavaScript لكل نقطة توقف.
- نقاط التوقف هي قرار تخطيطي، وليست قائمة أجهزة. عيّنها حيث ينكسر المحتوى فعليًا واختبر النطاقات بينها، وليس فقط حفنة من أحجام الشاشات المسماة.
- المتجاوب ≠ المطابق في كل مكان. لا تضمن قاعدة الشفرة الواحدة عرضًا أو إمكانية وصول أو تقديمًا مطابقًا عبر المتصفحات والأجهزة — لا يزال اختبار الأجهزة المتعددة مهمًا.
الوثائق الرسمية
وثائق المصدر الأساسي من محركات البحث.
- أفضل ممارسات فهرسة الجوال أولاً — الوثيقة الأساسية: تعريف المتجاوب، التكوينات الثلاثة، توصية “الأسهل تنفيذًا وصيانة”، وملاحظة النطاق بأن معظم قائمة التحقق لا تنطبق على المواقع المتجاوبة. ابدأ هنا.
- التصميم المتجاوب – تسخير قوة استعلامات الوسائط (2012) — شرح Google لسبب تحولها إلى المتجاوب: متطلب وسم منفذ العرض، مشكلة منفذ العرض الافتراضي 980 px/800 px، وانضباط CSS
max-width/min-height. - تعلم التصميم المتجاوب (web.dev) — دورة مطور مملوكة لـ Google حول جانب التنفيذ (استعلامات الوسائط، الصور المتجاوبة، الوضع الداكن). عنوان URL القديم
developers.google.com/search/mobile-sites/mobile-seo/responsive-designيعيد التوجيه الآن إلى هنا. - فهم تجربة صفحة Google — حيث تندرج سهولة استخدام الجوال وCore Web Vitals كإشارات (ذات صلة بنقطة “المتجاوب ≠ السريع”).
Bing / Microsoft
- إرشادات مشرفي المواقع من Bing — الإرشادات العامة من Bing؛ يتم التعامل مع ملاءمة الجوال كمعايير قابلة للاختبار بدلاً من بنية موصى بها باسم محدد.
- الإعلان عن أداة اختبار ملاءمة الجوال من Bing (نوفمبر 2015) — المعايير الخمسة التي يتحقق منها Bing: إعداد منفذ العرض/التكبير، وعرض المحتوى، وسهولة القراءة، وتباعد أهداف النقر، والمكونات الإضافية غير المتوافقة.
اقتباسات من المصدر
تصريحات موثقة من Google وBing. ينقلك كل رابط مباشرةً إلى المقطع المقتبس في صفحة المصدر.
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 بغض النظر عن جهاز المستخدم (مثل سطح المكتب أو الجهاز اللوحي أو الجوال أو المتصفح غير المرئي)، ولكن يمكنه عرض المحتوى بشكل مختلف بناءً على حجم الشاشة.» — وثائق Google Search Central. الانتقال إلى الاقتباس
- “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” (ترجمة): «توصي 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 — التقديم الديناميكي وعناوين URL المنفصلة (للمقارنة)
- “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 إلى الأجهزة المختلفة.» (التقديم الديناميكي.) الانتقال إلى الاقتباس
- “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.” (ترجمة): «يقدّم HTML مختلفًا لكل جهاز وعلى عناوين URL منفصلة. وكما في التقديم الديناميكي، يعتمد هذا التكوين على وكيل المستخدم وترويسات HTTP Vary لإعادة توجيه المستخدمين إلى إصدار الموقع المناسب للجهاز.» (عناوين URL منفصلة.) الانتقال إلى الاقتباس
Google — لماذا يلزم وسم viewport (مدونة Search Central لعام 2012)
- “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.” (ترجمة): «افتراضيًا، تتظاهر متصفحات الهواتف الذكية بأنها متصفحات سطح مكتب عالية الدقة، وتنسق الصفحة كما لو كنت تشاهدها على شاشة سطح مكتب… عرض منفذ العرض الافتراضي لمتصفح Android الافتراضي هو 800 بكسل، و980 بكسل لنظام iOS، بغض النظر عن عدد وحدات البكسل الفعلية على الشاشة.» الانتقال إلى الاقتباس
- “In order to trigger the browser to render your page at a more readable scale, you need to use the viewport meta element.” (ترجمة): «لتشغيل المتصفح لعرض صفحتك بمقياس أكثر قابلية للقراءة، تحتاج إلى استخدام عنصر meta لمنفذ العرض.» الانتقال إلى الاقتباس
- “We faced a stark choice between creating mobile specific websites, or adapting existing sites and new launches to render well on both desktop and mobile… maintaining a single shared site preserves a canonical URL, avoiding any complicated redirects, and simplifies the sharing of web addresses.” (ترجمة): «واجهنا خيارًا صارمًا بين إنشاء مواقع ويب خاصة بالجوال، أو تكييف المواقع الحالية والإطلاقات الجديدة لتقديم عرض جيد على كل من سطح المكتب والجوال… الحفاظ على موقع واحد مشترك يحافظ على عنوان URL أساسي، ويتجنب أي عمليات إعادة توجيه معقدة، ويبسط مشاركة عناوين الويب.» الانتقال إلى الاقتباس
- “Instead of specifying
widthfor container elements, we started usingmax-widthinstead. In place ofheightwe usedmin-height, so larger fonts or multi-line text don’t break the container’s boundaries.” (ترجمة): «بدلاً من تحديدwidthلعناصر الحاوية، بدأنا في استخدامmax-widthبدلاً من ذلك. وبدلاً منheightاستخدمناmin-height، حتى لا تكسر الخطوط الأكبر أو النصوص متعددة الأسطر حدود الحاوية.» الانتقال إلى الاقتباس
Google — لا تعزيز في الترتيب (Zineb Ait Bahajji، عبر تغطية Search Engine Roundtable)
- يفيد التقرير بأن Google “not rank responsive web design sites better than sites using other configurations (separate site for mobile or dynamic serving).” (ترجمة): «لا ترتّب مواقع تصميم الويب المتجاوب أعلى من المواقع التي تستخدم إعدادات أخرى (موقعًا منفصلًا للجوال أو تقديمًا ديناميكيًا).» ويظل سبب Google المعلن لتفضيله: “it’s easier to maintain, it’s future-friendly and we see less configuration errors with RWD.” (ترجمة): «إنه أسهل في الصيانة، وملائم للمستقبل، ونرى معه أخطاء إعداد أقل في RWD.» قراءة التغطية
Google (نوفمبر 2016)، نقلًا عن عرضي التقديمي في SMX Advanced 2017
- “If you have a responsive site or a dynamic serving site where the primary content and markup is equivalent across mobile and desktop, you shouldn’t have to change anything.” (ترجمة): «إذا كان لديك موقع متجاوب أو موقع خدمة ديناميكية حيث يكون المحتوى الأساسي والترميز متكافئين عبر الجوال وسطح المكتب، فلا ينبغي أن تضطر إلى تغيير أي شيء.» عرض الشرائح
#:~:text= دقيق في هذه الجولة، لذا فهي مرتبطة بالمقال بدلاً من الارتباط العميق — تحقق من الصياغة الدقيقة مقابل الصفحة الحية قبل اعتبارها نصًا حرفيًا نهائيًا. بيان Google لعام 2016 مقتبس هنا كما تم نقله عبر عرضي التقديمي SMX Advanced 2017 (منسوب إلى مدونة Google Webmasters، نوفمبر 2016)، وليس جلبًا من عنوان URL مباشر حي من Google. ما هو تكوين الجوال الذي يجب أن أستخدمه؟
بالنسبة لكل بناء جديد تقريبًا، الإجابة هي التصميم المتجاوب — ولكن هناك أسباب مشروعة لاستمرار وجود التكوينين الآخرين. انقر من خلاله.
Choosing a mobile configuration
التصميم المتجاوب — ورقة الغش
التعريف: نفس HTML، نفس URL، استعلامات وسائط CSS تكيّف التخطيط مع منفذ العرض. نسخة واحدة من كل شيء.
الوسم المطلوب (لا شيء يعمل بدونه):
<meta name="viewport" content="width=device-width, initial-scale=1">مقارنة التكوينات
| التكوين | عنوان URL واحد؟ | نفس HTML؟ | متطلب إضافي | موقف Google |
|---|---|---|---|---|
| متجاوب | نعم | نعم | وسم منفذ العرض | موصى به |
| خدمة ديناميكية | نعم | لا (حسب وكيل المستخدم) | Vary: User-Agent | مدعوم، هش |
| عناوين URL منفصلة (m-dot) | لا | لا | rel=alternate + canonical، hreflang | الأقل توصية |
لماذا التصميم المتجاوب، في سطر واحد لكل سبب
- عنوان URL واحد، HTML واحد → تكافؤ المحتوى تلقائي.
- قائمة Google “only applies to dynamic serving and separate URL configurations.” (ترجمة): «تنطبق فقط على التقديم الديناميكي وتكوينات عناوين URL المنفصلة.»
- لا خطر من ترويسة
Vary، لا سلاسل إعادة توجيه، لا تعليقات توضيحية بديلة/قانونية. - الأسهل في التنفيذ والصيانة — السبب المعلن من Google.
ما ليس عليه
- ليس تعزيزًا للترتيب (Google: لا يضع التصميم المتجاوب فوق التكوينات الأخرى).
- ليس سريعًا تلقائيًا — التخطيط ≠ الأداء؛ لا تزال CWV تحتاج إلى عمل.
- ليس نفس “يبدو جيدًا على هاتفي” — إنه تكيف مدفوع باستعلامات الوسائط.
وضع فشل منفذ العرض: بدون وسم → يفترض الهاتف عرض 980 px (iOS) / 800 px (أندرويد قديم) لمنفذ العرض، يقلص الصفحة، ولا تعمل استعلامات الوسائط أبدًا.
Bing: يكافئ ملاءمة الجوال بمعايير قابلة للاختبار (منفذ العرض، عرض المحتوى، سهولة القراءة، تباعد أهداف النقر) — لا يؤيد “RWD” بالاسم.
الفهرسة الأولى للجوال: مكتملة؛ بالنسبة لموقع متجاوب لا تغير شيئًا — المحتوى/البيانات الوصفية متطابقة بالفعل.
قائمة فحص جودة التصميم المتجاوب
شغّل هذا للتأكد من أن الموقع متجاوب حقًا وليس مجرد “سطح مكتب مرن”:
- وسم منفذ العرض موجود وصحيح —
<meta name="viewport" content="width=device-width, initial-scale=1">في<head>لكل صفحة. - لا حظر للتكبير — تجنب
user-scalable=no/maximum-scale=1في وسم منفذ العرض (تراجع في إمكانية الوصول، وقد يشير إليه Bing). - نفس عنوان URL، نفس HTML عبر الأجهزة — لا تفرع لوكيل المستخدم، لا إعادة توجيه إلى عنوان URL منفصل للجوال.
- لا تمرير أفقي عند العروض الشائعة (360، 390، 414، 768، 1024، 1280).
- استعلامات الوسائط تعمل فعليًا — يعيد التخطيط هيكلته حقًا عند نقاط التوقف، وليس مجرد تصغير.
- أهداف النقر كبيرة بما يكفي ومتباعدة (نحو 48 px) عند نقاط التوقف الصغيرة.
- نص قابل للقراءة بدون تكبير (نحو 16 px كحد أدنى أساسي).
- صور بحجم حسب نقطة التوقف — باستخدام
srcset/<picture>، وليس صورة سطح مكتب ضخمة مصغرة في CSS. - CSS/JS غير محظور في
robots.txt— يجب أن يعرض Googlebot التخطيط المتجاوب. - اجتياز Core Web Vitals للجوال — LCP < 2,5 s، INP < 200ms، CLS < 0,1 على الجوال (المتجاوب ≠ السريع؛ تحقق بشكل منفصل).
- لا محتوى مخفي عن الجوال عبر
display:noneتريد فعليًا فهرسته. - مراجعة HTML الجوال المعروض في فحص عنوان URL في Search Console.
- فحص نقطي على متصفحات/أجهزة حقيقية، وليس فقط نافذة سطح مكتب مصغرة — قاعدة كود واحدة لا تضمن عرضًا متطابقًا في كل مكان.
الأنماط المضادة للتصميم المتجاوب
الأخطاء التي تحول “نحن متجاوبون” إلى مشكلة:
- لا توجد علامة viewport (أو علامة خاطئة). الفشل الأكثر شيوعًا — استعلامات الوسائط مكتوبة بشكل صحيح لكنها لا تعمل أبدًا لأن الهاتف يعرض في لوحة بعرض 980 px. دائمًا أول شيء يجب التحقق منه.
user-scalable=no/maximum-scale=1. حظر التكبير بالقرص هو تراجع في إمكانية الوصول ويمكن أن يتم الإبلاغ عنه بواسطة اختبار الجوال من Bing. لا تعطل التكبير “لحماية” تخطيطك.- “سطح مكتب مرن” يتنكر كتصميم متجاوب. التخطيط يتدرج بشكل متناسب لكنه لا يعيد الهيكلة أبدًا — ثلاثة أعمدة تضيق فقط بدلاً من التكديس. إنه تقنيًا يغير الحجم؛ لكنه ليس متجاوبًا حقًا.
display:noneعلى محتوى تريد فهرسته. إخفاء قسم كامل على الجوال عبر CSS “لإبقائه نظيفًا.” في فهرسة الجوال أولاً، يتم قراءة HTML الجوال — إذا أخفيته، فأنت تخاطر بعدم فهرسته. (التبويبات/الأكورديونات التي تحتفظ بالمحتوى في HTML مقبولة؛ إزالته بالكامل ليست كذلك.)- التعامل مع “التجاوب” كاستراتيجية أداء. إرسال صورة رئيسية بحجم 3 MB وترك CSS يصغرها، أو إرسال JavaScript بحجم سطح المكتب إلى الهواتف. التخطيط يتكيف؛ الحمولة لا تتكيف. هكذا تفشل المواقع المتجاوبة في Core Web Vitals.
- اللجوء إلى التقديم الديناميكي أو m-dot افتراضيًا. اختيار بنية بنسختين
عندما يكون قالب متجاوب واحد كافيًا — التسجيل لانحراف التطابق،
هشاشة ترويسة
Vary، أو صيانة التعليقات التوضيحية التي لم تكن بحاجة إليها. - افتراض أن التجاوب يكسب ترتيبًا. بناء حالة العمل على تحسين ترتيب غير موجود. قم ببيعه على البساطة وقلة الأخطاء، وهي حقيقية.
تحقق من جاهزية الصفحة للتجاوب
طرق سريعة لتأكيد الأمرين اللذين يصنعان أو يكسران التصميم المتجاوب: علامة viewport، وما إذا كان الخادم يقدم HTML مختلفًا بصمت حسب وكيل المستخدم.
1) هل علامة viewport موجودة؟ (shell)
# Fetch the page and look for the viewport meta tag
curl -s https://example.com/ | grep -io '<meta[^>]*name=["'"'"']viewport["'"'"'][^>]*>'
# Expect something like:
# <meta name="viewport" content="width=device-width, initial-scale=1">2) هل يقدم الخادم HTML مختلفًا للجوال مقابل سطح المكتب؟ (shell)
إذا كانت أحجام البايت مختلفة بشكل كبير، فقد تكون في تقديم ديناميكي — وستحتاج
إلى ترويسة Vary: User-Agent معها.
UA_MOBILE="Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125 Mobile Safari/537.36"
UA_DESKTOP="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125 Safari/537.36"
echo "Mobile bytes: $(curl -s -A "$UA_MOBILE" https://example.com/ | wc -c)"
echo "Desktop bytes: $(curl -s -A "$UA_DESKTOP" https://example.com/ | wc -c)"
# If they differ, check for the Vary header (needed for dynamic serving):
curl -sI -A "$UA_MOBILE" https://example.com/ | grep -i '^vary:'
# Expect: Vary: User-Agent (among any other Vary values)3) وحدة تحكم DevTools — تدقيق علامة viewport من صفحة محملة
الصق في وحدة تحكم المتصفح على أي صفحة:
(() => {
const vp = document.querySelector('meta[name="viewport"]');
if (!vp) return console.warn('❌ No viewport meta tag — responsive layout will not work.');
const c = vp.getAttribute('content') || '';
console.log('viewport content:', c);
console.log(/width=device-width/.test(c) ? '✅ width=device-width set' : '❌ missing width=device-width');
console.log(/user-scalable=no|maximum-scale=1(\b|,|$)/.test(c)
? '⚠️ zoom is blocked — accessibility regression' : '✅ zoom not blocked');
})();4) وحدة تحكم DevTools — الإبلاغ عن التجاوز الأفقي (قاعدة “لا شريط تمرير أفقي”)
شغّل عند عرض ضيق (شريط أدوات الجهاز مفعل) للعثور على عناصر أوسع من الشاشة:
(() => {
const w = document.documentElement.clientWidth;
const bleeding = [...document.querySelectorAll('*')]
.filter(el => el.getBoundingClientRect().right > w + 1)
.slice(0, 20);
console.log(bleeding.length ? '⚠️ Elements overflowing the viewport:' : '✅ No horizontal overflow');
bleeding.forEach(el => console.log(el.tagName.toLowerCase() + (el.className ? '.' + String(el.className).split(' ').join('.') : ''), el));
})();5) إشارة مرجعية — فحص سريع لـ viewport
احفظ كإشارة مرجعية وانقر على أي صفحة:
javascript:(()=>{const v=document.querySelector('meta[name="viewport"]');alert(v?('viewport: '+v.getAttribute('content')):'No viewport meta tag found — responsive layout will not work.');})(); اختبر نفسك: التصميم المتجاوب
خمسة أسئلة سريعة حول تصميم الويب المتجاوب. اختر إجابة لكل سؤال، ثم تحقق.
موارد تستحق وقتك
كتاباتي
- فهرسة الجوال أولاً تتحول إلى الجوال فقط — دليلي في Ahrefs؛ “استخدم التصميم المتجاوب” يتصدر قائمة النصائح العشر لبناء موقع متوافق مع الجوال، ويغطي خلفية تكافؤ المحتوى التي تجعل التجاوب الخيار الافتراضي الآمن.
- دليل المبتدئين لتحسين محركات البحث التقني — حيث يقع إعداد الجوال في الصورة الأكبر للزحف/الفهرسة/الترتيب.
- Core Web Vitals: ما هي وكيف تحسنها — الجانب المتعلق بالأداء، لأن التجاوب وحده لا يجعلك سريعًا.
محاضراتي
- فهرسة الجوال أولاً (SMX Advanced 2017) (SlideShare) — عرضي التقديمي حول إعدادات الجوال؛ يقتبس خطاب Google في نوفمبر 2016 بأن المواقع المتجاوبة وذات التقديم الديناميكي ذات المحتوى المكافئ “shouldn’t have to change anything” (ترجمة): «لا ينبغي أن تغير أي شيء» لفهرسة الجوال أولاً. (إخلاء مسؤولية دائم: هذا هو فهمي لهذه الأنظمة، وليس ضمانًا للاكتمال.)
من مصادر القطاع
- أفضل ممارسات الفهرسة المعتمدة على الجوال (Google) — الوثيقة الأساسية: تعريف التصميم المتجاوب، التكوينات الثلاثة، وملاحظة النطاق التي تفيد بأن معظم قائمة التحقق لا تنطبق على المواقع المتجاوبة.
- التصميم المتجاوب – تسخير قوة استعلامات الوسائط (Google، 2012) — لماذا اعتمدت Google نفسها التصميم المتجاوب، وأصل توصيتها بوسم viewport.
- تعلّم التصميم المتجاوب (web.dev / Google) — الدورة التدريبية المتعمقة في التنفيذ: استعلامات الوسائط، الصور المتجاوبة، تفضيلات المستخدم.
- الإعلان عن أداة اختبار ملاءمة الجوال من Bing (Microsoft Bing) — معايير Bing الخمسة لملاءمة الجوال (viewport، عرض المحتوى، قابلية القراءة، تباعد أهداف النقر، المكونات الإضافية).
- Google: التصميم المتجاوب ليس تعزيزًا لترتيب البحث (Search Engine Roundtable) — تقرير باري شوارتز عن تصريح زينب آيت باحجي بأنه “لا يوجد تعزيز للترتيب”.
- هل التصميم المتجاوب كافٍ؟ (تلميح: لا) (Search Engine Land) — الحجة المخالفة بأن التصميم المتجاوب ليس حلاً سحريًا.
- أهم 7 فوائد للتصميم المتجاوب لتحسين محركات البحث (Search Engine Journal) — المكاسب العملية لرابط واحد وتكافؤ المحتوى، موضحة بالتفصيل.
مقاطع فيديو
- Google Search Central (YouTube) — شروحات مارتن سبلت حول ملاءمة الجوال وعرض الصفحات، بالإضافة إلى سلسلة How Google Search Works، تغطي كيفية تعامل Googlebot مع التخطيطات المتجاوبة. القناة
سجل التغييرات
تم التحديث في 22 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 11 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 11 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 18 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.