تحسين محركات البحث في Astro

الخلاصة — يُعد Astro خيارًا ممتازًا لتحسين محركات البحث. فهو يبني صفحاتك افتراضيًا في صورة ملفات HTML عادية مسبقًا، لذلك يكون محتواك موجودًا أصلًا عندما يصل Google (أو أي روبوت) — من دون انتظار تشغيل JavaScript. وهو سريع جدًا أيضًا. النقطة الوحيدة التي ينبغي معرفتها: يمنحك Astro HTML نظيفًا، لكنه لا يضيف تلقائيًا عناوين صفحاتك أو خريطة موقعك أو وسوم canonical. تضبط هذه الأمور بنفسك (وذلك سهل).

ما المقصود بـ «Astro SEO»؟

Astro هو إطار لبناء المواقع. وفكرته الكبيرة هي «JavaScript أقل». ففي حين تبني أطر مثل React أو Next.js الصفحة في متصفحك باستخدام JavaScript غالبًا، يبني Astro صفحاتك في صورة ملفات HTML عادية وقت البناء، ولا يرسل JavaScript تقريبًا إلا عندما يحتاج جزء من الصفحة إليه فعلًا. Evidence for this claim Astro prerenders pages as static HTML by default and only sends client JavaScript for explicitly hydrated components. Scope: Astro default static output and islands architecture. Confidence: high · Verified: 2026-07-14 Astro: Why Astro

هذا الفرق وحده هو سبب ملاءمة Astro لمحركات البحث. عندما يزحف محرك بحث إلى صفحة، يريد قراءة محتواك. وفي الموقع الثقيل بـ JavaScript قد لا يكون المحتوى موجودًا في الصفحة بعد — إذ يجب على الروبوت تشغيل JavaScript أولًا، وقد يتأخر ذلك. أما مع Astro فالمحتوى موجود أصلًا في HTML لحظة تحميل الصفحة. لا شيء يستحق الانتظار.

أشغّل موقعي الخاص، patrickstox.com، على Astro — لذا فالأمر ليس نظرية بالنسبة إليّ. هذه هي الحزمة التي أبني عليها فعلًا.

لماذا يُعد Astro جيدًا لتحسين محركات البحث

• المحتوى موجود في HTML فورًا. لا تأخير في التصيير ولا محتوى مفقود.
• إنه سريع. مواقع Astro خفيفة وتميل إلى تحقيق نتائج ممتازة في مقاييس تجربة الصفحة لدى Google (Core Web Vitals).
• كل صفحة لها عنوان URL حقيقي مستقل. لا يوجد توجيه معقد لتطبيق أحادي الصفحة قد يربك برامج الزحف.
• يُحمّل JavaScript حيث تكون الحاجة إليه فقط. يمكن لمعرض صور أو مربع بحث أن يكون تفاعليًا من دون إبطاء بقية الصفحة.

ما الذي لا يفعله Astro لك

هذه نقطة تربك الناس. القول إن «Astro محسّن لتحسين محركات البحث» صحيح جزئيًا فقط. يمنحك Astro أساسًا نظيفًا، لكنه لا يضيف تلقائيًا:

• كتابة العناوين والأوصاف الوصفية لصفحتك.
• إنشاء خريطة موقع (تضيف لذلك إضافة رسمية مجانية). Evidence for this claim Astro's official sitemap integration generates sitemap files from statically generated routes. Scope: Astro @astrojs/sitemap integration. Confidence: high · Verified: 2026-07-14 Astro: Sitemap integration
• إضافة وسوم canonical (التي تخبر Google بالنسخة «الرسمية» من الصفحة).
• إضافة بيانات منظمة (الشيفرة التي تشغّل النتائج الغنية).
• إنشاء ملف robots.txt.

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

قائمة البداية البسيطة

• أضف خريطة موقع باستخدام الإضافة الرسمية @astrojs/sitemap.
• اضبط title وdescription وcanonical لكل صفحة (عادةً من ملف تخطيط مشترك واحد).
• استخدم مكوّن Astro المدمج <Image /> للصور — فهو يجعل تحميلها سريعًا ويمنع قفز الصفحة.
• ضع ملف robots.txt في مجلد public/.

هل تريد النسخة المتعمقة — Server Islands وView Transitions والتصيير الثابت مقابل التصيير من الخادم، والأخطاء الدقيقة التي ينبغي تجنبها؟ انتقل إلى علامة التبويب Advanced. وللاطلاع على الصورة الأكبر لكيفية تعامل محركات البحث مع JavaScript، راجع JavaScript SEO.

الخلاصة — بُنية Astro مهيأة جيدًا لتحسين محركات البحث: تُصيَّر الصفحات ونقاط النهاية مسبقًا إلى HTML ثابت افتراضيًا، لذلك لا توجد موجة انتظار في طابور التصيير لهذا المحتوى — لكن هذا افتراض افتراضي، وليس ضمانًا شاملًا، كما أن HTML الثابت أو المولّد من الخادم لا يثبت وحده قابلية الزحف أو الفهرسة أو الترتيب أو Core Web Vitals لعناوين URL المنشورة. تقوم بنية الجزر بترطيب المكوّنات التي تحددها فقط بتوجيه client:* — وكل ما عدا ذلك يرسل HTML من دون JavaScript خاص بالترطيب، مع أن نصوص الصفحة والجزر الأخرى وتحسينات الموجّه قد تضيف JavaScript في مواضع أخرى من الصفحة. لا ينشئ Astro وسومًا وصفية أو عناوين canonical أو خرائط مواقع أو بيانات منظمة تلقائيًا — صِل هذه الأشياء صراحةً، ويفضل التحقق منها باستخدام Content Collections + Zod. وتخدم Server Islands (التي تتطلب adapter) الغلاف الثابت مع محتوى احتياطي في المستند الأولي، ثم تجلب المحتوى المؤجل بصورة مستقلة — تحقّق مما يجلبه روبوت زحف معين فعلًا بدل الافتراض. وتستخدم View Transitions الدالة history.pushState وهي آمنة لتحسين محركات البحث؛ إذ يزحف Google إلى صفحات MPA الأساسية بصورة عادية. أشغّل patrickstox.com على Astro، والميزات أدناه هي ما أستخدمه فعلًا — وقد تحققت منها مقابل الموقع المنشور، لا في بيئة التطوير المحلية فحسب.

لماذا يتجاوز Astro مشكلة تصيير JavaScript بالكامل

السبب الكامل لصعوبة تحسين محركات البحث في JavaScript هو الموجة الثانية. يجلب Google أولًا HTML الخام لصفحتك، ثم يضع الصفحة في طابور تصيير داخل Chromium عديم الرأس لاحقًا — وهذا الطابور هو موضع الخطر. وتصف وثائق Google الأمر بوضوح: “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (ترجمة) «يضع Googlebot كل الصفحات ذات رمز حالة HTTP 200 في طابور التصيير ما لم تخبر وسمة robots meta Google بعدم فهرسة الصفحة. وقد تبقى الصفحة في هذا الطابور بضع ثوانٍ، لكن الأمر قد يستغرق أطول من ذلك.» أما في تطبيق SPA المصيَّر من جهة العميل، فلا يظهر محتواك حتى تعمل موجة التصيير تلك.

