مواضيع مهمة

بالصوت والصورة

24 ساعة

مشاكل وحلول

الخميس، 31 يوليو، 2014

إنشاء مواقع مخصصة للهواتف الذكية

إنشاء مواقع مخصصة للهواتف الذكية

تفاصيل التوصيات

تدعم Google المواقع المخصصة للهواتف الذكية من خلال ثلاث تهيئات:
  1. المواقع التي تستخدم تصميم الويب التفاعلي، أي المواقع التي يتم عرضها على كل الأجهزة من خلال المجموعة نفسها من عناوين URL، حيث يعرض كل عنوان URL شفرة HTML نفسها على جميع الأجهزة ويستخدم CSS فقط لتغيير طريقة عرض الصفحة على الجهاز. هذه هي التهيئة التي توصي بها Google.
  2. المواقع التي يتم عرضها ديناميكيًا على كل الأجهزة من خلال المجموعة نفسها من عناوين URL، ولكن يعرض كل عنوان URL شفرة HTML (وCSS) مختلفة بناءً على ما إذا كان وكيل المستخدم يمثل جهاز سطح مكتب أو جهاز جوّال.
  3. المواقع التي لديها عناوين URL منفصلة لكل من أجهزة الجوّال وأجهزة سطح المكتب.
في هذه الصفحة، سنطلع على كيفية تطبيق كل تهيئة من هذه التهيئات.

تصميم الويب التفاعلي

تصميم الويب سريع الاستجابة (التفاعلي) عبارة عن عملية إعداد يرسل من خلالها الخادم دائمًا شفرة HTML نفسها إلى جميع الأجهزة ويتم استخدام CSS لتعديل طريقة عرض الصفحة على الجهاز باستخدام استعلامات الوسائط. ومن المفترض أن تكتشف خوارزمياتنا تلقائيًا عملية الإعداد هذه إذا كان مسموحًا لكل وكلاء مستخدم Googlebot بالزحف إلى مواد الصفحة (CSS وجافا سكريبت والصور).
استعلام وسائط CSS الذي نوصي باستخدامه للهواتف الذكية هو ما يلي:
@media only screen and (max-width: 640px) {...}
قيمة الحد الأقصى للعرض ـ التي تبلغ 640 بكسل والموضحة أعلاه ـ ما هي إلا مثال، وليست من المتطلبات. تبحث خوارزمياتنا عن الحد الأقصى لقيم العرض التي يمكن توقعها بشكل منطقي لتشير إلى درجات الدقة لشاشات الهواتف الذكية، وسنحاول مراقبة ما تستخدمه عادة مواقع الويب للجوّال وقد يتم تحديث الخوارزميات بناءً على ذلك في المستقبل.
بالنسبة إلى كيفية تحديد استعلام الوسائط، تتيح Google كل الوسائل المختلفة التي تسمح بها المعايير لاستخدام استعلامات الوسائط في شفرتك. وكل أسلوب من أساليب التطبيق له إيجابيات وسلبيات ويمكنك استخدام الأسلوب الذي يناسب موقعك ومستخدمي هذا الموقع. كقاعدة عامة، إذا كان موقعك يعمل في متصفح حديث مثل Google Chrome أو Apple Mobile Safari، فذلك يعني أنه سيعمل مع خوارزمياتنا.
للمزيد من المساعدة حول تصميم الويب سريع الاستجابة، يمكنك البدء بالاطلاع على مشاركة المدونة التي نقدمها على مجموعة خدمات مشرفي المواقع.

أسباب أهمية التصميم التفاعلي

نوصي باستخدام تصميم الويب التفاعلي لأنه يتضمن عددًا كبيرًا من الجوانب الجيدة:
  • يسهّل استخدام عنوان URL وحيد لجزء من المحتوى على المستخدمين التفاعل مع المحتوى الذي تقدمه ومشاركته وإنشاء روابط إليه، كما يعمل استخدام عنوان URL وحيد للمحتوى على مساعدة خوارزميات Google في تعيين خصائص الفهرسة للمحتوى.
  • لن تكون هناك حاجة لإعادة توجيه المستخدمين للحصول على عرض مخصص للجهاز، مما يؤدي إلى تقليل زمن التحميل. أيضًا يجب توضيح أن عمليات إعادة التوجيه استنادًا إلى وكيل المستخدم عرضة للأخطاء ويمكن أن تترك انطباعًا سيئًا لدى المستخدم عن موقعك (راجع قسم "المخاطر التي قد تنجم عند اكتشاف وكلاء المستخدم" للحصول على تفاصيل).
  • يحفظ هذا التصميم الموارد لكل من موقعك وبرامج زحف Google. بالنسبة إلى الصفحات ذات تصميم الويب سريع الاستجابة، يجب على أي وكيل مستخدم لبرنامج Googlebot الزحف إلى صفحاتك مرة واحدة، وليس لمرات متعددة من خلال وكلاء المستخدم الآخرين، لاسترداد المحتوى. ويمكن أن يعمل هذا التحسين في فعالية الزحف على مساعدة محرك بحث Google بشكل غير مباشر في فهرسة المزيد من محتويات الموقع وتحديثها باستمرار على النحو المناسب.

