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

الخلاصة — يبني Gatsby الصفحات افتراضيًا إلى HTML مكتمل قبل زيارة أي شخص، وهو نمط SSG؛ لذلك يجد Google المحتوى داخل الصفحة بلا انتظار JavaScript. وهذه بداية قوية لـSEO. كما يوفر أنماط عرض للصفحات التي تُنشأ لاحقًا أو تستخدم بيانات كل طلب. لكن Gatsby يرسل حزمة React كبيرة إلى المتصفح، ما قد يبطئ الصفحة، ويظل عليك إعداد الوسوم الوصفية وخرائط الموقع وcanonical والنصوص البديلة.

ما Gatsby؟

Gatsby إطار مواقع مبني على React. تبني تطبيقات React المعتادة الصفحة في المتصفح بعد تحميل JavaScript، فيرى محرك البحث أولًا غلافًا شبه فارغ. يعكس Gatsby ذلك افتراضيًا: فعند تشغيل gatsby build يحول معظم الصفحات مسبقًا إلى ملفات HTML كاملة. لذلك يكون المحتوى حاضرًا في HTML حين يطلب Google أوBing أوالقارئ الصفحة. Evidence for this claim Gatsby creates static HTML files during its production build. Scope: Gatsby static generation; client-side behavior can still be added. Confidence: high · Verified: 2026-07-14 Gatsby: Builds and deploys

يجعل هذا النمط Gatsby مولد مواقع ثابتة (SSG)، ولهذا يكون جيدًا لـSEO افتراضيًا وأفضل من تطبيق React عادي. ويمكن للصفحات اختيار ثلاثة أنماط أخرى: التوليد عند أول طلب، أو لكل طلب على الخادم، أو بالكامل في المتصفح. يشرحها تبويب المتقدم لأن كلًا منها يغير ما يراه الزاحف.

لماذا يقلق الناس من Gatsby وSEO؟

الخرافة الأشهر هي: «Gatsby سيئ لـSEO لأنه يستخدم React». هذا خطأ؛ يعمل React بعد بناء الصفحة وتسليمها ليضيف التفاعل فقط، بينما يكون النص والروابط والعناوين موجودًا في HTML منذ البداية.

إذن يتجاوز Gatsby أكبر عقبة تلقائيًا، لكنه لا ينفذ كل أعمال SEO عنك.

ما يزال عليك إعداده

لا يصبح موقع Gatsby محسنًا تلقائيًا؛ عليك:

• إضافة وسم العنوان والوصف التعريفي لكل صفحة عبر Gatsby Head API الحديثة. Evidence for this claim Gatsby's Head API lets pages export document-head metadata. Scope: Gatsby Head API. Confidence: high · Verified: 2026-07-14 Gatsby: Head API
• إنشاء خريطة موقع باستخدام gatsby-plugin-sitemap.
• تعيين عناوين canonical كي لا تتنافس نسخ الصفحة.
• كتابة نصوص الصور البديلة؛ تحسن أداة الصور الحجم تلقائيًا لكنها لا تكتب النص البديل.

المفاجأة الأساسية

يرسل Gatsby بيئة React كاملة، نحو 200KB أو أكثر، إلى المتصفح في كل صفحة. لا يضر ذلك الفهرسة لأن HTML مكتمل، لكنه قد يبطئ الصفحة ويؤثر في Core Web Vitals. أما أطر أخف مثل Astro فترسل قدرًا ضئيلًا جدًا من JavaScript.

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

للتفاصيل التقنية عن Head API وreact-helmet، ومشكلات الخريطة وcanonical، وكلفة حزمة React، ومستقبل Gatsby، انتقل إلى تبويب المتقدم.

الخلاصة — لدى Gatsby أربعة أنماط عرض: SSG الافتراضي وDSG وSSR والمسارات العاملة لدى العميل، ولا تضع كلها المحتوى في HTML الخام بالطريقة نفسها. يعرض SSG الصفحة وقت gatsby build؛ ويؤجل DSG التوليد إلى أول طلب؛ وينشئ SSR الصفحة لكل طلب؛ ولا تعرض المسارات الخاصة بالعميل محتوى خاصًا بالمسار قبل JavaScript. أيًا كان المسار، يرطب Gatsby الصفحة بحزمة React كاملة تقارب 200KB أو أكثر، وهي كلفة أداء لا زحف. النهج الحالي للبيانات الوصفية هو Gatsby Head API المدمج منذ v4.19 بدل gatsby-plugin-react-helmet. وتشمل الأخطاء المتكررة تكرار canonical، وتسرب المسودات والصفحات اليتيمة إلى الخرائط، وعدم معرفة أن الخريطة لا تُنشأ إلا في الإنتاج، وغياب alt في GatsbyImage، وعدم اتساق الشرطة المائلة، وعدم اختبار مسارات DSG وSSR والمسارات الخاصة بالعميل في الإنتاج. ومنذ استحواذ Netlify عام 2023 تباطأت الصيانة بشدة.

أنماط عرض Gatsby الأربعة وأثرها في SEO

تعالج Google صفحات JavaScript على ثلاث مراحل: الزحف ثم العرض ثم الفهرسة، ويجري العرض في مرور منفصل داخل طابور باستخدام Chromium بلا واجهة. وتوضح Google السبب في عدم الاعتماد عليه: “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” (ترجمة) «يظل العرض على الخادم أو المسبق فكرة ممتازة لأنه يسرع الموقع للمستخدمين والزواحف، وليست كل الروبوتات قادرة على تشغيل JavaScript».

لا تكون كل صفحات Gatsby HTML ثابتًا منشأ وقت البناء؛ بل يختار كل قالب أو صفحة أحد أربعة مسارات Evidence for this claim gatsby build writes production output, including generated HTML, to the public directory. Scope: Gatsby production builds. Confidence: high · Verified: 2026-07-14 Gatsby CLI: build :