وضع الإخراج الافتراضي في Astro هو static: تُصيَّر الصفحات ونقاط النهاية مسبقًا إلى ملف HTML مكتمل وقت البناء. لذلك، في مسار يعمل بهذا الوضع الافتراضي، يكون HTML الخام هو الصفحة المصيَّرة. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering ولا توجد موجة ثانية ينبغي انتظارها لهذا المسار، إذ لا شيء متبقيًا للتنفيذ. يرى Googlebot المحتوى الكامل في الجلب الأول. وكما يقول Joost de Valk (مؤسس Yoast): “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (ترجمة) «من منظور تحسين محركات البحث، يُعد HTML الثابت على CDN نقطة بداية أفضل مما ستمنحك إياه معظم أنظمة إدارة المحتوى.»

لكن ذلك هو الافتراضي — وليس خاصية شاملة لكل مسار. اضبط output: 'server' في astro.config.mjs لينقلب الافتراضي إلى التصيير عند الطلب (سنتناول ذلك أدناه)؛ وحتى في مشروع افتراضيه static، يتيح adapter لمسار منفرد الانسحاب باستخدام export const prerender = false. لا يضمن أي من ذلك النتيجة بفضل البنية وحدها: فـ HTML الثابت أو المولّد من الخادم والجزر وadapters لا تضمن وحدها قابلية الزحف أو الفهرسة أو الترتيب أو Core Web Vitals — إذ تعتمد هذه الأمور على المسار المنشور وروبوت الزحف المحدد، لذلك تحقّق منها بدل افتراض أن الإطار يتولاها.

يساعد هذا أيضًا مع برامج الزحف التي لا تستطيع التصيير إطلاقًا. تقول Google بوضوح إن “not all bots can run JavaScript” (ترجمة) «ليست كل الروبوتات قادرة على تشغيل JavaScript» — وهذه هي حقيقة 2026 بالنسبة إلى معظم روبوتات الذكاء الاصطناعي وكثير من الأدوات الخارجية. ومخرجات Astro القائمة على HTML قابلة للقراءة من كل واحد منها حيث صُيِّرت مسبقًا فعلًا، لا من Googlebot وحده. (هذه هي النقطة نفسها التي أطرحها في SEO for a headless CMS: وضع التصيير هو المنتج.)

بنية الجزر: JavaScript حيث تطلبه فقط

يصيّر Astro مكوّناتك إلى HTML، ويرسل — على حد تعبيره — “just HTML & CSS, stripping out all client-side JavaScript automatically.” (ترجمة) «HTML وCSS فحسب، مع إزالة كل JavaScript من جهة العميل تلقائيًا». التفاعل اختياري. تحدد مكوّنًا بتوجيه client:* — مثل client:load أو client:idle أو client:visible — ولا تُرطّب JavaScript إلا تلك الجزيرة. أما كل ما عداها فيظل HTML ثابتًا. Evidence for this claim Astro client directives selectively hydrate interactive islands while other components remain static HTML. Scope: Astro islands and client directives. Confidence: high · Verified: 2026-07-14 Astro: Islands

وهذا قريب من المثالي لتحسين محركات البحث. فالمحتوى الذي يحتاج Googlebot إلى فهرسته هو HTML عادي، ولا تثقل عليه أدواتك التفاعلية. ويُعد client:visible مفيدًا خصوصًا: إذ لا يبدأ مكوّن أسفل الجزء المرئي بالترطيب حتى يُمرَّر إليه، فلا يحجب LCP أبدًا. ويعود المفهوم إلى Jason Miller (مبتكر Preact)، الذي وصف “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions” (ترجمة) بأنه «تصيير صفحات HTML على الخادم، وحقن عناصر نائبة أو فتحات حول المناطق عالية الديناميكية» للترطيب الانتقائي.

هناك دقيقتان تستحقان الدقة، لأن تغطية المنافسين تميل إلى طمس الفرق بينهما:

• client:only حيوان مختلف. بخلاف client:load وclient:idle وclient:visible، يتخطى مكوّن client:only التصيير من الخادم بالكامل — فلا ينتج HTML على الخادم إطلاقًا. وأي محتوى قابل للفهرسة يوضع فقط داخل مكوّن client:only لن يكون في المستند الذي يجلبه Googlebot؛ بل لا يوجد إلا بعد أن يرطبه المتصفح. لا تضع المحتوى الرئيسي هناك.
• هذا ترطيب انتقائي، وليس قابلية للاستئناف. يعيد Astro تشغيل شيفرة العميل لكل جزيرة من الصفر في المتصفح؛ ولا يستأنف حالة تنفيذ جرى تسلسلها على الخادم كما يفعل نموذج قابلية الاستئناف (مثل نموذج Qwik). يخلط الكتّاب بين الأمرين — لكنهما آليتان مختلفتان.

والمكوّن غير المرطَّب ليس صورة JavaScript الكاملة في الصفحة. فعبارة «Zero JS» تصف مكوّنًا واحدًا من دون توجيه client:* — ويمكن لـ Astro مع ذلك إرسال وسوم <script> على مستوى الصفحة، وموجّه View Transitions، وجزر أخرى في مواضع أخرى من الصفحة نفسها. صِف ما يُرسل لكل مكوّن/مسار، لا بوصف شامل للصفحة.

ما الذي لا يفعله Astro تلقائيًا

ينشئ Astro HTML دلاليًا نظيفًا — ولا شيء آخر من ناحية تحسين محركات البحث. لا توجد بيانات وصفية أو canonical أو خريطة موقع أو بيانات منظمة من الصندوق. وخرافة أن «Astro محسّن تلقائيًا لتحسين محركات البحث» هي خرافة فعلًا. أنت تملك:

• الوسوم الوصفية (العنوان والوصف وOpen Graph وTwitter)
• عناوين URL الأساسية
• خريطة الموقع (عبر التكامل الرسمي)
• البيانات المنظمة / JSON-LD
• robots.txt

Astro أفضل أساس استخدمته، لكنه أساس لا بيت مكتمل.

خريطة الموقع: @astrojs/sitemap

ثبّتها باستخدام npx astro add sitemap. فهي تزحف إلى مساراتك المولّدة ثابتًا وتصدر sitemap-index.xml وملفات sitemap-0.xml مجزأة وقت البناء. ثمة أمران يوقعان الناس في المشكلات:

• يجب ضبط site: في astro.config.mjs. فبدونه ينشئ التكامل لا شيء بصمت. وهذا هو السبب الأكثر شيوعًا لسؤال «أين خريطة موقعي؟».
• يجب إضافة سطر خريطة الموقع إلى robots.txt بنفسك. لا يفعل Astro ذلك.

