تحسين محركات البحث لتطبيقات الويب التقدمية

TL;DR — التطبيق التقدمي للويب (PWA) هو موقع ويب عادي مع إضافتين ملحقتين به: manifest يسمح للأشخاص بتثبيته على شاشتهم الرئيسية، وservice worker يمكنه جعله يعمل دون اتصال. بالنسبة لجوجل، لا يزال مجرد موقع ويب — التحول إلى PWA لا يعزز ترتيبك. الشيء الوحيد الذي يمكن أن يضرك فعلاً هو إعداد service worker بشكل سيئ يعرض لجوجل صفحة قديمة مخزنة مؤقتًا بدلاً من صفحتك الحية.

ما هو PWA فعليًا

التطبيق التقدمي للويب هو موقع ويب تم تحسينه ليشعر وكأنه تطبيق أصلي. قطعتان تجعلانه PWA:

• web app manifest (manifest.json) — ملف صغير يخبر المتصفح باسم تطبيقك وأيقوناته وألوانه، بحيث يمكن للزائر النقر على “إضافة إلى الشاشة الرئيسية” والحصول على أيقونة وشاشة بدء بأسلوب التطبيق.
• service worker — جزء من JavaScript يعمل في الخلفية ويمكنه تخزين الملفات مؤقتًا بحيث يتم تحميل الموقع بسرعة في الزيارات المتكررة ويعمل حتى دون اتصال.

هذا كل شيء. في الأساس، يكون PWA دائمًا تقريبًا موقع ويب JavaScript عادي (React، Vue، Angular، وما إلى ذلك). إنه موقع عادي يرتدي زي تطبيق.

الأسطورة الكبيرة التي يجب كسرها

الشيء الأكثر شيوعًا الذي يعتقده الناس هو: “If we turn our site into a PWA, we’ll rank better.” (ترجمة) «إذا حولنا موقعنا إلى PWA، فسنحصل على ترتيب أفضل.» لقد صرحت جوجل بوضوح أن هذا غير صحيح. جون مولر من جوجل قال مباشرة: PWAs “currently don’t have any advantage in Google Search.” (ترجمة) «لا تتمتع حاليًا بأي ميزة في بحث Google.» لا يوجد “مكافأة PWA” في أنظمة الترتيب.

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

الشيء الوحيد الذي يمكن أن يضر فعلاً

الـ service worker هو الجزء الذي يجب الحذر معه. لأنه يمكن أن يقدم نسخة مخزنة مؤقتًا (محفوظة) من صفحاتك، يمكن أن يؤدي إعداد سيئ إلى عرض نسخة قديمة أو حتى فارغة “أنت غير متصل” من الصفحة لجوجل بدلاً من النسخة الحقيقية والمحدثة. هكذا يفقد PWA الزيارات بعد الإطلاق — ليس لأنه “أصبح PWA”، ولكن لأن التخزين المؤقت كان موجهًا في الاتجاه الخاطئ.

ما يجب فعله فعليًا

• تأكد من أن محتوى صفحتك الحقيقي يُحمَّل لمحركات البحث، وليس مجرد قشرة فارغة تُملأ بـ JavaScript بعد ذلك.
• اضبط الـ service worker بحيث يجلب HTML الطازج من الشبكة أولاً، ولا يلجأ إلى التخزين المؤقت إلا للسرعة في أشياء مثل الصور وأوراق الأنماط.
• حافظ على الأساسيات صحيحة: عناوين URL حقيقية وفريدة؛ عنوان جيد ووصف meta في كل صفحة؛ تجربة سريعة وموثوقة.

كونك PWA رائع لمستخدميك — قابل للتثبيت، سريع، صديق للعمل دون اتصال. فقط لا تتوقع أن يرفعك في جوجل، ولا تدع الـ service worker يغذي جوجل بالصفحة الخاطئة. تحتوي علامة التبويب المتقدمة على الآليات واستراتيجيات التخزين المؤقت والاقتباسات.

TL;DR — PWA هو manifest + service worker فوق ما هو دائمًا تقريبًا موقع JS/SPA — لذا تنطبق قواعد العرض من JavaScript/SPA SEO دون تغيير، بالإضافة إلى مخاوف خاصة بـ PWA. لا تمنح جوجل PWAs أي ميزة في الترتيب (مولر). يتحكم manifest.json في قابلية التثبيت، وليس الفهرسة، ولا يوجد دليل على أن أنظمة الترتيب تقرأه. الـ service worker هو الخطر الحقيقي: لا يقوم مُقدِّم جوجل بتشغيل service workers عند الفهرسة، لذا يمكن لاستراتيجية HTML أولاً التخزين المؤقت أن تفهرس قشرة قديمة أو غير متصلة — استخدم network-first لـ HTML، وcache-first للأصول الثابتة. HTTPS هو شرط صارم لـ service workers وبشكل منفصل إشارة ترتيب صغيرة؛ لا تربط هذه في “PWAs ترتيب أفضل.” Core Web Vitals هو التداخل الشرعي الوحيد، وهو الهندسة، وليس تسمية PWA.

PWA هو موقع ويب أولاً

الإطار الأكثر فائدة: التطبيق التقدمي للويب هو موقع ويب عادي مع شيئين مضافين فوقه. وفقًا لتعريف جوجل الخاص، PWAs “are web apps built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase.” (ترجمة) «هي تطبيقات ويب مبنية ومعززة بواجهات برمجة تطبيقات حديثة لتوفير قدرات محسنة مع الوصول إلى أي مستخدم ويب على أي جهاز بقاعدة بيانات واحدة.» الركائز الثلاث التي تسميها جوجل هي Capable وReliable وInstallable — لاحظ أن أياً من الثلاثة ليس “قابلًا للترتيب.”