• SSG، مولد المواقع الثابتة، وهو الافتراضي. ينتج gatsby build HTML كاملًا في /public، فيحتوي جلب Googlebot الأول على النص والروابط والبيانات الوصفية. وهذا المسار الآمن قليل المخاطر لمعظم الصفحات.
• DSG، التوليد الثابت المؤجل. يؤجل إنشاء الصفحة إلى أول طلب، وهو مفيد للمواقع الضخمة ذات الصفحات قليلة الزيارات. لا يكشف سجل البناء وحده ما يراه الزاحف؛ افحص الطلب الأول والسلوك بعد التخزين المؤقت.
• SSR، العرض على الخادم. تُنشأ الصفحة لكل طلب عبر Gatsby Functions وبيانات وقت الطلب. اختبر في الإنتاج حالة الاستجابة ورؤوس التخزين والمهلات وما يراه الزاحف عند الاستجابة الفارغة أو الخطأ.
• المسارات الخاصة بالعميل. تُعرض بالكامل في المتصفح ولا تحمل محتوى خاصًا بالمسار في HTML الأولي، مثل تطبيق React يعمل لدى العميل وحده. لا تفترض أن Google أو أي زاحف يرى محتوى الصفحة قبل تشغيل JavaScript؛ تعامل معها بوصفها معتمدة على JS تصميميًا. يناسب ذلك المحتوى المحمي أو المتطلب للمصادقة، لكنه لا يناسب محتوى تريد فهرسته بنصه.

يجري ترطيب React عبر ReactDOMClient.hydrateRoot() فوق الناتج لإضافة التفاعل، بغض النظر عن مسار العرض. وهذه مسألة منفصلة عن مصدر إنشاء الصفحة.

بعكس SSG وDSG وSSR، يقدم تطبيق React العميل الخالص <div id="root"> فارغًا ويعتمد على المتصفح أو العارض لبناء الصفحة. تشحن معظم صفحات Gatsby HTML ذا معنى، وهي ميزة فهرسة حقيقية لكنها خاصية لكل صفحة لا ضمانًا من الإطار. لا تضمن أنماط العرض وأدوات الصور Core Web Vitals أو الفهرسة أو الترتيب؛ افحص ناتج الإنتاج الفعلي لكل مسار.

المشكلة المشتركة بين SSG وDSG وSSR هي الأداء لا قابلية الزحف: يرسل Gatsby بيئة React كاملة ويرطبها في كل صفحة.

Gatsby Head API مقابل gatsby-plugin-react-helmet

هذا أهم سؤال لتحديد ما إذا كان التنفيذ حديثًا.

النهج القديم — gatsby-plugin-react-helmet. كان تعيين <title> والوصف ووسوم الرأس يجري عبر react-helmet وهذه الإضافة التي تمنحه دعم SSR. بدونها لا تظهر الوسوم إلا بعد JavaScript، لا في HTML الخام. يعمل النهج، لكنه يعاني مشكلات مع React Hooks والعرض المتزامن، وخطأ عنوان التبويب الخلفي الذي يعالج بـdefer={false}.

النهج الحديث — Gatsby Head API منذ v4.19. يضيف Gatsby عناصر الرأس عبر تصدير مسمى Head من ملف صفحة أو قالب. Evidence for this claim Gatsby pages and templates can export a named Head function to add head elements. Scope: Gatsby Head API. Confidence: high · Verified: 2026-07-14 Gatsby: Head API

export const Head = () => (
  <>
    <title>Page Title</title>
    <meta name="description" content="..." />
  </>
)

تتلقى الواجهة خصائص مفيدة مثل location.pathname وparams وdata من استعلام GraphQL وpageContext، وتزيل تكرار الوسوم التي تشترك في id بحيث يفوز الأخير. لكن تشغيل Head API وreact-helmet معًا قد يسبب تعارضًا. تعمل في ملفات الصفحات والقوالب فقط لا المكونات العادية. مزاياها: لا حزمة خارجية ولا Provider وترتيب حتمي مع بث React 18. استخدمها للمشاريع الجديدة وخطط لترحيل القديمة.

تدعم الأنماط الأربعة تصدير Head، لكن وقت وصول مخرجاته إلى HTML القابل للجلب يختلف: تُضمّن في SSG وقت البناء، وتُنشأ في DSG عند أول طلب وفي SSR لكل طلب، ولا تظهر في HTML الأولي للمسار الخاص بالعميل. فلا تساوِ بين «أضفت تصدير Head» و«توجد هذه البيانات في HTML الخام لكل مسار»؛ افحص ناتج الإنتاج الفعلي عبر view-source: أوcurl لكل مسار عرض مستخدم، لا لصفحة ممثلة واحدة فقط.

خطأ «الوسوم في DevTools لا المصدر». من أعراض Gatsby SEO المعروفة أن يظهر العنوان ووسوم meta في Chrome DevTools لكنها تغيب عن view-source:. تعرض DevTools DOM بعد الترطيب، أي بعد تشغيل JavaScript، بينما يعرض view-source: HTML الخام. إذا لم تظهر الوسوم إلا في DevTools، فإن مكون SEO يُعرض لدى العميل بدل تضمينه في ناتج Gatsby الثابت، وغالبًا لأنه استُخدم كمكون عادي لا بوصفه تصدير Head للصفحة أو داخله. تحقق دائمًا من HTML الخام لا DevTools.

توصيل مكون SEO بطبقة GraphQL

طبقة بيانات Gatsby هي GraphQL، ومنها تغذي بيانات الصفحات الوصفية.

• يجلب useStaticQuery القيم العامة من siteMetadata، مثل العنوان والوصف وsiteUrl في gatsby-config.js.
• تمرر استعلامات GraphQL للصفحة الخاصية data مباشرة إلى تصدير Head.
• النمط المعتاد هو قيمة الصفحة أوsiteMetadata احتياطية.

يبدو تصدير Head الذي يتلقى بيانات الصفحة هكذا:

export const Head = ({ data }) => (
  <>
    <title>{data.post.title}</title>
    <meta name="description" content={data.post.excerpt} />
  </>
)

خرائط الموقع: gatsby-plugin-sitemap ومزالقها

ثبّت gatsby-plugin-sitemap واضبطها في gatsby-config.js. ومن المزالق:

• تنشئ sitemap-index.xml لا /sitemap.xml؛ أرسل عنوان الفهرس إلى Search Console، ولا ترسل /sitemap.xml متوقعًا أن يُحل.
• تعمل في بناء الإنتاج فقط ولا تفعل شيئًا في gatsby develop. اختبر عبر gatsby build && gatsby serve.
• يضيف createLinkInHead: true افتراضيًا مرجع الخريطة إلى الرأس.
• تستبعد دائمًا /dev-404-page و/404 و/offline-plugin-app-shell-fallback.
• تتجاهل Google <priority> و<changefreq>؛ ركز على <lastmod> الدقيق.
• الحد الافتراضي لـentryLimit هو 45٬000 عنوان URL لكل ملف.

استبعاد المسودات مسؤوليتك. يبني Gatsby كل ما يجده، فتدخل المسودة الخريطة ما لم ترشحها في gatsby-node.js عبر GraphQL، مثل استبعاد ما لا يحمل تاريخ نشر. لا تخفها داخل مكون React؛ عندها تكون قد بُنيت وأُدرجت بالفعل.

تحتاج مسارات DSG وSSR والمسارات الخاصة بالعميل قرارًا صريحًا بشأن الخريطة. تعكس gatsby-plugin-sitemap ما تستطيع رؤيته وقت البناء. توجد صفحة SSG كملف ثابت فتكون مؤهلة طبيعيًا للإدراج، بينما لا يوجد HTML لصفحة DSG قبل أول طلب، ولا HTML ثابت أصلًا لصفحة SSR، ولا محتوى خاص بالمسار في HTML الأولي للمسار الخاص بالعميل. لا تفترض إدراج أي منها، أو وجوب إدراجه، لمجرد وجود المسار؛ قرر لكل صفحة هل تنتمي إلى الخريطة، ثم تحقق من أن sitemap-index.xml الناتج يعكس القرار الفعلي لا مجرد تخمين وقت البناء.

robots.txt: إضافة gatsby-plugin-robots-txt

تنشئ gatsby-plugin-robots-txt ملف robots.txt وقت البناء وتقرأ process.env.GATSBY_ACTIVE_ENV ثم process.env.NODE_ENV، ما يتيح قواعد مختلفة لكل بيئة. الاستخدام التقليدي هو حظر الزواحف في معاينات Netlify وفروعه لمنع فهرسة staging مع إبقاء الإنتاج مفتوحًا.

عناوين canonical وخطأ التكرار

يوجد نهجان صالحان:

1. تضيف gatsby-plugin-canonical-urls وسم canonical لكل صفحة. اضبط stripQueryString: true كي لا تعامل /blog?tag=foo و/blog كصفحتين منفصلتين.
2. استخدم Head API لتعيين canonical من location.pathname بنفسك:

export const Head = ({ location }) => (
  <link rel="canonical" href={`https://example.com${location.pathname}`} />
)

خطأ canonical المزدوج. إذا استخدمت gatsby-plugin-canonical-urls ووسم react-helmet معًا، فستنتج وسمَي <link rel="canonical">. اختر آلية واحدة. ولـreact-helmet توجد gatsby-plugin-react-helmet-canonical-urls؛ ومع Head API ضع canonical هناك واحذف الإضافة.

الشرطة المائلة الختامية. قد تصل صفحات Gatsby بالشكلين، ويستخدم <Link> توجيه History API لدى العميل متجاوزًا تحويلات 301 على الخادم. اختر صيغة واحدة، وافرضها لدى المستضيف أوCDN، واجعل canonical متسقًا معها.

SEO الصور: gatsby-plugin-image

تعد gatsby-plugin-image من نقاط قوة Gatsby، ولها مكونان:

• StaticImage للصور ذات المسار المعروف والثابت وقت البناء.
• GatsbyImage للصور الديناميكية القادمة من GraphQL.

تنشئ تلقائيًا أحجامًا متعددة وصيغ WebP وAVIF وتحميلًا كسولًا ونقاط توقف 750/1080/1366/1920px. كما تولد عناصر نائبة ضبابية أو بلون سائد أوSVG متتبع تحجز المساحة وتمنع Cumulative Layout Shift. الأبعاد تمنع CLS، والصيغ الحديثة والتحميل الكسول يساعدان LCP.

الشيء الوحيد الذي لا تفعله هو كتابة النص البديل. تقع هذه المسؤولية عليك في كل صورة، ويعد غياب alt عن GatsbyImage من أكثر أخطاء Gatsby SEO شيوعًا. وإذا كنت تنتقل من حزمة gatsby-image القديمة، فاستخدم: npx gatsby-codemods gatsby-plugin-image.

البيانات المنظمة (JSON-LD)

صيغة Google المفضلة للبيانات المنظمة هي JSON-LD، والطريقة النظيفة لإضافتها في Gatsby الحديث هي Head API مع وسم script:

export const Head = ({ data }) => (
  <script type="application/ld+json">
    {JSON.stringify({
      "@context": "https://schema.org",
      "@type": "Article",
      "headline": data.post.title,
    })}
  </script>
)

توفر gatsby-plugin-next-seo مكونات JSON-LD جاهزة إن لم ترد كتابتها يدويًا. وللتوضيح: gatsby-plugin-manifest ليست إضافة بيانات منظمة؛ فهي تنشئ بيان تطبيق PWA، مثل الأيقونات ولون السمة، ولا علاقة لها بـschema.

حزمة React وCore Web Vitals

هنا يظهر ضعف Gatsby الحقيقي مقارنة بالمولدات عديمة JavaScript.