وللتحكم، تستبعد filter() المسارات (صفحات المعاينة/المسودات — وهذا هو الاستخدام الذي أخصصه له في هذا الموقع)، وتتيح لك serialize() ضبط lastmod وchangefreq وpriority، كما يصدر الخيار i18n إدخالات hreflang في خريطة الموقع. هذا ما تحدده وثائق @astrojs/sitemap الحالية — تحقّق منه مقابل الإصدار المثبت لديك إذا كنت على إصدار أقدم، فقد تغير سلوك التكامل عبر الإصدارات الرئيسية من قبل.

النطاق الذي يربك الناس: يستهدف اكتشاف التكامل المسارات المولّدة ثابتًا. وإذا كانت بعض عناوين URL لا توجد إلا وقت التشغيل — مسارات مصيَّرة من الخادم (المضبوطة على output: 'server') أو مسارات مولّدة عند الطلب بدل وقت البناء — فلا تفترض أنها في خريطة الموقع. أضفها صراحةً باستخدام customPages، ثم افتح sitemap-index.xml فعلًا بعد البناء لتتأكد من وجودها. لا تصدق عبارة «التكامل يتولى ذلك» في أي شيء ليس مسارًا ثابتًا وقت البناء.

الوسوم الوصفية والعناوين الأساسية: نمط BaseLayout

لا يملك Astro مكوّن <Head> خاصًا — فأنت تتحكم في <head> مباشرةً داخل ملفات .astro. والنمط القياسي (وهو ما أفعله) هو BaseLayout.astro واحد يتلقى title وdescription وcanonicalURL كخصائص ويكتب الرأس. اضبط العنوان الأساسي صراحةً في كل صفحة وحافظ على اتساقه مع og:url. لا تحتاج إلى مكتبة، لكن حزمة المجتمع astro-seo (npm) غلاف مريح بمكوّن واحد لـ title/description/OG/Twitter/canonical إن أردت.

مجموعات المحتوى بوصفها شبكة أمان لتحسين محركات البحث

هذه هي ميزة SEO غير المقدَّرة في Astro. مجموعات المحتوى هي طبقة محتوى ذات أنواع آمنة لـ Markdown/MDX/JSON، مع تحقق مخطط Zod. وهذا يعني أنه يمكنك جعل title وdescription حقلين مطلوبين — وإذا غاب أحدهما من صفحة ما يفشل البناء فشلًا. فلا يمكنك إرسال صفحة بلا عنوان عرضًا. وتولّد دوال الاستعلام (getCollection() وgetEntry()) صفحات ثابتة وقت البناء، لذلك يكون الإخراج HTML عاديًا عند النشر. ولأن MDX يبقي Markdown الخام مصدر الحقيقة، فهذه الملفات أيضًا محتوى مصدر نظيف لروبوتات الذكاء الاصطناعي وأنماط شبيهة بـ llms.txt. وهذا الموقع نفسه مبني على مجموعات محتوى ذات frontmatter متحقق منه بواسطة Zod.

astro:assets: الصور بصورة صحيحة (مع فخ واحد)

يحوّل مكوّن <Image /> الصور تلقائيًا إلى WebP، ويستنتج الأبعاد كي “avoid Cumulative Layout Shift (CLS),” (ترجمة) «يتجنب Cumulative Layout Shift (CLS)»، ويضبط loading="lazy" افتراضيًا، ويشترط alt — فغياب alt خطأ في الترجمة. ويوسّع <Picture /> ذلك بعناصر <source> للـ AVIF/WebP/البديل.

الفخ هو أن loading="lazy" التلقائي خاطئ لصورة LCP لديك (وهي الصورة الرئيسية عادةً). فتأخير تحميل أهم صورة يؤخرها. وبالنسبة إلى الصور الواقعة فوق الجزء المرئي، استبدل ذلك بـ loading="eager" وfetchpriority="high". وتحتاج الصور البعيدة إلى width وheight صريحين.

Server Islands: ما الذي يراه الزاحفون فعلًا

تُعد Server Islands (في Astro 4.12+) الميزة التي تخطئ فيها معظم أدلة المنافسين. باستخدام server:defer، يُصيَّر المكوّن على الخادم بصورة مستقلة عن الصفحة الرئيسية. ويُخدم الغلاف الثابت فورًا؛ ووفق وثائق Astro: “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (ترجمة) «ستُصيَّر صفحتك فورًا مع أي محتوى احتياطي محدد بوصفه عنصرًا نائبًا. ثم يُجلب محتوى المكوّن نفسه على العميل ويُعرض عند توفره.»

هناك أمران ينبغي تحديدهما بدقة. أولًا، تتطلب Server Islands adapter — فهي ميزة عند الطلب، وليست شيئًا ينتجه بناء ثابت محض بمفرده. ثانيًا، التسلسل هو: يرسل المستند الأولي أي محتوى احتياطي ضبطته، ويكون المحتوى الحقيقي للجزيرة طلبًا منفصلًا مستقلًا يُجلب بعد تحميل الصفحة، عبر نقطة نهاية خاصة به. وهذا حد صارم لما يحتويه المستند الأولي — ولا أعمم أكثر من ذلك بشأن ما يفعله كل زاحف محدد بعد ذلك من دون اختبار عناوين URL المنشورة لديك مباشرةً.

النتيجة العملية لتحسين محركات البحث هي: يحتوي HTML الثابت الذي يقرؤه الزاحف في ذلك الجلب الأول على المحتوى الاحتياطي، لا محتوى الجزيرة المؤجل. وهذا مثالي لما صُممت Server Islands له — أشياء مخصصة مرتبطة بالجلسة (حالة تسجيل الدخول وعدّاد سلة التسوق والتوصيات) لا ينبغي تخزينها مؤقتًا أو فهرستها أصلًا. لكنه خطأ بالنسبة إلى المحتوى الرئيسي القابل للفهرسة. ضع أي شيء يحتاج إلى الترتيب في قالب Astro الرئيسي، ودع Server Islands تتولى الأجزاء الديناميكية المحيطة به.

أوضاع الإخراج: الثابت مقابل الخادم، والتجاوز لكل مسار

وضع الإخراج الافتراضي في Astro هو static — تُصيَّر الصفحات ونقاط النهاية إلى HTML وقت البناء. اضبط output: 'server' في astro.config.mjs لينقلب الافتراضي إلى التصيير عند الطلب: تُصيَّر الصفحات لكل طلب (مع adapter)، وهو مفيد للمصادقة والبيانات الآنية والتخصيص الذي يتجاوز ما تغطيه Server Islands. وفي كلتا الحالتين يمكنك تجاوز الافتراضي لكل مسار: ففي مشروع افتراضيه static، يختار export const prerender = false مسارًا للتصيير عند الطلب؛ وفي مشروع افتراضيه server، يعيد export const prerender = true مسارًا إلى التصيير وقت البناء. لذلك نادرًا ما يكون قول «موقعي ثابت» أو «موقعي SSR» صحيحًا لكل مسار — افحص إعداد المسار، لا الإعداد الأعلى في الملف فحسب. Evidence for this claim Astro uses static output and prerenders routes at build time by default. Scope: Astro default output mode; routes can opt out of prerendering. Confidence: high · Verified: 2026-07-14 Astro: On-demand rendering