من الناحية المعمارية، تكون هذه القاعدة البرمجية دائمًا تقريبًا إطار عمل جافاسكريبت يشغّل نمط تطبيق الصفحة الواحدة. وهذا يعني: كل ما يتحكم في قابلية فهرسة JS/SPA يتحكم في قابلية فهرسة PWA، دون أي تعديل. روابط <a href> حقيقية وتوجيه History-API (وليس أجزاء التجزئة) لقابلية العنونة؛ عرض من جانب الخادم أو المعالجة المسبقة لتوفر المحتوى؛ canonical وtitle وmeta لكل مسار في DOM المعروض. إذا كنت قد قرأت مواد JavaScript SEO وSPA SEO، فأنت تعرف بالفعل 90% من PWA SEO — وضع فشل غلاف التطبيق، على وجه الخصوص، هو أحد الأمور التي توثقها Google صراحةً: “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” (ترجمة) «قد تستخدم بعض مواقع جافاسكريبت نموذج غلاف التطبيق حيث لا يحتوي HTML الأولي على المحتوى الفعلي وتحتاج Google إلى تنفيذ جافاسكريبت قبل أن تتمكن من رؤية محتوى الصفحة الفعلي الذي يولده جافاسكريبت.» إن PWA التي تُصدر غلافًا فارغًا دون SSR/معالجة مسبقة ترث هذه المشكلة مباشرة.

لذا فإن النطاق الصادق لمقالة SEO خاصة بـ PWA صغير: ملف manifest، وعامل الخدمة. كل شيء آخر هو JS/SPA SEO يرتدي manifest.

الأسطورة الأساسية: “التحول إلى PWA” لا يحسّن التصنيفات

هذا هو العنوان الرئيسي. كانت Google مباشرة بشكل غير معتاد بشأنه. قال جون مولر، في جلسة ساعات عمل Search Central، إن PWAs “currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this,” (ترجمة) «لا تتمتع حاليًا بأي ميزة في بحث Google، وعلى حد علمي، لا توجد خطط لتغيير ذلك،» — وعندما سُئل عما إذا كان التحويل إلى PWA سيساعد — “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (ترجمة) «بشكل افتراضي، القول إن التحول إلى PWA سيجعل تصنيفاتك أفضل — لا أعتقد أن هذا هو الحال.»

كما استبق الحجة المضادة المعتادة، وهي أن “منافسنا تحول إلى PWA وقفزت تصنيفاته.” كانت إجابته: “So just the fact that one of your competitors has moved from one framework to another, and has seen an improvement in search, that framework change from my point of view wouldn’t be responsible for that.” (ترجمة) «لذا مجرد حقيقة أن أحد منافسيك انتقل من إطار عمل إلى آخر، وشهد تحسنًا في البحث، فإن تغيير الإطار هذا من وجهة نظري لن يكون مسؤولًا عن ذلك.» وعن السبب: “These are essentially different ways of making a website… for the most part, we see these as normal HTML pages.” (ترجمة) «هذه في الأساس طرق مختلفة لإنشاء موقع ويب… في معظم الأحيان، نعتبرها صفحات HTML عادية.»

حيث ترتبط إعادة إطلاق PWA بالفعل بارتفاعات التصنيف، فإن الأمر يعود إلى المتغيرات المربكة التي تأتي مع أي إعادة بناء كبيرة: ربط داخلي حديث، محتوى منعش وموسع، تحسينات سرعة حقيقية، وعادةً حملة تسويقية مرتبطة بإعادة الإطلاق. لا يتطلب أي من ذلك تسمية PWA. إذا أعدت بناء موقع عضوي النمو عمره 10 إلى 15 عامًا، فأنت تغير عشرات الأشياء في وقت واحد — نسب النتيجة إلى “PWA” هو خطأ ارتباط.

Manifest.json: قابلية التثبيت ≠ قابلية الفهرسة

ملف manifest.json موجود لجعل تطبيقك قابلًا للتثبيت. حقوله — name, short_name, icons, start_url, display, theme_color — تتحكم في مطالبة التثبيت، وأيقونة الشاشة الرئيسية، وشاشة البداية، وما إذا كان التطبيق يفتح بشكل مستقل أو في علامة تبويب المتصفح. هذه هي المهمة بأكملها.

لا يوجد دليل على أن أنظمة تصنيف أو فهرسة Google تقرأ manifest كإشارة. التأكيد الخارجي الأوضح هو قائمة فحص PWA الخاصة بـ Google، والتي تدرج “Is installable” (ترجمة) «قابل للتثبيت» و*“Discoverable in search”* (ترجمة) «قابل للاكتشاف في البحث» كـ فئتين منفصلتين ومستقلتين في قائمة الفحص — حيث يتم تعريف قابلية الاكتشاف على أنها أساسيات SEO عادية: “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (ترجمة) «تمكين اكتشاف محرك البحث من خلال عناوين URL فريدة وعناوين وصفية وأوصاف meta وبيانات منظمة.» قابلية التثبيت (مدفوعة بـ manifest) وقابلية الاكتشاف (SEO الكلاسيكي) تُعتبران اهتمامين متوازيين، لا يغذي أحدهما الآخر. لذا: احتفظ بـ manifest صالح لأنه ما يجعل التطبيق قابلًا للتثبيت — فقط لا تضعه تحت SEO.

عمال الخدمة: خطر تحسين محركات البحث الوحيد الحقيقي الخاص بـ PWA

إليك الحقيقة الأهم، وهي خاصة بـ PWA: خدمة العرض من Google لا تشغّل عامل الخدمة الخاص بك عندما تعرض صفحة للفهرسة. السبب، من Martin Splitt: “As we have to assume that someone clicking on your page from a SERP is a first-time visitor, running a service worker is usually not going to do much good.” (ترجمة) «نظرًا لأنه يتعين علينا افتراض أن شخصًا ينقر على صفحتك من نتائج محرك البحث هو زائر لأول مرة، فإن تشغيل عامل الخدمة عادةً لن يفيد كثيرًا.» الهدف الأساسي لعامل الخدمة هو تسريع الزيارات المتكررة من ذاكرة التخزين المؤقت — وGooglebot، بحكم التصميم، يُعامل دائمًا كزائر لأول مرة، لذلك لا يوجد شيء لتسريعه. Splitt مرة أخرى: “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (ترجمة) «نحن لا ندعم ذلك لأن المستخدمين الذين ينقرون على صفحتك من نتيجة البحث ربما لم يزوروها من قبل.» وقد أكد Mueller أن هذه سياسة مستقرة، وليست حالة مؤقتة: “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (ترجمة) «لا أتوقع أن تتغير — إن تشغيل عمال الخدمة في الخلفية بهذه الطريقة للفهرسة مكلف حسابيًا.»

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