• الترطيب الكامل، افتراضي Gatsby 1–4، يرطب شجرة React كلها ويرسل بيئة React أكبر من 200KB لكل صفحة. لا يضر ذلك الزحف لأن HTML معروض مسبقًا، لكنه يؤثر قطعًا في سرعة التحميل وCWV.
• الترطيب الجزئي، تجريبي في Gatsby 5، يرطب المكونات الموسومة بـ"use client" فقط ويترك الباقي HTML ثابتًا، فيقلل JavaScript ويحسن TTI وCWV مباشرة. لكن له قيود حقيقية: يعمل في بناء الإنتاج فقط، وما يزال تجريبيًا، ولا يتوافق مع emotion وstyled-components وgatsby-plugin-offline.

الخلاصة: حمولة JavaScript في Gatsby مشكلة أداء لا فهرسة. ما يزال Googlebot يعرض JavaScript لتقييم إشارات تجربة الصفحة، ولذلك قد تضر الحزمة CWV حتى إن فُهرس المحتوى جيدًا.

Gatsby مقابل Astro في SEO

إذا كنت تختار إطارًا ثابتًا اليوم، فهذه أهم مقارنة لـSEO.

يعرض كلاهما HTML قابلًا للفهرسة مسبقًا، فتتعادل هذه النقطة. الفرق ضريبة JavaScript؛ ترسل جزر Astro جزءًا صغيرًا منه. وتصف مقارنة Vaihe ذلك: “Reduced JavaScript execution conserves crawl budget and accelerates page scanning.” (ترجمة) «تقليل تنفيذ JavaScript يحافظ على ميزانية الزحف ويسرع فحص الصفحات». تنبيه تاريخي لصالح Gatsby: كانت معالجة الصور في Astro تفتقر إلى width/height تلقائيًا وقت المقارنة، فتظهر تحذيرات Lighthouse؛ راجع وثائق Astro الحالية لاحتمال معالجة ذلك.

للسياق العام، راجع مركز مولدات المواقع الثابتة.

الحقيقة الصريحة: مسار صيانة Gatsby

لن أجمل الوضع ولن أهوّله.

استحوذت Netlify على Gatsby Inc. في فبراير 2023. أُوقف Gatsby Cloud ونُقل العملاء إلى Netlify، وقالت الشركة إن الاستحواذ «لن يؤثر في Gatsby JS». لكن النشاط تباطأ بوضوح. وترى مناقشة GitHub مجتمعية واسعة القراءة، رقم #39062، أن Gatsby مهجور فعليًا: التزامات قليلة، ولا دعم React 19، وخريطة طريق 2024 غير منفذة، وإيقاف خدمة القياس. ويصف القائمون الوضع بأنه إصلاحات أمنية وتحديثات محدودة للتبعيات وإصلاح أخطاء سهلة.

المعنى لفرق SEO. لا توجد حالة طوارئ في موقع Gatsby قائم؛ فهو يبني ويُفهرس ويعمل. الخطر هو تآكل المنظومة مع الوقت، لأن SEO يعتمد على إضافات الخريطة والصور وcanonical، وقد تنكسر الإضافات القديمة، مثل gatsby-source-shopify مع إهمال API، فتضعف الفهرسة بصمت. أما في مشروع جديد فوازن ذلك جديًا؛ الأطر التي ينتقل إليها الناس هي Astro وNext.js.

قائمة تحقق الإنتاج لكل مسار عرض

لا تثبت جلسة gatsby develop محلية، ولا حتى سجل gatsby build نظيف، ما يتلقاه الزاحف. لأن SSG وDSG وSSR ومسارات العميل تنشئ HTML بطرق مختلفة، افحص كل مسار في الإنتاج بدل افتراض أن صفحة ممثلة تكفي:

• محتوى HTML الخام. اجلب URL إنتاجيًا حقيقيًا لكل مسار عرض مستخدم عبر curl -s <url> أوview-source:، لا DevTools، وتأكد من وجود المحتوى والعنوان ووسوم meta التي سيراها الزاحف.
• بيانات تصدير Head. تأكد من وصول وسوم تصدير Head إلى HTML الخام للمسار المعني. قد توجد الوسوم في الشفرة في جميع الحالات، لكن الجلب الإنتاجي وحده يثبت وصولها إلى الاستجابة عبر DSG أوSSR.
• حالة HTTP. افحص رمز الاستجابة، خصوصًا لمسارات SSR وDSG؛ فقد تفشل الصفحة بالرمز 500 عند أول طلب أو تحت الحمل رغم نجاحها محليًا.
• التخزين المؤقت. SSG ملف ثابت؛ وDSG يخزن بعد أول طلب، فاختبر الطلب الثاني؛ وتتوقف استجابات SSR على الرؤوس والاستضافة، فتحقق من عدم تقديم محتوى قديم أوخاص بمستخدم إلى آخر.
• سلوك الفشل والحالة الفارغة. في صفحات SSR وDSG التي تعتمد بيانات وقت الطلب أو الطلب الأول، افحص ما يراه الزاحف عند فشل جلب البيانات أو عودتها فارغة؛ فحالة الخطأ غير المعالجة ليست الصفحة التي اختبرتها محليًا ببيانات سليمة.
• إنشاء الخريطة والاستثناءات. أكد أن الإنشاء لا يحدث إلا في بناء الإنتاج (gatsby build && gatsby serve، لا gatsby develop)، وأن المسودات والمسارات الخاصة بالعميل وكل ما قررت استبعاده غائب فعلًا عن sitemap-index.xml الناتج، لا عن نيتك فحسب.

لا شيء من ذلك اختياري لكل مسار؛ نجاح gatsby build يثبت ناتج SSG فقط، لا DSG أوSSR أوالمسار الخاص بالعميل.

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