شرط الزحف

احرص على عدم حظر زحف أي برنامج Googlebot إلى مواد الصفحة (CSS وجافا سكريبت والصور) باستخدام ملف robots.txt أو بطريقة أخرى. ذلك أن توفير إمكانية الدخول إلى الملفات الخارجية هذه بالكامل يساعد خوارزمياتنا في اكتشاف تهيئة تصميم الويب سريع الاستجابة لموقعك والتعامل معها بشكل مناسب.

عرض شفرة HTML مختلفة ديناميكيًا على عنوان URL نفسه

العرض الديناميكي عبارة عن إعداد يستجيب من خلاله الخادم باستخدام شفرة HTML (وCSS) مختلفة على عنوان URL نفسه بناءً على وكيل المستخدم الذي يطلب الصفحة. ونظرًا لأنه لا يتضح على الفور من خلال هذا الإعداد أن الموقع يعدل شفرة HTML لوكلاء المستخدم للجوّال (المحتوى المخصص للجوّال "مخفي")، نوصي بأن يرسل الخادم تلميحًا للمطالبة بزحف Googlebot للجوّال إلى الصفحة أيضًا، ومن ثم اكتشاف المحتوى المخصص للجوّال. ويتم تطبيق هذا التلميح باستخدام رأس Vary HTTP.

رأس Vary HTTP

نستعرض فيما يلي أهمية Vary HTTP:
  1. يشير هذا الرأس إلى خوادم التخزين المؤقت المستخدمة لدى مزودي خدمة الإنترنت وفي أي مكان آخر حيث يتعين فحص وكيل المستخدم عند تحديد ما إذا كان سيتم عرض الصفحة من ذاكرة التخزين المؤقت أم لا. وبدون رأس Vary HTTP، قد تعرض ذاكرة التخزين المؤقت عن طريق الخطأ لمستخدمي الجوّال ذاكرة التخزين المؤقت لصفحة HTML بإصدار سطح المكتب والعكس صحيح.
  2. يساعد هذا الرأس Googlebot في اكتشاف المحتوى المخصص للجوّال بشكل أسرع؛ وذلك لأن رأس Vary HTTP الصالح هو إحدى الإشارات التي قد نستخدمها للزحف إلى عناوين URL التي تعرض محتوى مخصصًا للجوّال.
يعد رأس Vary HTTP جزءًا من استجابة الخادم لأحد الطلبات، وذلك كالتالي:
GET /page-1 HTTP/1.1
Host: www.example.com(...rest of HTTP request headers...)

HTTP/1.1 200 OKContent-Type: text/htmlVary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)
وهو ما يعني أن محتويات الاستجابة ستتباين اعتمادًا على وكيل المستخدم الذي يطلب الصفحة. فإذا كان الخادم يستخدم فعلاً رأس Vary HTTP، يمكنك إضافة "وكيل مستخدم" إلى القائمة التي يتم عرض المحتوى لها بالفعل.
الرجاء التأكد من التعرف على المخاطر الشائعة التي قد تنجم عند اكتشاف وكلاء المستخدم والتي يجب عليك وضعها في الاعتبار عند إعداد العرض الديناميكي على موقعك.

عناوين URL المنفصلة للجوّال

من خلال هذه التهيئة، يكون لكل عنوان URL لسطح المكتب عنوان URL مكافئ يختلف عنه ويعرض محتوى مخصصًا للجوّال. ويتمثل الإعداد الشائع في أن الصفحات المتاحة على العنوان www.example.com، ـ والتي يتم عرضها لمستخدمي أجهزة سطح المكتب ـ لها صفحات متناظرة على العنوان m.example.com، يتم عرضها لمستخدمي أجهزة الجوّال. ولا يفضل محرك بحث Google أي تنسيق معين لعنوان URL ما دام يمكن الوصول إلى كل هذه التنسيقات عبر كل من Googlebot وGooglebot للجوّال.

التعليقات التوضيحية لعناوين URL لكل من أجهزة سطح المكتب والجوّال