القاعدة الأساسية لاستراتيجية التخزين المؤقت:

• مستندات HTML → الشبكة أولاً (أو إعادة التحقق من القديم أثناء إعادة التحقق مع TTL قصير). احصل على الصفحة الحية؛ استخدم ذاكرة التخزين المؤقت فقط كاحتياط دون اتصال، وتأكد من أن هذا الاحتياط ليس ما ستفهرسه عملية زحف جديدة أبدًا.
• الأصول الثابتة (JS، CSS، الصور، الخطوط) → أولوية ذاكرة التخزين المؤقت مقبولة ومرغوبة — لا تتغير لكل طلب وليست المستند القابل للفهرسة.

كيفية تدقيق ذلك: قارن ما يراه Googlebot بما يقدمه متصفح الزائر المتكرر من ذاكرة التخزين المؤقت. استخدم فحص عنوان URL في Search Console (الاختبار المباشر) لرؤية HTML المعروض الذي تحصل عليه Google فعليًا، وتحقق منه مقابل الصفحة الحية. إذا تباعدا، فإن عامل الخدمة أو إعداد SSR هو المشتبه به الأول. وراقب مهلات العرض في الإعدادات الهجينة — كما لاحظ Hamlet Batista من عصر العرض الديناميكي، “Rendering services won’t wait forever for a page to finish loading.” (ترجمة) «لن تنتظر خدمات العرض إلى الأبد حتى تنتهي الصفحة من التحميل.» (تلك المقالة المحددة تتعلق بالعرض الديناميكي، الذي تثبطه Google الآن لصالح SSR — استشهد بمبدأ المهلة، وليس بالنمط.)

HTTPS: شرط لعامل الخدمة، وبشكل منفصل إشارة ترتيب صغيرة

سترى منشورات تحسين محركات البحث لـ PWA توحي بأن “PWAs تحتاج إلى HTTPS، وHTTPS يعزز الترتيب، لذلك PWAs أكثر ملاءمة لتحسين محركات البحث.” حقيقتان صحيحتان، لكنهما مرتبطتان بشكل خاطئ.

حقيقة أولى: لا تعمل عمال الخدمة إلا في سياق آمن. وفقًا لـ MDN: “Service workers are only available in secure contexts: this means that their document is served over HTTPS, although browsers also treat http://localhost as a secure context, to facilitate local development.” (ترجمة) «عمال الخدمة متاحون فقط في السياقات الآمنة: وهذا يعني أن مستندهم يُقدَّم عبر HTTPS، على الرغم من أن المتصفحات تعامل أيضًا http://localhost كسياق آمن، لتسهيل التطوير المحلي.» هذه قاعدة منصة متصفح، وليست تكتيك SEO — بدون HTTPS، لا يوجد عامل خدمة، نقطة انتهت.

حقيقة ثانية: HTTPS هو إشارة ترتيب حقيقية في Google، لكنها ضئيلة جدًا. إعلان Google الخاص بعام 2014: “we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (ترجمة) «نبدأ في استخدام HTTPS كإشارة ترتيب. في الوقت الحالي، هي إشارة خفيفة جدًا فقط — تؤثر على أقل من 1% من الاستعلامات العالمية، وتحمل وزنًا أقل من إشارات أخرى مثل المحتوى عالي الجودة.»

النقطة: أي موقع HTTPS يحصل على نفس الإشارة الصغيرة — سواء كان PWA أم لا. لا يحصل PWA على ائتمان SEO إضافي لـ HTTPS؛ بل لا يمكنه العمل بدونه. لا تبيع HTTPS كفائدة SEO لـ PWA.

Core Web Vitals: التداخل الشرعي الوحيد

إذا كان هناك مكان حقيقي يلتقي فيه “PWA جيد” و”SEO جيد”، فهو الأداء. تبدأ إرشادات Google لـ PWA بالموثوقية — “A reliable Progressive Web App feels fast and dependable regardless of the network” (ترجمة) «تطبيق ويب تقدمي موثوق يشعر بالسرعة والاعتمادية بغض النظر عن الشبكة» — وCore Web Vitals هي عامل ترتيب مؤكد (وإن كان متواضعًا). تطبيق PWA مُصمم جيدًا يحمّل بسرعة ويبقى سريع الاستجابة سيميل إلى تحقيق نتائج جيدة في Vitals.

لكن اقرأ السببية بعناية: إنها الهندسة، وليس كونها PWA. تطبيق PWA منتفخ — حزمة JS ضخمة، ترطيب يحجب العرض، عامل خدمة مفرط الحماس — يمكن أن يسجل بسهولة نتائج Core Web Vitals أسوأ من صفحة عادية تُقدَّم من الخادم. فوز Vitals يأتي من القيام بعمل الأداء جيدًا، وهو ما يمكنك فعله مع أو بدون manifest. كونك PWA لا يضمن Vitals جيدة ولا يمنحك اختصارًا إليها.

الميزات الشبيهة بالتطبيقات هي تجربة مستخدم، وليست عوامل ترتيب

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

لا تعامل “قابل للتثبيت” كقدرة واحدة وعالمية أيضًا — فهي تختلف حسب المتصفح ونظام التشغيل، وهو سبب إضافي لعدم كونها إشارة SEO (لن يكون لدى Google سلوك متسق عبر المتصفحات لتكافئه). حدث beforeinstallprompt الذي يسمح لـ PWA بعرض واجهة التثبيت المخصصة الخاصة به هو آلية خاصة بـ Chromium فقط؛ وفقًا لدليل قابلية تثبيت PWA من MDN، فهو “not supported on iOS.” (ترجمة) «غير مدعوم على iOS.» على iOS Safari، يحدث التثبيت فقط من خلال تدفق مشاركة ← إضافة إلى الشاشة الرئيسية اليدوي (الممتد إلى Chrome وEdge وFirefox وOrion على iOS 16.4+، وكلها تستخدم محرك WebKit المطلوب من Apple على iOS وبالتالي تشارك هذا القيد)، وليس عبر مطالبة تلقائية. لا شيء من ذلك يغير صورة SEO — بل يعني فقط أن “هل PWA الخاص بي قابل للتثبيت” ليس حقيقة نعم/لا مستقلة عن المتصفح ونظام التشغيل الذي يتواجد عليه الزائر.