1. الاستمرار في gatsby-plugin-react-helmet بدل الانتقال إلى Head API.
2. ظهور الوسوم في DevTools لا مصدر الصفحة؛ يعمل مكون SEO لدى العميل، فافحص view-source:.
3. المسودات في الخريطة؛ رشحها في gatsby-node.js عبر GraphQL لا داخل React.
4. صفحات يتيمة من src/pages؛ يحول Gatsby كل ملف هناك إلى مسار فتدخل الملفات القديمة الخريطة.
5. وسما canonical بسبب تشغيل gatsby-plugin-canonical-urls وreact-helmet معًا.
6. عدم اتساق الشرطة الختامية لأن توجيه <Link> لدى العميل يتجاوز تحويل الخادم.
7. عدم إزالة استعلامات canonical؛ اضبط stripQueryString: true.
8. غياب alt عن GatsbyImage؛ لا يُنشأ تلقائيًا.
9. إرسال /sitemap.xml بدل /sitemap-index.xml الحقيقي.
10. اختبار الخريطة في gatsby develop؛ لا تُنشأ إلا في gatsby build.
11. تبديل noindex عبر حالة React؛ ربما عالج Google HTML الخام بالفعل، وإذا رأى noindex فيه فقد يتجاوز العرض. أبق قرار noindex في HTML الثابت أو رؤوس الخادم.

لأساسيات عرض JavaScript، راجع مركز JavaScript SEO الأعلى.

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

خلاصة موجزة للنسخة المتقدمة:

• لدى Gatsby أربعة مسارات: SSG وDSG وSSR والمسارات الخاصة بالعميل. يعرض gatsby build صفحات SSG افتراضيًا إلى HTML ثابت، بينما يؤجل DSG التوليد إلى أول طلب وينشئ SSR لكل طلب ولا يظهر محتوى المسار الخاص بالعميل قبل JavaScript. تحقق من HTML الإنتاج لكل مسار؛ يثبت البناء الناجح SSG فقط.
• كلفة حزمة React أداء لا زحف. يرطب Gatsby بيئة React كاملة تتجاوز 200KB فتضغط Core Web Vitals، بعكس مولدات بلا JS؛ يرسل Astro نحو 5KB عبر الجزر.
• استخدم Gatsby Head API منذ v4.19 عبر تصدير Head في الصفحة أوالقالب للعناوين وmeta وcanonical وJSON-LD بدل gatsby-plugin-react-helmet. تعمل في المسارات الأربعة وفي الصفحات والقوالب فقط، وتزيل التكرار حسب id.
• افحص في الإنتاج لكل مسار: HTML الخام وبيانات Head وحالة HTTP والتخزين وسلوك الفشل أوالفراغ، مع الخريطة والاستثناءات.
• الخرائط: تنشئ gatsby-plugin-sitemap ملف sitemap-index.xml في gatsby build فقط؛ أرسل هذا الملف لا /sitemap.xml. تتجاهل Google <priority> و<changefreq>؛ ركز على <lastmod>. رشح المسودات في gatsby-node.js واتخذ قرار إدراج صريحًا لـDSG وSSR ومسارات العميل.
• Canonical: استخدم Head API وlocation.pathname أوgatsby-plugin-canonical-urls مع stripQueryString: true، لا كليهما.
• الصور: تحسن gatsby-plugin-image الأحجام والصيغ والتحميل وتمنع CLS، لكنها لا تكتب alt.
• خطأ DevTools دون view-source يعني عرض مكون SEO لدى العميل.
• مخاطر الصيانة: استحوذت Netlify عام 2023 وتباطأ النشاط؛ المواقع القائمة مستقرة، لكن وازن Astro أوNext.js للمشاريع الجديدة.

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

وثائق مصادر أولية من Gatsby وGoogle.

Gatsby

• خيارات العرض — SSG وDSG وSSR ومسارات العميل.
• استخدام DSG — التوليد عند أول طلب.
• استخدام SSR — ناتج وقت الطلب عبر Gatsby Functions.
• مسارات العميل والمصادقة — غياب محتوى المسار من HTML الأولي.
• إضافة مكون SEO — النمط الموصى به.
• مرجع Gatsby Head API — الإدارة الحديثة لوسوم الرأس.
• تقديم Gatsby Head API — سبب استبدال react-helmet.
• gatsby-plugin-sitemap — خرائط الإنتاج.
• gatsby-plugin-image — StaticImage وGatsbyImage والصيغ ومنع CLS.
• gatsby-plugin-robots-txt — robots.txt الواعي بالبيئة.
• gatsby-plugin-canonical-urls — canonical وstripQueryString.
• gatsby-plugin-react-helmet — النهج القديم.
• gatsby-plugin-next-seo — مكونات JSON-LD جاهزة.
• ترطيب React في Gatsby — تحويل HTML الثابت إلى تفاعلي.

Google

• أساسيات JavaScript SEO — مراحل الزحف ثم العرض ثم الفهرسة وميزة العرض المسبق.

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

تصريحات مسجلة تنطبق على بنية Gatsby. ولأنه SSG يعمل بـJavaScript، فأهم المصادر إرشادات Google للعرض وتصريحات ممثليها.

Google Search Central — أساسيات JavaScript SEO

• “Server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.” (ترجمة) «يظل العرض على الخادم أوالمسبق فكرة ممتازة لأنه يسرع الموقع للمستخدمين والزواحف، وليست كل الروبوتات تشغل JavaScript»؛ وهذا يصف بناء Gatsby.
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (ترجمة) «قد تبقى الصفحة في طابور العرض ثواني، وقد يستغرق الأمر أطول»؛ ويتجاوز HTML المسبق هذا الطابور.

Martin Splitt من Google، مناصر المطورين