لمساعدة خوارزمياتنا في التعرف على هذه التهيئة على موقعك، نوصي باستخدام التعليقات التوضيحية التالية:
  1. في صفحة إصدار سطح المكتب، أضف علامة rel="alternate"‎ لرابط خاص؛ للمساعدة في التوجيه إلى عنوان URL لإصدار الجوّال المناظر. ويساعد هذا Googlebot في اكتشاف مكان صفحات الجوّال لموقعك.
  2. في صفحة إصدار الجوّال، أضف علامة rel="canonical"‎ للرابط من أجل التوجيه إلى عنوان URL لإصدار سطح المكتب المناظر.
ونحن بدورنا ندعم طريقتين لتزويدك بهذا التعليق التوضيحي: في شفرة HTML للصفحات نفسها وفي ملفات Sitemap. على سبيل المثال، لنفترض أن عنوان URL لإصدار سطح المكتب هو http://example.com/page-1 وأن عنوان URL المناظر لإصدار الجوّال هو http://m.example.com/page-1. عندها ستكون التعليقات التوضيحية في هذا المثال كما يلي:

التعليق التوضيحي في شفرة HTML

في صفحة إصدار سطح المكتب، أضف:
<link rel="alternate" media="only screen and (max-width: 640px)"
      href="http://m.example.com/page-1" >
وفي صفحة إصدار الجوّال، يجب أن يكون التعليق التوضيحي المطلوب هو:
<link rel="canonical" href="http://www.example.com/page-1" >
إن علامة rel="canonical"‎ هذه على عنوان URL لإصدار الجوّال، والتي توجّه إلى صفحة إصدار سطح المكتب، مطلوب توفرها.

التعليق التوضيحي في ملفات Sitemap

نتيح تضمين التعليق التوضيحي باستخدام rel="alternate"‎ في صفحات إصدار سطح المكتب في ملفات Sitemap كما يلي:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:xhtml="http://www.w3.org/1999/xhtml">
<url>
<loc>http://www.example.com/page-1/</loc>
<xhtml:link
    rel="alternate"
    media="only screen and (max-width: 640px)"
    href="http://m.example.com/page-1" />
</url>
</urlset>
لا تزال هناك ضرورة لإضافة علامة rel="canonical"‎ المطلوبة على عنوان URL لإصدار الجوّال إلى شفرة HTML لصفحة إصدار الجوّال.

التعليق التوضيحي بالتفصيل

لاحظ سمات علامة الرابط في صفحة إصدار سطح المكتب:
  • تشير سمة rel="alternate"‎ إلى أن هذه العلامة تحدد عنوان URL بديلاً إلى صفحة إصدار سطح المكتب.
  • قيمة سمة الوسائط هي سلسلة استعلام عن وسائط CSS تحدد ميزات الوسائط التي ينطبق عليها عنوان URL البديل. في هذه الحالة، نستخدم استعلام وسائط يتم استخدامه عادةً لاستهداف الهواتف الذكية.
  • تحدد سمة href مكان عنوان URL البديل، وتحديدًا في صفحة على m.example.com.
يساعد التعليق التوضيحي ثنائي الاتجاه Googlebot في اكتشاف المحتوى كما يساعد خوارزمياتنا في التعرف على العلاقة بين صفحاتك بإصدار سطح المكتب وصفحاتك بإصدار الجوّال ومن ثم التعامل معها. وعندما تستخدم عناوين URL مختلفة لعرض المحتوى نفسه بتنسيقات مختلفة، يعمل التعليق التوضيحي على إبلاغ خوارزميات Google بأن عنواني URL هذين يشتملان على محتوى مطابق، وأنه يجب التعامل معهما على أنهما كيان واحد وليسا كيانين. وإذا تم التعامل معهما كل على حدة، فسيتم عرض عنواني URL بإصدار لسطح المكتب وإصدار للجوّال ضمن نتائج بحث سطح المكتب، كما قد يتراجع ترتيبهما في البحث عما كانا سيكونا عليه بطريقة أخرى.

عمليات إعادة التوجيه ورأس HTTP Vary

الرجاء ملاحظة أنه إذا كان موقعك يعيد تلقائيًا توجيه الزائرين الذين يستخدمون إصدار الجوّال ـ ويتوجهون إلى الموقع المخصص لسطح المكتب ـ ويحيلهم إلى الموقع المخصص لإصدار الجوّال، أو العكس، يرجى التأكد من تهيئة خادمك لتضمين رأس Vary HTTP على النحو الموضح في هذا القسم.
ماذا يمكنك أن تقول حيال هذا الموضوع؟
 
copyright © 2013 مواقف مضحكة دوت كوم
GooPlz Blogger Template Download. Powered byBlogger blogger templates