Twitter Lite هو دراسة الحالة التي يلجأ إليها الجميع كدليل على أن “PWA يساعد SEO” — ونتائجه الموثقة حقيقية (زيادة 65% في الصفحات لكل جلسة، زيادة 75% في التغريدات المرسلة، انخفاض 20% في معدل الارتداد) — لكن كل واحدة من هذه هي مقياس تفاعل. دراسة الحالة الخاصة بـ Google عنه لا تذكر SEO أو البحث العضوي أو الترتيبات على الإطلاق. نتيجة رائعة؛ عمود خاطئ.

واجهات متاجر PWA للتجارة الإلكترونية: إشارة قصيرة

واجهات متاجر PWA تضيف بعض التعقيدات التي تستحق الذكر، لأنها تضاعف مخاطر SPA. التوجيه من جانب العميل مع التنقل متعدد الأوجه يمكن أن يولد عناوين URL تبدو قابلة للزحف وتؤدي جميعها إلى نفس الهيكل، أو انفجارًا في عناوين URL ذات المعلمات. حالة سلة التسوق والدفع تعيش من جانب العميل ويجب ألا تمنع أبدًا محتوى المنتج القابل للفهرسة. ويجب أن تعيد كل صفحة منتج بشكل مستقل HTML حقيقي وفريد — فخ التطبيق-الهيكل هو الأكثر تكلفة تحديدًا حيث لديك أكبر عدد من الصفحات. الإصلاحات هي نفسها من SEO للتجارة الإلكترونية والتنقل متعدد الأوجه؛ طبقة PWA لا تغيرها، بل تجعل انضباط SSR/prerender أكثر أهمية.

Bing و PWAs

يستحق سطرًا: لم تنشر Bing أي إرشادات خاصة بـ PWA تتعلق بالترتيب أو الفهرسة. إرشادات مشرفي المواقع الخاصة بها محايدة تجاه PWA (قابلية الزحف العامة، خرائط المواقع، robots.txt، IndexNow)، ووثائق Microsoft الواسعة حول PWA تتعلق بالكامل بمطالبات تثبيت Edge، وPWABuilder، وتغليف متجر Microsoft — التوزيع والتثبيت، مسار منفصل عن فهرسة بحث الويب. لذا بالنسبة إلى Bing، اعتمد على إرشادات قابلية الزحف القياسية لتطبيقات JavaScript؛ لا يوجد استثناء خاص بـ PWA لتعلمه.

الخلاصة

SEO لتطبيقات الويب التقدمية (PWA) هو SEO لتطبيقات JavaScript/SPA مع إضافتين محددتين فقط: تجاهل ملف البيان (manifest) كمدخل لتحسين محركات البحث (فهو خاص بقابلية التثبيت)، وتكوين عامل الخدمة (service worker) بحيث لا يحاصر زاحف جوجل (Googlebot) أبدًا في ذاكرة تخزين مؤقتة قديمة أو غير متصلة بالإنترنت. إذا أتقنت هاتين النقطتين، فسيتم فهرسة تطبيق PWA تمامًا مثل أي موقع آخر مبني جيدًا — لا مكافأة، لا عقوبة، فقط نفس القواعد.

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

نظرة مختصرة على النسخة المتقدمة:

• تطبيق PWA هو موقع ويب أولاً. هو manifest.json (قابلية التثبيت) + عامل خدمة (غير متصل/تخزين مؤقت) مُضاف فوق موقع يكون دائمًا تقريبًا موقع JS/SPA. جميع قواعد تحسين محركات البحث لتطبيقات JavaScript/SPA تنطبق دون تغيير.
• لا توجد ميزة في الترتيب. جون مولر من Google: تطبيقات PWA “لا تمتلك حاليًا أي ميزة في بحث Google.” “التحول إلى PWA” لا يحسن الترتيب.
• manifest.json غير ذي صلة بتحسين محركات البحث. يتحكم في مطالبات التثبيت، والأيقونات، وstart_url، وdisplay — لا يوجد دليل على أن أنظمة الترتيب تقرأه. قائمة فحص PWA من Google تدرج “قابل للتثبيت” و”قابل للاكتشاف في البحث” كفئتين منفصلتين.
• الخطر الحقيقي الوحيد هو عامل الخدمة. لا يقوم مُقدِّم العرض من Google بتشغيل عمال الخدمة عند الفهرسة (يعامل كل زحف كزيارة أولى)، لذا يمكن لاستراتيجية HTML ذات الأولوية للتخزين المؤقت فهرسة قشرة قديمة أو غير متصلة بالإنترنت. استخدم الشبكة أولاً لـ HTML، والتخزين المؤقت أولاً للأصول الثابتة.
• HTTPS ≠ ميزة تحسين محركات البحث لتطبيقات PWA. إنه شرط صارم لعمال الخدمة (سياق آمن) وبشكل منفصل إشارة ترتيب “خفيفة جدًا” يحصل عليها كل موقع HTTPS. لا تربط بين الاثنين.
• Core Web Vitals هو التداخل الشرعي الوحيد — وهو هندسة الأداء، وليس تسمية PWA. يمكن لتطبيق PWA المتضخم أن يسجل أسوأ.
• الميزات الشبيهة بالتطبيقات (التثبيت، عدم الاتصال، الإشعارات) هي تفاعل، وليست ترتيبًا. المكاسب الشهيرة لتطبيق Twitter Lite هي مقاييس تفاعل؛ تلك الدراسة الحالة لا تذكر تحسين محركات البحث أبدًا. تختلف قابلية التثبيت نفسها حسب المتصفح/نظام التشغيل (لا يحتوي Safari على iOS على beforeinstallprompt، فقط إضافة يدوية إلى الشاشة الرئيسية) — سبب إضافي لعدم كونها إشارة ترتيب.
• Bing ليس لديها إرشادات خاصة بـ PWA؛ اعتمد على قابلية الزحف العادية لتطبيقات JavaScript.

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

مادة من المصادر الأولية حول تطبيقات PWA، والتقديم، والحقائق التي يستند إليها هذا المقال.

Google / web.dev