• “Even though Googlebot can render JavaScript, we don’t want to rely on that.” (ترجمة) «مع أن Googlebot يستطيع عرض JavaScript، لا نريد الاعتماد على ذلك»؛ وهو مبدأ تفضيل SSG وSSR، وفق تغطية SEJ وBotify.
• “A lot of people are still looking at view source. That is not what we use for indexing. We use the rendered HTML.” (ترجمة) «ما زال كثيرون ينظرون إلى مصدر الصفحة؛ ليس هذا ما نستخدمه للفهرسة، بل HTML المعروض»؛ وهذا يفسر ارتباك خطأ DevTools مقابل view-source، وفق SEJ.
• “The median time in the render queue is only five seconds.” (ترجمة) «الزمن الوسيط في طابور العرض خمس ثوان فقط». لكنه وسيط وقد يكون الذيل أطول كثيرًا، من BrightonSEO وفق SEJ.

John Mueller من Google، مناصر البحث

• “Server-side rendering is not a requirement there. We can render JavaScript-based pages for the most part.” (ترجمة) «العرض على الخادم ليس شرطًا؛ نستطيع غالبًا عرض الصفحات المبنية على JavaScript». أي إن SSR وSSG أفضل ممارسة لا شرطًا مطلقًا، وفق SEJ.

قائمة تحقق Gatsby SEO

مراجعة للتأكد من أن بناء Gatsby ملائم للبحث:

• يظهر المحتوى الأساسي في View Source، أي HTML الخام، لا DevTools فقط.
• تُضبط البيانات الوصفية عبر Gatsby Head API، أي تصدير Head من الصفحات والقوالب، لا react-helmet في العمل الجديد.
• لكل صفحة <title> ووصف فريدان وقت البناء مع قيمة siteMetadata احتياطية.
• يُضبط canonical بآلية واحدة فقط: Head API أوgatsby-plugin-canonical-urls.
• ضُبط stripQueryString: true لمنع تجزئة canonical بسبب الاستعلامات.
• ثُبتت gatsby-plugin-sitemap وفُحص الناتج عبر gatsby build && gatsby serve.
• أرسلت /sitemap-index.xml لا /sitemap.xml إلى Search Console.
• رُشحت المسودات في gatsby-node.js عبر GraphQL قبل دخول الخريطة.
• لا ملفات قديمة أو يتيمة في src/pages تتحول تلقائيًا إلى مسارات.
• يحظر robots.txt معاينات وفروع Netlify ويترك الإنتاج مفتوحًا.
• لكل GatsbyImage وStaticImage نص بديل صريح.
• ملفات JS وCSS غير محظورة في robots.txt.
• حُدد شكل الشرطة المائلة وفُرض لدى المستضيف أوCDN، لا عبر <Link> وحده.
• توجد قرارات noindex في HTML الثابت أو رؤوس الخادم لا حالة React.
• فُحصت Core Web Vitals؛ غالبًا تكون حزمة React موضع الضغط، فانظر في الترطيب الجزئي.
• لكل مسار عرض مستخدم فُحص في الإنتاج HTML الخام والبيانات الوصفية وحالة HTTP والتخزين وسلوك الفشل أوالفراغ، لا مجرد سجل gatsby build محلي.
• لكل من DSG وSSR ومسارات العميل قرار خريطة صريح ومتحقق، لا افتراض SSG نفسه.

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

1. قابلية الزحف والأداء بطاقتان منفصلتان. يتفوق Gatsby في الزحف لأن HTML معروض مسبقًا، ويدفع كلفة أداء بسبب حزمة React. القول إنه سيئ لـSEO لمجرد React يخلط الأمرين؛ يُفهرس المحتوى وتظهر ضريبة JavaScript في Core Web Vitals.

2. كلما وُجد HTML مبكرًا قل ما قد يفشل. يحسم SSG الصفحة وقت البناء، وهو الأكثر أمانًا. صفحة Gatsby الافتراضية SSG، لكن الإطار متعدد الأنماط وقد تكون الصفحة DSG أوSSR أوخاصة بالعميل. اعرف نمط كل مسار قبل وضعه على طيف المخاطر التقريبي: خاص بالعميل ← SSR ← DSG ← SSG، من الأعلى إلى الأقل خطرًا للفهرسة.

3. Head API افتراضيًا، وreact-helmet إرثًا فقط. استخدم Gatsby Head API في كل عمل جديد، وانتقل من react-helmet في القديم. وإذا غاب وسم من HTML الخام، فاسأل هل هو داخل تصدير Head أم عالق في مكون.

4. اختر آلية canonical واحدة تمامًا. إما Head API أوgatsby-plugin-canonical-urls؛ تشغيلهما معًا ينتج وسمين. واتبع مصدر حقيقة واحدًا لكل وسم يكتب في <head>.

5. يبني Gatsby كل ما يجده، لذلك الترشيح مسؤوليتك. لا يحكم على المسودات وملفات src/pages القديمة ونسخ الاستعلامات. إن لم تستبعدها في gatsby-node.js أوإعداد canonical أوالخريطة، فستُنشر وتُزحف.

6. يختلف حساب الصيانة بين مشروع جديد وموقع قائم. أبق موقع Gatsby القائم فهو يعمل. أما المشروع الجديد فليوازن تباطؤ الصيانة وخطر تآكل المنظومة مقابل Astro وNext.js.

ورقة مرجعية لـGatsby SEO

اختيار نهج البيانات الوصفية

الإضافات في لمحة

حقائق سريعة

• ملف الخريطة /sitemap-index.xml لا /sitemap.xml.
• لا تُنشأ الخريطة في gatsby develop؛ استخدم gatsby build && gatsby serve.
• لا تستخدم Google <priority> و<changefreq> في الخريطة؛ اجعل <lastmod> دقيقًا.
• حزمة React نحو 200KB أو أكثر لكل صفحة في الترطيب الكامل؛ كلفة CWV لا زحف.
• يرسل Astro نحو 5KB بالمقارنة عبر الجزر.
• gatsby develop لا يساوي الإنتاج؛ تختلف الخريطة وrobots والتحسينات.
• استحوذت Netlify في فبراير 2023 وتباطأت الصيانة، بلا React 19 حتى الآن.

تصدير SEO عبر Head في سطرين