من منظور SEO الخالص، يتساوى HTML المصيَّر مسبقًا وHTML المولّد عند الطلب — فكلاهما يرسل HTML كاملًا إلى الزاحف في الطلب الأول، بعد أن تتأكد فعلًا من أن المسار يعيد 200 مع ترميز كامل. وقد تبث المسارات عند الطلب HTML، ويمكن للبيانات البطيئة أو ظروف الشبكة أن تؤخر الأجزاء اللاحقة، لذلك ليست الاستجابة المبثوثة دليلًا تلقائيًا على وصول كل قطعة من المحتوى — افحص، ولا تفترض. والفرق الحقيقي بين الوضعين تشغيلي: المحتوى المصيَّر مسبقًا ثابت حتى البناء التالي (أو تحديث تشغيل منفصل مضبوط) ويُخدم مباشرةً من حافة CDN؛ أما المحتوى عند الطلب فدائمًا حديث لكنه يعتمد على سلامة adapter وبيئة التشغيل في الإنتاج. لا تتعامل مع ذلك بوصفه قرار SEO — اختر بناءً على حداثة البيانات والتشغيل، ثم تحقق من المسارات المنشورة والحالات وعمليات إعادة التوجيه ورؤوس الاستجابة بدل الاستقراء من نجاح بيئة التطوير المحلية.

View Transitions: آمنة لتحسين محركات البحث رغم إحساس التطبيق الأحادي