• ما هي تطبيقات الويب التقدمية؟ — تعريف Google والركائز الثلاث (قادرة، موثوقة، قابلة للتثبيت).
• ما الذي يجعل تطبيق ويب تقدميًا جيدًا؟ (قائمة فحص PWA) — يفصل “قابل للتثبيت” عن “قابل للاكتشاف في البحث” كفئتين متميزتين.
• عمال الخدمة (تعلم PWA) — استراتيجيات التخزين المؤقت ودورة حياة عامل الخدمة.
• فهم أساسيات تحسين محركات البحث لجافا سكريبت — وضع فشل غلاف التطبيق الذي يوثقه Google.
• بناء تطبيقات ويب تقدمية قابلة للفهرسة (2016) — منشور Google الأصلي حول قابلية فهرسة PWA.
• دراسة حالة Twitter Lite — مقاييس التفاعل (ملاحظة: لا توجد ادعاءات حول تحسين محركات البحث أو الزيارات العضوية في أي مكان فيه).
• HTTPS كإشارة ترتيب (2014) — عبارة “الإشارة الخفيفة جدًا”.

MDN / المنصة

• Service Worker API — متطلب السياق الآمن (HTTPS).
• Making PWAs installable — اختلافات قابلية التثبيت بين المتصفحات وأنظمة التشغيل، بما في ذلك سبب عدم دعم beforeinstallprompt على iOS.

Bing / Microsoft (لا توجد إرشادات ترتيب خاصة بـ PWA — هذه مستندات تثبيت وتوزيع)

• Bing Webmaster Guidelines — قابلية الزحف العامة؛ غير مرتبطة بـ PWA.
• Overview of Progressive Web Apps (PWAs) — التركيز على تثبيت وتوزيع Edge.

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

تصريحات مسجلة. عندما يُنقل اقتباس عبر طرف ثالث بدلاً من رابط مملوك لـ Google، يوضح التحذير ذلك.

Google — لا ميزة ترتيب لـ PWA

• “PWAs currently don’t have any advantage in Google Search, and as far as I know, there are no plans to change this.” (ترجمة) «لا تتمتع تطبيقات PWA حاليًا بأي ميزة في بحث Google، وعلى حد علمي، لا توجد خطط لتغيير ذلك.» — جون مولر، Google، ساعات عمل Search Central (نوفمبر 2021). اقرأ التغطية
• “By default, saying going to a PWA will make your rankings better — I don’t think that is the case.” (ترجمة) «بشكل افتراضي، القول إن استخدام PWA سيحسن ترتيبك — لا أعتقد أن هذا هو الحال.» — جون مولر، نفس الجلسة. اقرأ التغطية
• “So just the fact that one of your competitors has moved from one framework to another, and has seen an improvement in search, that framework change from my point of view wouldn’t be responsible for that.” (ترجمة) «لذا مجرد حقيقة أن أحد منافسيك انتقل من إطار عمل إلى آخر، وشهد تحسنًا في البحث، فإن تغيير الإطار هذا من وجهة نظري لن يكون مسؤولًا عن ذلك.» — جون مولر، نفس الجلسة. اقرأ التغطية

Google — ما هي PWA، ومخاطر غلاف التطبيق

• “Progressive Web Apps (PWA) are web apps built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase.” (ترجمة) «تطبيقات الويب التقدمية (PWA) هي تطبيقات ويب مبنية ومعززة بواجهات برمجة تطبيقات حديثة لتوفير قدرات محسنة مع الوصول إلى أي مستخدم ويب على أي جهاز باستخدام قاعدة بيانات واحدة.» — web.dev. انتقل إلى الاقتباس
• “Some JavaScript sites may use the app shell model where the initial HTML does not contain the actual content and Google needs to execute JavaScript before being able to see the actual page content that JavaScript generates.” (ترجمة) «قد تستخدم بعض مواقع JavaScript نموذج غلاف التطبيق حيث لا يحتوي HTML الأولي على المحتوى الفعلي وتحتاج Google إلى تنفيذ JavaScript قبل أن تتمكن من رؤية محتوى الصفحة الفعلي الذي يولده JavaScript.» — Google Search Central. انتقل إلى الاقتباس
• “Enable search engine discovery through unique URLs, descriptive titles, meta descriptions, and structured data.” (ترجمة) «فعّل اكتشاف محركات البحث عبر عناوين URL فريدة وعناوين وصفية وأوصاف meta وبيانات منظمة.» — قائمة فحص PWA من web.dev، “قابل للاكتشاف في البحث.” انتقل إلى الاقتباس

Google — عمال الخدمة والفهرسة (منقول)

• “As we have to assume that someone clicking on your page from a SERP is a first-time visitor, running a service worker is usually not going to do much good.” (ترجمة) «نظرًا لأننا يجب أن نفترض أن شخصًا ينقر على صفحتك من نتائج محرك البحث هو زائر لأول مرة، فإن تشغيل عامل الخدمة عادةً لن يفيد كثيرًا.» — مارتن سبلت، Google. اقرأ التغطية
• “We’re not supporting that because users clicking onto your page from the search result might never have been there beforehand.” (ترجمة) «نحن لا ندعم ذلك لأن المستخدمين الذين ينقرون على صفحتك من نتائج البحث ربما لم يزوروها من قبل.» — مارتن سبلت، Google (Google I/O 2019). اقرأ التغطية
• “I wouldn’t expect it to change — it’s computationally expensive to run service-workers in the background like this for indexing.” (ترجمة) «لا أتوقع أن يتغير — إن تشغيل عمال الخدمة في الخلفية بهذه الطريقة للفهرسة مكلف حسابيًا.» — جون مولر، Google (أُبلغ في يوليو 2023). اقرأ التغطية

HTTPS: متطلب النظام الأساسي مقابل إشارة الترتيب

• “Service workers are only available in secure contexts: this means that their document is served over HTTPS, although browsers also treat http://localhost as a secure context, to facilitate local development.” (ترجمة) «لا تتوفر Service workers إلا في السياقات الآمنة: هذا يعني أن مستندها يُقدَّم عبر HTTPS، على الرغم من أن المتصفحات تعامل أيضًا http://localhost كسياق آمن، لتسهيل التطوير المحلي.» — MDN، Service Worker API. الانتقال إلى الاقتباس
• “we’re starting to use HTTPS as a ranking signal. For now it’s only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content.” (ترجمة) «بدأنا استخدام HTTPS كإشارة ترتيب، لكنها في الوقت الراهن إشارة خفيفة جدًا — تمس أقل من 1% من الاستعلامات العالمية ووزنها أقل من إشارات مثل المحتوى عالي الجودة.» — Google، “HTTPS كإشارة ترتيب” (2014). الانتقال إلى الاقتباس