export const Head = ({ data, location }) => (
  <>
    <title>{data.post.title}</title>
    <link rel="canonical" href={`https://example.com${location.pathname}`} />
  </>
)

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

شغّل هذا بعد gatsby build لا ضد gatsby develop:

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

يكشف السكربت الناتج المفقود أوالمكرر من تداخل Head API والإضافات. راجع القيم وعضوية الخريطة بصورة مستقلة.

أدوات Gatsby SEO

• Gatsby Head API المدمجة منذ v4.19 لإدارة <title> وmeta وcanonical وJSON-LD لكل صفحة أو قالب بلا تبعية.
• gatsby-plugin-sitemap لإنشاء sitemap-index.xml في بناء الإنتاج.
• gatsby-plugin-image لمكونات StaticImage وGatsbyImage والأحجام وWebP/AVIF والتحميل الكسول وعناصر منع CLS.
• gatsby-plugin-canonical-urls لوسوم canonical مع stripQueryString.
• gatsby-plugin-robots-txt لملف robots.txt واع بالبيئة يحظر المعاينات.
• gatsby-plugin-next-seo لمكونات JSON-LD وschema الجاهزة.
• view-source: وفحص URL في GSC للحقيقة بشأن وجود المحتوى والبيانات في HTML الخام، لا DOM المرطب في DevTools.
• Lighthouse وPageSpeed Insights لقياس كلفة حزمة React على Core Web Vitals وجدوى الترطيب الجزئي.
• gatsby build && gatsby serve لاختبار الخريطة وrobots وتحسينات الإنتاج محليًا.

ما لا ينبغي فعله في موقع Gatsby

أخطاء ملموسة يقع فيها من يبني مواقع Gatsby وينشرها؛ الهدف منعها لا تشخيصها.

إبقاء gatsby-plugin-react-helmet في العمل الجديد

الخطأ: استخدام react-helmet بحكم العادة في صفحات أو مشروع جديد لأن الشروحات القديمة ما زالت تعرضه.

سبب الخطأ: يعاني react-helmet مشكلات مع React Hooks والعرض المتزامن وخطأ عنوان التبويب الخلفي الذي يحتاج defer={false}، وهو حزمة خارجية وProvider لم تعد بحاجة إليهما.

البديل: استخدم Gatsby Head API المدمجة منذ v4.19 عبر تصدير Head من الصفحة أوالقالب، واقصر react-helmet على الشفرة القديمة حتى ترحيلها.

تشغيل آليتي canonical معًا

الخطأ: تعيين canonical عبر gatsby-plugin-canonical-urls وبوسم react-helmet أوHead API في الصفحة نفسها.

سبب الخطأ: تعمل الآليتان وتنتج الصفحة وسمَي <link rel="canonical">، فتربك الإشارة المقصودة.

البديل: اختر آلية واحدة للموقع كله، Head API أوالإضافة مع stripQueryString: true، واحذف الأخرى.

ترشيح المسودات داخل React بدل وقت البناء

الخطأ: إخفاء المحتوى غير المنشور بفحص لدى العميل مثل if (!post.published) return null وافتراض خروجه من البحث.

سبب الخطأ: يبني Gatsby كل ما يجده إلى HTML ثابت قبل تشغيل المكون في المتصفح؛ تكون المسودة قد بُنيت وأُدرجت في الخريطة.

البديل: رشح المسودات في gatsby-node.js عبر GraphQL، مثل استبعاد ما لا يحمل تاريخ نشر، كي لا تُبنى ولا تُدرج.

نشر GatsbyImage بلا نص بديل

الخطأ: الثقة بأن gatsby-plugin-image تتولى SEO الصور كاملًا لأنها تنشئ الأحجام والصيغ والعناصر النائبة.

سبب الخطأ: تحسن الإضافة التسليم ولا تكتب alt. لذلك يغيب النص عن GatsbyImage وStaticImage كثيرًا رغم اكتمال بقية التحسينات.

البديل: اجعل alt حقلًا مطلوبًا لكل مكون صورة في كل مرة؛ فهو جانب SEO الصور الذي يتركه Gatsby لك.

افتراض أن gatsby develop يعرض ناتج SEO الإنتاجي

الخطأ: فحص الخريطة أوrobots.txt أوnoindex في gatsby develop واستنتاج وجود عطل لغيابها.

سبب الخطأ: لا تعمل gatsby-plugin-sitemap وسلوكيات وقت البناء الأخرى في وضع التطوير؛ هذا سلوك dev لا خطأ.

البديل: شغّل gatsby build && gatsby serve قبل الحكم على الخريطة أوrobots.txt أوتحسينات الإنتاج.

ترك توجيه <Link> يخفي عدم اتساق الشرطة الختامية

الخطأ: افتراض تطبيق تحويلات الشرطة على الخادم في كل مكان، بما فيه التنقل داخل التطبيق.

سبب الخطأ: يستخدم <Link> واجهة History API ويتجاوز تحويلات 301 الخادمية، فتقدم الروابط الداخلية الصيغة «الخاطئة» بلا المرور بالتحويل.

البديل: اختر صيغة واحدة، وافرضها لدى المستضيف أوCDN، واجعل canonical متسقًا بصرف النظر عن طريقة الوصول.

مشكلات Gatsby SEO الشائعة

مرجع يبدأ من الأعراض للمشكلات التي تراها فعليًا في موقع Gatsby؛ ابدأ بما تلاحظه.

تظهر وسوم meta في DevTools لكنها غائبة عن مصدر الصفحة

العَرَض: تفحص الصفحة في Chrome DevTools فيبدو العنوان ووصف meta صحيحين، لكن view-source: (أو طلب curl خام) يُظهر غيابهما أو يعرض قيمًا عامة.

السبب المرجح: يُعرض مكون SEO لدى العميل؛ إذ استُخدم كمكون عادي لا بوصفه تصدير Head للصفحة (ولا داخله)، فلا يظهر إلا في DOM بعد الترطيب.