يمنح <ClientRouter /> في Astro (المعروف سابقًا باسم <ViewTransitions />) تنقلًا ناعمًا شبيهًا بتطبيق SPA باستخدام View Transitions API وHistory API في المتصفح. والحقيقة الأساسية أنه يتنقل باستخدام history.pushState، وهو ما توصي به Google بالضبط للتنقل من جهة العميل — إذ تحذر Google من أن عناوين URL القائمة على الأجزاء (#hash) شيء “can’t reliably resolve.” (ترجمة) «لا تستطيع حله بصورة موثوقة». والأهم أن View Transitions تحسين من جهة المتصفح. عندما يزحف Googlebot، يطلب كل عنوان URL ويحصل على صفحة HTML عادية مكتملة — وتظل صفحات MPA الكامنة كما هي. تؤثر الانتقالات فقط في ما يراه الإنسان في المتصفح.

إذن لا، لا تحول View Transitions موقع Astro إلى SPA، ولا تكسر تحسين محركات البحث. وهناك فجوة جديرة بالملاحظة: لا يحتوي دليل View Transitions في Astro على قسم لتحسين محركات البحث، وربما لهذا تستمر خرافة «إنها تكسر SEO». وللتحقق في موقعك، اجلب بضعة عناوين URL مباشرةً وتأكد من أن كلًا منها يعيد HTML كاملًا — لا تأخذ الأمر بالإيمان، بل افحص نشرَك.

أخطاء Astro SEO الشائعة

1. افتراض أن Astro يتولى تحسين محركات البحث عنك. إنه يتولى HTML. أما البيانات الوصفية والعناوين الأساسية وخريطة الموقع والمخطط فهي مسؤوليتك.
2. نسيان site: في الإعداد — فلا تُنشأ خريطة موقعك بصمت.
3. عدم إضافة خريطة الموقع إلى robots.txt — لن يفعل Astro ذلك.
4. تحميل صورة LCP بكسل — استبدل ذلك في الصورة الرئيسية بـ eager + fetchpriority.
5. وضع محتوى قابل للفهرسة في Server Island — يرى الزاحفون المحتوى الاحتياطي لا المحتوى الحقيقي، كما أن Server Islands تتطلب adapter من الأساس.
6. مطاردة نتيجة Lighthouse المثالية والتوقف عندها. السرعة إشارة ترتيب، وليست إشارة الترتيب الوحيدة. الصفحة الفارغة السريعة لا تتصدر — فالمحتوى والروابط وE-E-A-T ما تزال تؤدي العمل الأكبر.
7. وضع المحتوى القابل للفهرسة داخل مكوّن client:only فقط. بخلاف توجيهات client:* الأخرى، يتخطى client:only التصيير من الخادم بالكامل — ولا يوجد HTML لهذا المكوّن حتى يرطبه المتصفح.
8. التعامل مع «Astro ثابت/سريع» بوصفه ضمان نتيجة. HTML الثابت أو المولّد عند الطلب والجزر وadapters آليات — لا تضمن وحدها قابلية الزحف أو الفهرسة أو الترتيب أو Core Web Vitals. تحقق من المسار المنشور، لا من مخطط البنية.

موضع هذا في المجموعة

Astro إجابة محددة، وصديقة لتحسين محركات البحث على نحو استثنائي، عن الأسئلة التي يطرحها JavaScript SEO حول التصيير، كما أنه واجهة أمامية شائعة لإعدادات headless CMS. ويتصل جانب الأداء مباشرةً بـ Core Web Vitals في مجموعة أداء الويب، كما أن منهجية اختبار «هل يوجد محتواي فعلًا في HTML؟» هي نفسها المستخدمة في مجموعات الزحف والفهرسة.

أخطاء Astro SEO المضادة

هذه أخطاء عملية أراها فعلًا في مواقع Astro — وليست افتراضات نظرية. كل واحدة منها للوقاية لا للتشخيص: اكتشفها قبل أن تُشحن.

التعامل مع Astro على أنه «محسّن لتحسين محركات البحث» من الصندوق

يمنحك Astro HTML ثابتًا سريعًا ونظيفًا، وهذا تقدم كبير فعلًا — لكنه ليس هو نفسه الوسوم الوصفية أو العناوين الأساسية أو خريطة الموقع أو البيانات المنظمة. لماذا هذا خطأ: تنشر الفرق صفحات بلا تنويع في <title>، وبلا عنوان أساسي، وبلا خريطة موقع لأن «Astro يتولى SEO»، ثم تتساءل لماذا لم تُفهرس النتائج كما توقعت. ما ينبغي فعله بدلًا من ذلك: صِل خصائص BaseLayout.astro للعنوان والوصف والعنوان الأساسي منذ اليوم الأول، وأضف @astrojs/sitemap، وتعامل مع هذه الأمور كخطوات بناء مطلوبة لا كإعدادات افتراضية.

نسيان site: في astro.config.mjs

هذا هو التقرير الأكثر شيوعًا لسؤال «لماذا خريطة موقعي فارغة؟». لماذا هذا خطأ: تحتاج @astrojs/sitemap إلى عنوان URL مطلق للموقع كي تبني إدخالات <loc> مطلقة — ومن دون ضبط site: ينتج التكامل لا شيء بصمت (لا خطأ ولا تحذير). ما ينبغي فعله بدلًا من ذلك: اضبط site: في astro.config.mjs قبل تثبيت تكامل خريطة الموقع، وتحقق بعد البناء التالي من أن sitemap-index.xml يحتوي فعلًا على عناوين URL.

ترك خريطة الموقع خارج robots.txt

لا تؤدي تثبيت @astrojs/sitemap إلى إضافة سطر Sitemap: إلى robots.txt — فهذه خطوة يدوية منفصلة يفترض الناس أنها تلقائية. لماذا هذا خطأ: ما تزال محركات البحث قادرة على العثور على خريطة الموقع إذا أرسلتها في Search Console، لكنك تفقد مسار الاكتشاف السلبي الذي تعتمد عليه روبوتات أخرى (وزواحف Bing القريبة من IndexNow). ما ينبغي فعله بدلًا من ذلك: أضف Sitemap: https://yoursite.com/sitemap-index.xml إلى robots.txt في public/، وتأكد بعد النشر من أنه يُحل.

ترك loading="lazy" الافتراضي على الصورة الرئيسية

يحمّل مكوّن <Image /> في Astro الصور بتكاسل افتراضيًا، وهو التصرف الصحيح للصور الواقعة أسفل الجزء المرئي والخاطئ للصورة الوحيدة التي تكون عادةً عنصر LCP لديك. لماذا هذا خطأ: يؤخر التحميل الكسول للصورة الرئيسية بدء المتصفح حتى لطلب تلك الصورة، ما يضر مباشرةً بنتيجة Largest Contentful Paint. ما ينبغي فعله بدلًا من ذلك: تجاوز الصورة الرئيسية/الواقعة فوق الجزء المرئي صراحةً باستخدام loading="eager" وfetchpriority="high"، واترك كل صورة أخرى على الإعداد الكسول الافتراضي.

وضع محتوى قابل للفهرسة داخل Server Island

صُمّم server:defer للمحتوى المخصص المرتبط بالجلسة — أعداد السلة وحالة تسجيل الدخول والتوصيات — لا لأي شيء تريد أن يحتل ترتيبًا. لماذا هذا خطأ: يحتوي HTML الثابت الذي يقرؤه الزاحف على المحتوى الاحتياطي المحدد للجزيرة، لا ما يُجلب من جهة العميل بعد تحميل الصفحة، لذلك يكون أي محتوى رئيسي يوضع هناك غير مرئي لمحركات البحث في الزحف الأول. ما ينبغي فعله بدلًا من ذلك: أبقِ المحتوى الذي تريد ترتيبه في قالب Astro الرئيسي، واحجز Server Islands للأجزاء الديناميكية المخصصة التي لا ينبغي فهرستها أصلًا.

افتراض أن نتيجة Lighthouse السريعة هي خط النهاية

تحقق مواقع Astro عادةً نتائج قوية في Core Web Vitals، ومن المغري التوقف عند ذلك. لماذا هذا خطأ: السرعة مدخل ترتيب واحد بين مداخل كثيرة — فالصفحة السريعة الفارغة أو الرقيقة لا تتفوق على صفحة أبطأ ذات محتوى وروابط وعمق موضوعي أفضل. ما ينبغي فعله بدلًا من ذلك: تعامل مع الأداء بوصفه حدًا أدنى تحصل عليه مجانًا مع Astro، ثم أنفق جهد التحسين الفعلي على جودة المحتوى والربط الداخلي وأعمال البيانات المنظمة/البيانات الوصفية التي لا ينفذها Astro.

افتراض أن «الثبات افتراضيًا» صحيح لكل مسار

وضع الإخراج الثابت في Astro هو الافتراضي، لكنه افتراضي لا خاصية شاملة — إذ يقلبه output: 'server'، ويمكن ضبط prerender لكل مسار في أي من الاتجاهين. لماذا هذا خطأ: تصف الفرق موقعها كله بأنه «static» أو «SSR» استنادًا إلى الإعداد الأعلى، ولا تفحص المسارات الفردية، ثم تتفاجأ عندما يتصرف مسار واحد بصورة مختلفة في الإنتاج. ما ينبغي فعله بدلًا من ذلك: افحص إعداد prerender لكل مسار تستند إليه في استدلالك، وتحقق من الاستجابة الفعلية (رمز الحالة والترميز الكامل وسلوك إعادة التوجيه) على عنوان URL المنشور بدل ملف الإعداد.

وضع المحتوى فقط داخل مكوّن client:only

لا يساوي client:only كلًا من client:load وclient:idle وclient:visible — فهو يتخطى التصيير من الخادم بالكامل. لماذا هذا خطأ: لا ينتج المكوّن الذي يستخدم client:only أي HTML على الخادم، لذلك يكون كل محتوى قابل للفهرسة يوضع هناك فقط غير مرئي لزاحف يقرأ الاستجابة الخام، ومن السهل اللجوء إلى client:only من أجل «البساطة» من دون إدراك كلفة SEO. ما ينبغي فعله بدلًا من ذلك: صَيِّر المحتوى الرئيسي في مكوّن مصيَّر من الخادم أو قالب الصفحة، واحجز client:only لعناصر التفاعل فقط التي لا تحتوي على شيء قابل للفهرسة.

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

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

• يصيّر وضع الإخراج الافتراضي في Astro الصفحات مسبقًا إلى HTML ثابت وقت البناء — وفي مسار يعمل بذلك الافتراضي، يكون HTML الخام هو الصفحة المكتملة، فلا تنطبق عليه مشكلة طابور التصيير لدى Google (المعروفة بـ «الموجة الثانية»). هذا افتراضي لا خاصية شاملة: يقلبه output: 'server'، ويمكن لـ prerender تجاوزه لكل مسار في أي من الاتجاهين.
• ترطّب بنية الجزر المكوّنات المحددة بـ client:* فقط؛ فالمكوّن الذي لا يملك ذلك يرسل HTML من دون JavaScript خاص بترطيبه (مع أن Astro قد يضيف نصوص الصفحة وجزر أخرى وJavaScript للموجّه في مواضع أخرى). وclient:only استثناء — إذ يتخطى التصيير من الخادم بالكامل، لذلك لا ينبغي أن يعيش المحتوى القابل للفهرسة هناك وحده. هذا ترطيب انتقائي لا قابلية استئناف. ويحافظ client:visible على عدم حجب JavaScript الواقع أسفل الجزء المرئي لـ LCP.
• لا ينشئ Astro شيئًا تلقائيًا من ناحية SEO — فالوسوم الوصفية والعناوين الأساسية وخريطة الموقع والبيانات المنظمة وrobots.txt كلها خطوات بناء مقصودة. و«Astro محسّن تلقائيًا لـ SEO» خرافة.
• يكتشف @astrojs/sitemap المسارات المولّدة ثابتًا — لكن يجب ضبط site: في الإعداد (وإلا فلن يفعل شيئًا بصمت)، وإضافة سطر خريطة الموقع إلى robots.txt بنفسك، وإضافة أي عناوين URL لا توجد إلا وقت التشغيل صراحةً عبر customPages.
• يمكن لمجموعات المحتوى + Zod جعل title/description مطلوبين، مع إفشال البناء إذا غاب أحدهما عن صفحة — شبكة أمان لـ SEO.
• يحوّل astro:assets و<Image> الصور إلى WebP، ويضبط الأبعاد (فيمنع CLS)، ويحمّلها بتكاسل افتراضيًا، ويشترط alt. تجاوز الصورة LCP بـ loading="eager" + fetchpriority="high".
• تتطلب Server Islands (server:defer) adapter، وتخدم الغلاف الثابت + المحتوى الاحتياطي فورًا في المستند الأولي، ثم تجلب الجزيرة بصورة مستقلة بعد ذلك. يرى الزاحفون الذين يقرؤون المستند الأولي المحتوى الاحتياطي لا الجزيرة — فلا تضع محتوى قابلًا للفهرسة هناك.
• يتساوى الإخراج الثابت وعند الطلب (الخادم) من ناحية SEO بعد التحقق — فكلاهما يرسل HTML كاملًا إلى الزواحف في الطلب الأول، لكن المسارات عند الطلب قد تبث، لذلك تأكد من وصول الاستجابة مكتملة فعلًا؛ اختر الوضع بناءً على حداثة البيانات والتشغيل، لا SEO.
• تستخدم View Transitions (<ClientRouter />) history.pushState وهي آمنة لـ SEO؛ ويزحف Google إلى صفحات MPA الأساسية عاديًا. إنها تحسين من جهة المتصفح لا تحويل إلى SPA.
• لا شيء مما سبق ضمان لنتيجة — HTML الثابت/المولّد من الخادم والجزر وadapters آليات، وليست دليلًا على قابلية الزحف أو الفهرسة أو الترتيب أو Core Web Vitals. تحقق من المسار المنشور.
• تحقق مواقع Astro نتائج قوية في Core Web Vitals في معياره الخاص لعام 2023 — فقد اجتاز أكثر من 50% من مواقع Astro تقييم CWV لدى Google، متجاوزةً خط الأساس الصناعي آنذاك بكثير؛ تعامل مع ذلك كنقطة بيانات مؤرخة لا كضمان حي.

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

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

Astro

• بنية الجزر — كيف يزيل Astro JavaScript من جهة العميل ولا يرطّب إلا المكوّنات التفاعلية.
• مرجع توجيهات القوالب — client:load/idle/visible/only وserver:defer، بما في ذلك ما يتخطاه client:only.
• تحسين الصور (astro:assets) — مكوّنا <Image>/<Picture> وWebP والأبعاد وCLS.
• @astrojs/sitemap — إنشاء خريطة الموقع تلقائيًا وfilter وserialize وi18n.
• Server Islands — server:defer ومتطلب adapter والمحتوى الاحتياطي والجلب المؤجل من العميل.
• التصيير عند الطلب — وضْعا الإخراج static/server وprerender لكل مسار وبث HTML.
• مرجع التوجيه — كيفية تصيير الصفحات ونقاط النهاية مسبقًا افتراضيًا.
• مرجع Astro Runtime API — معالجة Response/إعادة التوجيه ورموز الحالة الافتراضية.
• مجموعات المحتوى — محتوى آمن الأنواع مع تحقق مخطط Zod.
• View Transitions — <ClientRouter /> والتنقل عبر History API.

Google

• فهم أساسيات JavaScript SEO — طابور التصيير والروابط القابلة للزحف وHistory API وتحفظ «ليست كل الروبوتات تشغّل JavaScript».
• دليل متعمق لكيفية عمل Google Search — الزحف ← التصيير ← الفهرسة، والموضع الذي يلغي فيه SSG خطوة التصيير.

Bing / Microsoft

• IndexNow / indexnow.org — بروتوكول الدفع الذي ينسجم جيدًا مع نشر Astro الثابت (صِله بخطوة النشر كي يسمع Bing وYandex بالصفحات الجديدة فورًا).

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

تصريحات مسجلة من وثائق Astro وGoogle وممارسين مسمّين. كل رابط لمحرك بحث أو وثيقة رابط عميق يقفز إلى المقطع المقتبس في صفحة المصدر.

Google — طابور التصيير الذي يتجاوزه Astro

• “Googlebot queues all pages with a 200 HTTP status code for rendering unless a robots meta tag tells Google not to index the page. The page may stay on this queue for a few seconds, but it can take longer than that.” (ترجمة) «تضع Googlebot جميع الصفحات التي تحمل حالة HTTP 200 في طابور التصيير ما لم تطلب وسمة robots meta من Google عدم فهرسة الصفحة. وقد يستمر الانتظار بضع ثوانٍ أو أطول.» الانتقال إلى الاقتباس
• “not all bots can run JavaScript” (ترجمة) «ليست كل الروبوتات قادرة على تشغيل JavaScript» — وهذا يوضح لماذا تساعد المخرجات القائمة على HTML خارج Googlebot. الانتقال إلى الاقتباس

وثائق Astro — الجزر والصور وخرائط المواقع وServer Islands

• “just HTML & CSS, stripping out all client-side JavaScript automatically.” (ترجمة) «HTML وCSS فحسب، مع إزالة كل JavaScript من جهة العميل تلقائيًا» — حول بنية الجزر. الانتقال إلى الاقتباس
• “infers image dimensions to avoid Cumulative Layout Shift (CLS).” (ترجمة) «يستنتج أبعاد الصورة لتجنب Cumulative Layout Shift (CLS)» — حول مكوّن Image. الانتقال إلى الاقتباس
• “Your page will be rendered immediately with any specified fallback content as a placeholder. Then, the component’s own contents are fetched on the client and displayed when available.” (ترجمة) «تُعرض الصفحة فورًا مع المحتوى الاحتياطي المحدد كعنصر نائب، ثم يجلب العميل محتوى المكوّن نفسه ويعرضه عندما يتاح» — حول Server Islands. الانتقال إلى الاقتباس

Jason Miller (مبتكر Preact، وصاحب مصطلح «بنية الجزر»)

• يعمل الترطيب الانتقائي عبر “rendering HTML pages on the server, and inject[ing] placeholders or slots around highly dynamic regions.” (ترجمة) «تصيير صفحات HTML على الخادم، وحقن عناصر نائبة أو فتحات حول المناطق عالية الديناميكية». — مقتبس في وثائق Astro: بنية الجزر

Joost de Valk (مؤسس Yoast SEO)

• “From an SEO perspective, static HTML on a CDN is a better starting point than most CMSes will ever give you.” (ترجمة) «من منظور تحسين محركات البحث، يُعد HTML الثابت على CDN نقطة بداية أفضل مما ستمنحك إياه معظم أنظمة إدارة المحتوى.» — Joost.blog: دليل Astro SEO الكامل

قائمة التحقق لـ Astro SEO

فحص للتأكد من أن موقع Astro مضبوط فعلًا للبحث — لا أنه مستند فحسب إلى أساس جيد:

• ضُبط site: في astro.config.mjs (لن تُنشأ خريطة الموقع بصمت من دونه).
• ثُبّت @astrojs/sitemap وأُضيفت إحالة خريطة الموقع إلى robots.txt يدويًا.
• يوجد robots.txt في public/ ولا يحظر أي شيء تريد فهرسته.
• تضبط كل صفحة title وdescription فريدين (ويفضّل عبر BaseLayout.astro مشترك).
• يوجد canonical يشير إلى نفسه في كل صفحة ويتطابق مع og:url.
• تستخدم مجموعات المحتوى مخطط Zod يجعل title/description مطلوبين (يفشل البناء عند غيابهما).
• تستخدم الصور <Image />/<Picture />؛ ولكل منها alt (وغياب أحدها خطأ في الترجمة على أي حال).
• تتجاوز صورة LCP/الرئيسية التحميل الكسول الافتراضي باستخدام loading="eager" وfetchpriority="high".
• لا يوجد محتوى قابل للفهرسة في Server Island (server:defer) — يرى الزاحفون المحتوى الاحتياطي، كما تحتاج Server Islands إلى adapter كي تعمل أصلًا.
• لا يوجد محتوى قابل للفهرسة فقط داخل مكوّن client:only — فهو يتخطى التصيير من الخادم، لذلك لا يوجد له HTML حتى يرطبه المتصفح.
• لأي مسار يستخدم output: 'server' أو prerender = false لكل مسار، تأكد من إضافة عناوين URL وقت التشغيل صراحةً إلى خريطة الموقع (customPages) — فاكتشاف خريطة الموقع تلقائيًا يستهدف المسارات المولّدة ثابتًا.
• توجد البيانات المنظمة (JSON-LD) في <head> المصيَّر من الخادم.
• إذا فُعّل <ClientRouter />، فتحقق بعينة من أن كل عنوان URL ما يزال يعيد HTML كاملًا عند جلبه مباشرةً.
• للمسارات عند الطلب/من الخادم: اجلب عنوان URL حيًا من الإنتاج مباشرةً وتأكد من رمز الحالة وسلوك إعادة التوجيه وHTML الاستجابة الكامل — لا تستنتج من التطوير المحلي، لأن سلوك adapter/بيئة التشغيل قد يختلف.

النماذج الذهنية

1. HTML الخام هو الصفحة المكتملة — لهذا الافتراضي في ذلك المسار. يعني وضع الإخراج الثابت في Astro عدم وجود موجة تصيير ينبغي انتظارها لمسار مصيَّر مسبقًا — فما يجلبه Googlebot هو ما يُفهرس. وهذا افتراضي لكل مسار، لا ضمان للموقع كله (output: 'server' وprerender لكل مسار يمكن أن يغيراه)، لذلك افحص المسار لا الإعداد الأعلى فحسب. وعندما ينطبق ذلك، يكون View Source هو الحقيقة (عكس SPA مصيَّر من جهة العميل) — لكن أكد انطباقه قبل اعتباره حقيقة.

2. أساس لا نهاية، ولا ضمان لنتيجة. يمنحك Astro HTML نظيفًا وآليات أداء قوية مجانًا. وكل ما يرسل معنى إلى محركات البحث — البيانات الوصفية والعنوان الأساسي وخريطة الموقع والمخطط — خطوة مقصودة تضيفها. «بنية جيدة» ≠ «انتهى العمل»، ولا أحدهما دليل على قابلية الزحف أو الفهرسة أو الترتيب — فما تزال تحتاج إلى التحقق من الموقع المنشور.

3. الجزر إضافية — باستثناء client:only. يوضع التفاعل فوق HTML ولا يكون تحته أبدًا مع client:load/client:idle/client:visible: فهذه التوجيهات تضيف JS إلى مكوّن واحد من دون إزالة المحتوى من الأساس القابل للزحف. ويكسر client:only هذا النمط — إذ يتخطى التصيير من الخادم بالكامل، فلا يكون إضافيًا بل فجوة حقيقية في HTML الثابت ما لم تخطط لها. كما أن ترطيب الجزر انتقائي لا قابلية استئناف — فلا تخلط بينهما.

4. الغلاف الثابت هو ما يراه الزاحفون. في Server Islands يقرأ الزاحف المحتوى الاحتياطي في الغلاف الثابت، لا المحتوى المؤجل. قاعدة القرار: يذهب المحتوى القابل للفهرسة إلى القالب الرئيسي، ويذهب المحتوى المخصص/الديناميكي إلى الجزيرة.

5. تحسين المتصفح ≠ تغيير بنيوي. تغيّر View Transitions تجربة المتصفح (التنقل الناعم عبر history.pushState)، لكنها لا تغير تجربة الزحف (فكل عنوان URL ما يزال صفحة HTML كاملة). والتحسينات التي تترك MPA الأساسي سليمًا آمنة لـ SEO.

6. تحقق وقت البناء. تحوّل مجموعات المحتوى + Zod عبارة «تذكر إضافة عنوان» إلى «لن يُشحن البناء من دونه». ادفع متطلبات SEO إلى نظام الأنواع، وعندها تتوقف عن كونها أشياء يمكنك نسيانها.

Astro SEO — ورقة الغش

ما هو تلقائي مقابل ما يقع عليك

أوضاع الإخراج

توجيهات الجزر

• client:load — ترطيب فوري.
• client:idle — ترطيب عندما يكون المتصفح في حالة خمول.
• client:visible — ترطيب عند التمرير إلى داخل الجزء المرئي (الأفضل لما يقع أسفل الجزء المرئي؛ ويحمي LCP).
• client:only — يتخطى التصيير من الخادم بالكامل. لا يوجد HTML لهذا المكوّن حتى يرطبه المتصفح؛ وليس إضافيًا مثل التوجيهات الأخرى.

قواعد سريعة

• غياب site: → لا خريطة موقع (بصمت).
• محتوى قابل للفهرسة في Server Island → يرى الزاحف المحتوى الاحتياطي؛ وتحتاج Server Islands إلى adapter.
• محتوى قابل للفهرسة داخل client:only فقط → لا HTML له، إطلاقًا.
• تغطي خريطة الموقع المسارات الثابتة → أضف عناوين URL وقت التشغيل عبر customPages.
• تستخدم View Transitions الدالة history.pushState → آمنة لـ SEO، وMPA باقٍ تحتها.
• الإخراج الثابت/من الخادم والجزر آليات لا ضمانات — تحقق من المسار المنشور ورمز الحالة وHTML الكامل قبل ادعاء نتيجة.
• ما تزال الصفحة الفارغة السريعة لا تتصدر — فالسرعة إشارة وليست الإشارة الوحيدة.

دقّق في HTML المبني من Astro

شغّل هذا بعد astro build. فهو يفحص الأثر الذي تتلقاه برامج الزحف، لا شجرة المكوّنات المصدرية:

find dist -name '*.html' -type f | while IFS= read -r file; do
  canonicals=$(grep -Eio '<link[^>]+rel=["'"']canonical["'"'][^>]*>' "$file" | wc -l | tr -d ' ')
  titles=$(grep -Eio '<title>[^<]*</title>' "$file" | wc -l | tr -d ' ')
  if [ "$canonicals" -ne 1 ] || [ "$titles" -ne 1 ]; then
    printf '%s\ttitles=%s\tcanonicals=%s\n' "$file" "$titles" "$canonicals"
  fi
done

تعني النتيجة الفارغة أن لكل ملف HTML مولّد عنوانًا أساسيًا وعنوانًا واحدًا بالضبط؛ لكنها لا تتحقق من صحة قيمهما، لذلك افحص عينة منها بصورة منفصلة. وهذا يفحص أثر البناء فقط — ولا يقول شيئًا عن المسارات عند الطلب (output: 'server') أو Server Islands، إذ لا توجد هذه في صورة ملفات ثابتة.

افحص عناوين URL الحية في الإنتاج

بالنسبة إلى كل ما يُصيَّر عند الطلب — مسارات output: 'server' أو prerender = false لكل مسار أو Server Islands — لا ينطبق فحص مخرجات البناء أعلاه. افحص الاستجابة المنشورة الفعلية بدلًا من ذلك:

# Replace with your real URLs
for url in "https://example.com/" "https://example.com/some-server-route/"; do
  echo "== $url =="
  curl -sS -D - -o /dev/null "$url" | grep -Ei '^(HTTP|location|cache-control):'
done

ابحث عن رمز الحالة المتوقع (200 لصفحة حية، أو رمز إعادة توجيه حقيقي إذا أعادت التوجيه — لا تفترض 302 مقابل 301 من دون فحص)، وتأكد من أن curl -sS "$url" يعيد ترميزًا كاملًا لا غلافًا احتياطيًا، إذا كنت تفحص صفحة تتضمن Server Island. نفّذ ذلك على الإنتاج لا astro dev — فقد يختلف سلوك adapter وبيئة التشغيل عن البيئة المحلية.

أدوات لموقع Astro

• @astrojs/sitemap — تكامل خريطة الموقع الرسمي (astro add sitemap). لا تنسَ site: في الإعداد.
• astro-seo (npm) — مكوّن مجتمعي اختياري يجمع العنوان والوصف وOpen Graph وبطاقات Twitter والعنوان الأساسي في وسم واحد.
• astro-seo-schema (npm) — مساعد typed لـ JSON-LD والبيانات المنظمة في Astro.
• astro:assets <Image> / <Picture> — تحسين الصور المدمج (WebP/AVIF والأبعاد وفرض alt والتحميل الكسول).
• فحص عنوان URL (Google Search Console) — تأكد من وجود محتواك في HTML الذي جرى زحفه (مع Astro ينبغي أن يكون موجودًا أصلًا في View Source — فحص سريع للسلامة).
• زاحف يصيّر JavaScript — استخدم Ahrefs Site Audit أو Screaming Frog للتحقق من تطابق الخام والمصيَّر عبر الموقع (ينبغي أن يتطابقا في المسارات المصيَّرة مسبقًا — تحقق من ذلك، ولا تفترضه، وافحص بصورة منفصلة أي مسارات عند الطلب أو Server Islands).
• IndexNow — صِله بخطوة النشر/الإتاحة كي يسمع Bing وYandex بالصفحات الثابتة الجديدة فورًا.

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

خمسة أسئلة سريعة عن تأثير بُنية Astro في تحسين محركات البحث. اختر إجابة لكل سؤال، ثم تحقق منها.

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

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

• JavaScript SEO: دليل حاسم — أساسيات التصيير التي تفسر لماذا تمثل مخرجات Astro القائمة على HTML هذه الميزة.
• دليل المبتدئ إلى Technical SEO — موضع اختيار الإطار في الصورة الأكبر.

كلامي في الفعاليات

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

من أنحاء المجال

• وثائق Astro: بنية الجزر — الشرح المرجعي لكيفية إزالة Astro JavaScript من جهة العميل.
• وثائق Astro: @astrojs/sitemap — الإعداد الرسمي ومتطلب site: وخيارات filter/serialize/i18n.
• وثائق Astro: Server Islands — server:defer والمحتوى الاحتياطي وسلوك الجلب من العميل الذي لا يراه الزاحفون.
• Joost de Valk: دليل Astro SEO الكامل — دليل الممارس الأكثر اعتمادًا، بقلم مؤسس Yoast؛ قوي في الأنماط الحديثة الجاهزة للذكاء الاصطناعي وIndexNow.
• Google Search Central: فهم أساسيات JavaScript SEO — طابور التصيير والروابط القابلة للزحف وإرشادات History API التي تتبعها View Transitions في Astro.
• Astro: تقرير أداء أطر الويب لعام 2023 — بيانات Core Web Vitals التي تقارن Astro بالأطر الأخرى.
• Search Engine Journal: Core Web Vitals وWordPress وAstro — تغطية مستقلة لمقارنة أداء Astro وWordPress.

إحصاءات تستحق الاستشهاد

تأتي كل الأرقام أدناه من تقرير Astro لأداء أطر الويب لعام 2023 (ومن تغطية SEJ له)؛ تعامل معها بوصفها معايير من حقبة 2023 لا أرقامًا حية.

• يجتاز أكثر من 50% من مواقع Astro تقييم Core Web Vitals لدى Google — أعلى من متوسط المجال البالغ نحو 40,5%، وكان Astro وSvelteKit الإطارين الرئيسيين الوحيدين اللذين تجاوزا ذلك الخط الأساسي (Next.js نحو 25% وNuxt نحو 20%). المصدر
• معدل اجتياز INP يبلغ 68,8% لدى Astro — ويُنسب إلى بُنية MPA (من دون تنقل تقوده JavaScript)، التي تُبقي الخيط الرئيسي متاحًا. المصدر
• وزن الصفحة الوسيط 1,65 MB — الأخف في مجموعة البيانات. المصدر
• LCP: Astro نحو 0,44s مقابل WordPress نحو 0,81s — أسرع بنحو 46%، في مقارنة التقرير. التغطية

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