تختلف قابلية التثبيت حسب المتصفح/نظام التشغيل

• “This is not supported on iOS.” (ترجمة) «هذا غير مدعوم على iOS.» — MDN، حول حدث beforeinstallprompt الخاص بمطالبة التثبيت المخصصة. الانتقال إلى الاقتباس

حول مهلات العرض (سياق مؤرخ)

• “Rendering services won’t wait forever for a page to finish loading.” (ترجمة) «لن تنتظر خدمات العرض إلى الأبد حتى تنتهي الصفحة من التحميل.» — هاملت باتيستا، Search Engine Land. اقرأ المقال

هل يجب أن أتحول إلى PWA — وماذا سيفعل ذلك لتحسين محركات البحث؟

جولة سريعة عبر الأسئلة التي يطرحها الناس فعليًا حول هذا الموضوع.

“نحن نفكر في PWA. هل سيساعد ذلك في تحسين محركات البحث لدينا؟”

• لا توجد فائدة ترتيب متأصلة — تقول Google إن PWAs لا تحصل على أي ميزة في البحث. → قم ببناء PWA لفوائد المستخدم (قابل للتثبيت، دون اتصال، تحميلات متكررة سريعة)، وليس من أجل الترتيب. → لن يضر أيضًا بتحسين محركات البحث، طالما أن العرض وخدمة العامل لديك مضبوطان بشكل صحيح (تابع أدناه).

“نحن نبني/لدينا PWA. هل المحتوى الخاص بي قابل للفهرسة فعليًا؟”

• هل يحتوي HTML الأولي على المحتوى الحقيقي (SSR/الترتيب المسبق)، أم أنه غلاف تطبيق فارغ يتم ملؤه بواسطة JS؟
  • غلاف فارغ، بدون SSR → هذا هو فخ غلاف التطبيق. أضف SSR أو التقديم المسبق قبل القلق بشأن أي شيء خاص بـ PWA. (نفس الإصلاح مثل أي SPA.)
  • SSR/الترتيب المسبق في مكانه → جيد؛ انتقل إلى عامل الخدمة.

“كيف يجب أن يخزن عامل الخدمة الخاص بي الصفحات في ذاكرة التخزين المؤقت؟”

• مستندات HTML → الشبكة أولاً (أو إعادة التحقق من القديم أثناء إعادة التحقق، TTL قصير). أبدًا التخزين المؤقت أولاً لـ HTML.
• الأصول الثابتة (JS/CSS/الصور/الخطوط) → التخزين المؤقت أولاً جيد ومناسب.
• صفحة احتياطية دون اتصال → تأكد من أنها لا يمكن أن تكون أبدًا الإصدار الذي يفهرسه زحف جديد.

“فقدت PWA الخاصة بي الترتيب/الحركة بعد الإطلاق. أين أنظر؟”

1. قم بتشغيل فحص URL (اختبار مباشر) في Search Console — هل ترى Google الصفحة الحقيقية أم صفحة قديمة/دون اتصال/فارغة؟
2. إذا كانت قديمة أو فارغة → اشتبه في استراتيجية التخزين المؤقت لعامل الخدمة (HTML أولاً في التخزين المؤقت) أو خطوة SSR مفقودة.
3. إذا كان المحتوى موجودًا ولكن الترتيب ما زال انخفض → انظر إلى ما غيره التغيير في إعادة البناء: الروابط الداخلية، المحتوى، عمليات إعادة التوجيه، السرعة. تسمية PWA نادرًا ما تكون السبب.

“هل أحتاج إلى القيام بأي شيء خاص مع ملف البيان لتحسين محركات البحث؟”

• لا. حافظ على صحته لقابلية التثبيت؛ ليس له دور في تحسين محركات البحث. أنفق الجهد على عناوين URL، والعناوين، والوصف التعريفي، والبيانات المنظمة، وCore Web Vitals بدلاً من ذلك.

قائمة فحص تحسين محركات البحث لتطبيقات الويب التقدمية

مراجعة سريعة للحفاظ على قابلية الزحف والفهرسة لتطبيق ويب تقدمي:

• المحتوى الحقيقي يتم تقديمه من الخادم أو يتم توليده مسبقًا — وليس غلاف تطبيق فارغ يتم ملؤه بواسطة JavaScript بعد التحميل.
• كل مسار له عنوان URL حقيقي وفريد عبر History API (بدون توجيه تجزئة/#!).
• كل مسار يُرجع عنوانه الأساسي (canonical) وعنوانه ووصفه التعريفي في DOM المعروض.
• عامل الخدمة يقدم HTML الشبكة أولاً (أو إعادة التحقق من القديم أثناء إعادة التحقق، مع TTL قصير) — أبدًا التخزين المؤقت أولاً لمستندات HTML.
• الأصول الثابتة (JS/CSS/الصور/الخطوط) يمكن أن تكون التخزين المؤقت أولاً؛ هذا جيد.
• صفحة الاحتياط دون اتصال لا يمكن أبدًا أن تكون ما يفهرسه الزحف الجديد.
• فحص URL (الاختبار المباشر) يُظهر لـ Google الصفحة الحالية الحقيقية — مقارنةً بـ الصفحة المباشرة.
• ملف البيان صالح لقابلية التثبيت، لكنك لا تعامله كأداة لتحسين محركات البحث.
• قابلية التثبيت تُختبر لكل متصفح/نظام تشغيل، ولا يُفترض أنها عالمية (iOS Safari لا يحتوي على beforeinstallprompt؛ إنها إضافة يدوية إلى الشاشة الرئيسية) — ولا يُعتبر أي من هذا الاختلاف مشكلة في تحسين محركات البحث.
• يتم التقديم عبر HTTPS (مطلوب لعمال الخدمة على أي حال).
• Core Web Vitals سليمة — تحقق من أن حزمة JavaScript والترطيب لا يسببان انخفاض LCP/INP.
• التجارة الإلكترونية: كل صفحة منتج تُرجع HTML فريدًا حقيقيًا؛ التنقل ذو الأوجه/التوجيه من جانب العميل لا يُنتج عناوين URL فارغة أو لا نهائية للمعلمات.

تحسين محركات البحث لتطبيقات الويب التقدمية — ورقة الغش

هل يؤثر على تحسين محركات البحث؟

التخزين المؤقت لعامل الخدمة حسب نوع المورد

حقائق سريعة

• Google يمنح تطبيقات الويب التقدمية أي ميزة في الترتيب (Mueller).
• مُقدِّم العرض في Google لا يشغل عمال الخدمة عند الفهرسة.
• إشارة ترتيب HTTPS: “أقل من 1% من الاستعلامات العالمية” (Google، 2014).
• Bing: لا توجد إرشادات خاصة بتطبيقات الويب التقدمية — تعامل معها كأي موقع JS.

دليل الحوادث: انخفض حركة البحث بعد إصدار تطبيق ويب تقدمي

1. جمّد مسار الإصدار. أوقف المزيد من عمليات نشر عامل الخدمة والتوجيه مع الحفاظ على حالة الإنتاج الفاشلة ومعرّفات الإصدار.
2. تأكيد النطاق. قسّم الانخفاض حسب القالب والدليل والجهاز ووقت النشر. لا ينبغي افتراض فشل على مستوى PWA من مسار واحد معطوب.
3. قارن ثلاث استجابات. احفظ استجابة HTTP الخام، وصفحة معروضة حديثًا مع مسح التخزين، وصفحة مستخدم عائد يتحكم فيها عامل الخدمة. تحقق من العنوان، والكنسي، وتوجيهات الروبوتات، والمحتوى الأساسي، والروابط، وسلوك الحالة.
4. افحص التسجيل وسياسة التخزين المؤقت. في DevTools Application، حدد العامل النشط ونطاقه وإصدارات الانتظار وأسماء التخزين المؤقت ومعالج التنقل. تأكد من عدم حبس تنقلات HTML خلف استجابة قديمة من نوع cache-first.
5. تجاوز العامل. قم بإلغاء تسجيله أو استخدم خيار التجاوز في DevTools، وأعد التحميل، وكرر المسار المتأثر. إذا اختفى العيب، فمن المرجح أن يكون العامل أو التخزين المؤقت الخاص به هو الحدود؛ وإذا بقي، فتابع كحادثة JavaScript SEO عادية.
6. استعد مسار تنقل آمن. تراجع عن العامل أو بدّل طلبات المستندات إلى network-first مع احتياطي غير متصل صريح. لا تحذف جميع التخزينات المؤقتة بشكل أعمى إذا كان المستخدمون يعتمدون على البيانات غير المتصلة.
7. تحقق وراقب. اختبر متصفحًا نظيفًا، ومتصفحًا يتم تحديثه، ومتصفحًا غير متصل. ثم افحص عناوين URL تمثيلية وراقب أداء البحث خلال نافذة إعادة الزحف العادية.

التعامل مع ملف البيان كملف SEO

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

تخزين HTML مؤقتًا إلى الأبد

قاعدة cache-first التي تعامل التنقلات مثل الأصول غير القابلة للتغيير يمكن أن تُبقي النسخ القديمة أو الكنسيات أو توجيهات الروبوتات حية بعد الإصدار. خزّن JS وCSS والصور ذات الإصدارات بشكل عدواني؛ وامنح HTML استراتيجية تحديث واعية بالشبكة.

إرجاع الغلاف غير المتصل كصفحة ناجحة

تقديم نفس غلاف التطبيق غير المتصل لكل عنوان URL غير متاح يمكن أن يبدو كأن العديد من عناوين URL المختلفة تُرجع محتوى رقيقًا متطابقًا. أبقِ التجربة غير المتصلة منفصلة بوضوح عن التنقل العادي ولا تتظاهر بأن المستند المفقود هو الصفحة المطلوبة.

إخفاء التنقل خلف عناصر تحكم غير مرتبطة

زر يغير حالة العميل قد يعمل في التطبيق دون توفير مسار <a href> قابل للزحف إلى الوجهة. استخدم روابط حقيقية للمسارات التي تحتاج محركات البحث والمستخدمون إلى اتباعها، ثم حسّن الانتقال باستخدام JavaScript.

الاختبار فقط كمستخدم عائد دافئ

متصفح المطور مع عامل مثبت وتخزين مؤقت ممتلئ يمكن أن يخفي زيارة أولى معطوبة. اختبر تخزينًا نظيفًا، وترقية من العامل السابق، وزيارة عائدة. تلك حالات PWA مميزة.

مثال: تخزين الأصول وتخزين المستندات يحتاجان قواعد مختلفة

منطق عامل الخدمة المبسط التالي يُظهر الحدود. الأصول ذات التجزئة يمكن أن تكون cache-first؛ يجب أن يحاول تنقل المستندات الشبكة قبل الرجوع إلى الاحتياطي.

self.addEventListener('fetch', event => {
  const request = event.request;

  if (request.mode === 'navigate') {
    event.respondWith(
      fetch(request).catch(() => caches.match('/offline/'))
    );
    return;
  }

  if (['script', 'style', 'image', 'font'].includes(request.destination)) {
    event.respondWith(
      caches.match(request).then(cached => cached || fetch(request))
    );
  }
});

تعتمد سياسة الإنتاج الدقيقة على متطلبات التحديث وعدم الاتصال، لكن درس SEO ثابت: HTML ليس نفس نوع الأصل غير القابل للتغيير مثل حزمة ذات بصمة.

مثال: مسار قابل للزحف مقابل حالة خاصة بالتطبيق

<!-- Search engines and users get a real destination. -->
<a href="/products/running-shoes/">Running shoes</a>

<!-- This changes app state but exposes no destination URL. -->
<button onclick="showCategory('running-shoes')">Running shoes</button>

يمكن لـ PWA اعتراض الرابط لانتقال يشبه التطبيق دون إزالة عنوان URL القابل للزحف.

موجه: مراجعة استراتيجية تخزين عامل الخدمة

الصق كود العامل وجرد المسارات. لا تتضمن أسرارًا أو استجابات API خاصة.

Audit this service worker for search and freshness risks. Classify each fetch route as
document navigation, versioned static asset, API response, media, or offline fallback.
For each route, state the current strategy, the stale-content failure mode, and a safer
strategy. Pay special attention to HTML served cache-first, redirect handling, offline
shells returned for real URLs, cache-version cleanup, and worker scope. Quote the exact
code that creates each finding. Do not claim that PWA features provide a ranking boost.

Route inventory:
[PASTE ROUTES AND CONTENT TYPES]

Service worker:
[PASTE SOURCE]

موجه: بناء مصفوفة ضمان جودة إصدار PWA

Create a release QA matrix for this PWA. Cover a clean first visit, a returning visit
with the current worker, an upgrade from the previous worker, offline navigation, and a
worker-bypassed visit. For each state, list how to reproduce it and what to compare in
the raw response and rendered page: status behavior, title, canonical, robots, primary
content, internal links, and freshness. Use only the routes and requirements I provide;
flag missing evidence instead of inventing expected results.

Routes and requirements:
[PASTE ROUTE | EXPECTED CONTENT | OFFLINE REQUIREMENT | RELEASE CHANGE]

إطار عمل SHELL لمراجعات SEO الخاصة بـ PWA

• S: استجابة الخادم. يجب أن تكشف الاستجابة الأولى القابلة للاستخدام، أو استراتيجية العرض المتعمدة، عن الصفحة بدلاً من مجرد قشرة تطبيق فارغة.
• H: الروابط. تستخدم المسارات المهمة روابط قابلة للزحف بعناوين URL مستقرة، وليس عناصر تحكم موجودة فقط كحالة من جانب العميل.
• E: البيانات الوصفية المتوقعة. تظل العناوين، والروابط الأساسية، وتوجيهات robots، والبيانات المنظمة صحيحة في الحالات الأولية والمعروضة.
• L: المستندات الحية. لطلبات التنقل سياسة حداثة مناسبة لـ HTML؛ لا تتجاوز المستندات المخزنة مؤقتًا القديمة الإصدارات بصمت.
• L: اختبارات دورة الحياة. تغطي مراقبة الجودة التثبيت، والتفعيل، والتحديث، والعامل المنتظر، وعدم الاتصال، وحالات التجاوز بدلاً من جلسة تطوير واحدة دافئة.

يحافظ الإطار على مراجعة PWA المحددة ضيقة. إذا نجحت جميع النقاط الخمس، فإن معظم العمل المتبقي هو مراجعة JavaScript العادية والأداء وقابلية الفهرسة.

وحدة تحكم DevTools: فحص العامل النشط وذاكرة التخزين المؤقت

قم بتشغيل هذا في وحدة تحكم DevTools في المتصفح على PWA. يبلغ عن التسجيلات وأسماء ذاكرة التخزين المؤقت دون تغيير أي منهما.

const registrations = await navigator.serviceWorker.getRegistrations();
console.table(registrations.map(r => ({
  scope: r.scope,
  active: r.active?.scriptURL || '',
  waiting: r.waiting?.scriptURL || '',
  installing: r.installing?.scriptURL || ''
})));
console.log('Caches:', await caches.keys());

وحدة تحكم DevTools: مقارنة طلب شبكة مع استجابة مخزنة مؤقتًا

const path = location.pathname;
const network = await fetch(path, { cache: 'no-store' });
const cached = await caches.match(path);
console.table({
  network: { status: network.status, type: network.type },
  cache: { found: Boolean(cached), status: cached?.status ?? '' }
});

تثبت النتيجة وجود استجابة في ذاكرة التخزين المؤقت؛ لا تثبت أي معالج جلب سيفوز لكل تنقل. أكد التوجيه في مصدر العامل ولوحة الشبكة.

Regex: العثور على معالجات تنقل خطيرة تعتمد على ذاكرة التخزين المؤقت أولاً

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

request\.mode\s*===?\s*['"]navigate['"][\s\S]{0,500}caches\.(?:match|open)\s*\(

التحقق من إصدار PWA SEO

اختبر نفسك: PWA SEO

خمسة أسئلة سريعة حول كيفية تفاعل تطبيقات الويب التقدمية مع البحث. اختر إجابة لكل سؤال، ثم تحقق.

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

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

• قضايا JavaScript SEO وأفضل الممارسات — الأساس في العرض الذي يعتمد عليه كل PWA؛ قشرة التطبيق، وSSR، وما يفعله محرك Google وما لا يفعله.
• دليل المبتدئين إلى SEO التقني — حيث يتناسب العرض وقابلية الزحف مع الصورة الأكبر.

محادثاتي

• كيف يعمل البحث (SlideShare) — شرح خطوة بخطوة للزحف والعرض والفهرسة والترتيب، خط الأنابيب الذي يجب أن يمر به PWA. (إخلاء مسؤولية دائم: “هذا فهمي للأنظمة… لن يكون مكتملاً أو دقيقًا بنسبة 100%.”)

من حول الصناعة

• Google: Progressive Web Apps Don’t Rank Better Than Regular Sites (Search Engine Journal) — تغطية ساعات عمل Mueller التي ترتكز على تفنيد الأسطورة.
• Google Says Progressive Web Apps (PWAs) Have No Advantage In Search (Search Engine Roundtable) — تقرير مستقل عن نفس الجلسة.
• Service Worker – What SEOs Need to Know (SearchViu) — تصريحات Splitt/Mueller حول سبب تخطي المُقدِّم (renderer) لخدمة العامل (service worker).
• Understand JavaScript SEO Basics (Google) — نمط فشل غلاف التطبيق (app-shell)، موثق من المصدر.
• What makes a good Progressive Web App? (PWA checklist) (web.dev) — قابلية التثبيت والاكتشاف كفئتين منفصلتين.
• Twitter Lite case study (web.dev) — أرقام التفاعل الحقيقية، والدليل على أنها لم تكن أبدًا متعلقة بـ SEO.

فيديوهات

• Google Search Central (YouTube) — شروحات Martin Splitt حول JavaScript SEO وعملية العرض تغطي المسار الدقيق (الزحف ← العرض ← الفهرسة) الذي يعتمد عليه PWA، بما في ذلك كيفية تعامل المُقدِّم عديم الحالة (stateless renderer) مع JavaScript. القناة

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