الإصلاح: انقل الوسوم إلى تصدير Head المسمى في الصفحة أو القالب. تحقق باستخدام view-source: أو curl -s <url>، لا DevTools الذي يعرض DOM بعد الترطيب وليس ما يراه الزاحف في الجلب الخام.

خريطة الموقع مفقودة أو فارغة

العَرَض: تزور /sitemap-index.xml (أو تفحص Search Console) فلا تجد شيئًا، أو تجد قائمة ناقصة.

السبب المرجح: في الغالب اختبرت في gatsby develop، حيث لا تعمل gatsby-plugin-sitemap أصلًا. وأقل شيوعًا، قد لا تكون الإضافة مثبّتة أو مضبوطة في gatsby-config.js.

الإصلاح: شغّل gatsby build && gatsby serve ثم افحص مجددًا. إن ظلت مفقودة، فتحقق من وجود الإضافة في gatsby-config.js. اطلب /sitemap-index.xml مباشرة للتأكد؛ وتذكر أنه عنوان الفهرس لا /sitemap.xml.

تحمل الصفحة وسمَي canonical

العَرَض: يُظهر مصدر الصفحة (أو تدقيق schema/الوسوم) عنصرَي <link rel="canonical"> في الصفحة نفسها.

السبب المرجح: تعمل gatsby-plugin-canonical-urls ووسم canonical من react-helmet (أو Head API) معًا للصفحة نفسها.

الإصلاح: أزل إحدى الآليتين كي يعيّن مصدر واحد فقط canonical. تحقق مجددًا من المصدر، واستخدم أداة فحص وسم Canonical من Patrick للتأكد من أن وسم canonical واحدًا بالضبط يُحل بصورة صحيحة.

تظهر المسودات أو الصفحات اليتيمة في خريطة الموقع

العَرَض: تسرد خريطة الموقع (أو تقرير التغطية في Search Console) عناوين URL لم تقصد نشرها، مثل تدوينات مسودة أو ملفات قديمة تحت src/pages.

السبب المرجح: يبني Gatsby مسارات تلقائيًا لكل ما يجده؛ فيتحول إدخال GraphQL غير منشور لم تُرشحه، أو ملف متروك في src/pages، إلى صفحة ثابتة حقيقية وتُدرج كغيرها.

الإصلاح: رشح المسودات في gatsby-node.js باستعلام GraphQL، مثل استبعاد الإدخالات التي بلا تاريخ نشر، كي لا تُبنى أصلًا. أما ملفات src/pages اليتيمة فاحذف الملف القديم؛ فالترشيح داخل المكون متأخر لأن الصفحة تكون قد بُنيت.

تُفهرس صيغ الصفحة ذات سلاسل الاستعلام بوصفها نسخًا مكررة

العَرَض: يعرض Search Console عناوين شبه مكررة مثل /blog و/blog?tag=foo مفهرسة معًا، أو يوسمها كمحتوى مكرر.

السبب المرجح: تعمل gatsby-plugin-canonical-urls من دون stripQueryString: true، لذلك تشير صيغة كل سلسلة استعلام إلى نفسها كعنوان canonical بدل العنوان النظيف.

الإصلاح: عيّن stripQueryString: true في ضبط الإضافة، وأعد البناء، ثم أعد فحص وسم canonical في عنوان يحوي سلسلة استعلام؛ ينبغي أن يشير الآن إلى المسار النظيف.

ما زالت صفحة أردت منع فهرستها تظهر في البحث

العَرَض: عيّنت الصفحة إلى noindex، لكنها ظلت مفهرسة بعد أسابيع، أو يعرضها Search Console مفهرسة رغم الوسم.

السبب المرجح: جرى تبديل توجيه noindex عبر حالة React بدل تضمينه في HTML الثابت أو ترويسات الخادم. ربما عالجت Google بالفعل HTML الخام (من دون noindex)، وحين لا ترى noindex إلا في تمريرة يعرضها العميل فقد تتخطى عرض الصفحة مجددًا بالكامل.

الإصلاح: انقل قرار noindex إلى HTML الثابت (عبر تصدير Head وقت البناء) أو إلى ترويسة HTTP، لا منطق React الشرطي. أعد الفحص باستخدام view-source: للتأكد من وجود الوسم في الاستجابة الخام.

اختبر معلوماتك: Gatsby SEO

خمسة أسئلة سريعة عن تحسين موقع Gatsby للبحث. اختر إجابة لكل سؤال ثم تحقق منها.

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

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

• دليل شامل لـ JavaScript SEO — العرض، وتكافؤ DOM، وسبب كون الناتج الثابت أو المسبق العرض (مثل Gatsby) الطرف الأقل مخاطرة في الطيف.
• دليل المبتدئين إلى Technical SEO — موضع معمارية العرض ضمن الصورة الأكبر.

محاضراتي

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

من أرجاء المجال

• مرجع Gatsby Head API — المصدر الأساسي لنهج البيانات الوصفية الحديث.
• تقديم Gatsby Head API — شرح Gatsby نفسه لسبب إحلالها محل react-helmet.
• Google Search Central — أساسيات JavaScript SEO — مراحل الزحف ← العرض ← الفهرسة التي يتيح لك بناء Gatsby تجاوزها للمحتوى.
• انضمام Gatsby إلى Netlify — إعلان الاستحواذ عام 2023، بوصفه سياقًا لحالة الصيانة.
• Netlify تستحوذ على منصة الواجهات الأمامية Gatsby (TechCrunch) — تغطية مستقلة للاستحواذ.
• نقاش «هل تُرك GatsbyJS؟» رقم #39062 — نقاش المجتمع حول حالة صيانة Gatsby الحالية.
• مقارنة SEO بين Gatsby وNext وAstro (Vaihe) — مقارنة حمولة JavaScript وميزانية الزحف.
• فهم الترطيب الجزئي في Gatsby 5 (LogRocket) — تحسين الترطيب المتعلق بـ CWV وحدوده.

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