مولدات المواقع الثابتة

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

ما مولد المواقع الثابتة؟

تعود معظم مشكلات تحسين محركات البحث المرتبطة بـ JavaScript إلى سؤال واحد: هل محتواك موجود فعلًا في الصفحة عندما يجلبها الزاحف، أم لا يظهر إلا بعد تشغيل البرامج النصية؟ يتجاوز مولد المواقع الثابتة (SSG) هذا السؤال تمامًا.

يأخذ مولد SSG محتواك (الذي يُكتب عادةً بصيغة Markdown) وقوالبك، ثم يحول — على جهازك أو خادم البناء — كل صفحة إلى ملف HTML مكتمل قبل أن يزورها أحد. بعد ذلك ترفع ملفات HTML العادية إلى مضيف. وعندما يطلب Google أو Bing أو قارئ صفحةً ما، يحصل عليها كاملة من المحاولة الأولى. دليل على هذا الادعاء A static site generator builds source content and templates into static files before requests are served. النطاق: Hugo as a representative static site generator. مستوى الثقة: مرتفع · تم التحقق: 2026-07-14 Hugo documentation

قارن ذلك بتطبيق JavaScript نموذجي، حيث يرسل الخادم غلافًا شبه فارغ ثم يبني المتصفح الصفحة لاحقًا. مع مولد SSG لا يوجد ما يجب بناؤه في المتصفح؛ فقد اكتمل البناء بالفعل.

لماذا يعد ذلك ممتازًا لتحسين محركات البحث؟

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

أشهر المولدات

هناك ستة أسماء ستسمع بها غالبًا: Hugo وJekyll وEleventy وHexo وGatsby وAstro. كلها تنتج HTML ثابتًا، لكنها تختلف في لغة بنائها ومقدار JavaScript الإضافي الذي ترسله إلى المتصفح، إن أرسلته أصلًا. وستجد في أسفل هذه الصفحة رابطًا إلى دليل مفصل لكل منها.

الشيء الوحيد الذي ينبغي مراقبته

الموقع الثابت هو لقطة. فهو يعرض ما كان صحيحًا في آخر مرة بنيته فيها. إذا غيّرت سعرًا أو صححت خطأً مطبعيًا أو نشرت تدوينة ثم نسيت إعادة البناء والنشر، فستظل محركات البحث ترى النسخة القديمة. لذلك يتمثل الانضباط الأساسي مع مولد SSG في ضمان أن تؤدي التغييرات إلى بناء جديد. دليل على هذا الادعاء Changes to a statically generated site require a new build and deployment before the generated output changes. النطاق: Astro static builds as a representative SSG workflow. مستوى الثقة: مرتفع · تم التحقق: 2026-07-14 Astro: Deploy your site

هل تريد النسخة التقنية: كيف تختلف مولدات SSG عن أطر جهة العميل والأطر الوصفية، ومقارنة جنبًا إلى جنب بين المولدات الستة، وفخ حداثة البناء بالتفصيل؟ انتقل إلى علامة تبويب متقدم.

الخلاصة — يعرض مولد SSG كل مسار مسبقًا في صورة HTML ثابتة وقت البناء، لذا يكون المحتوى موجودًا في الاستجابة قبل أول طلب من الزاحف، من دون Web Rendering Service أو طابور عرض أو تأخير «Wave 2». وهذه أكبر ميزة منفردة لقابلية الفهرسة يمكنك منحها لموقع. تختلف مولدات SSG عن أطر CSR (التي تبني الصفحة في المتصفح) وعن الأطر الوصفية (التي يمكنها تنفيذ SSR لكل طلب). وتنتج المولدات الستة في هذه المجموعة — Hugo وJekyll وEleventy وHexo و Gatsby وAstro — جميعها HTML ثابتًا، لكنها تختلف في اللغة وحمولة JS وأدوات خرائط الموقع والصور المدمجة. نمط الفشل الحقيقي ليس العرض بل حداثة البناء: فالموقع الثابت لا يكون أحدث من آخر بناء له، ولذلك فإن المحتوى المتغير الذي لا يؤدي إلى إعادة بناء يقدّم بصمت HTML قديمًا إلى محركات البحث. أشغّل هذا الموقع على Astro لهذه المفاضلات تحديدًا.

ما معنى «ثابت» فعليًا؟

يشغّل مولد المواقع الثابتة محتواك وقوالبك خلال خطوة بناء، ويُخرج مجلدًا من ملفات HTML وCSS والأصول المكتملة. والجزء الحاسم لتحسين محركات البحث هو متى يُنتج HTML: وقت البناء، مرة واحدة، للجميع — لا مع كل طلب ولا داخل المتصفح. تصف إرشادات Google بشأن JavaScript الزحف والعرض والفهرسة باعتبارها مراحل معالجة منفصلة. يزيل مولد SSG العرض من جهة العميل من المسار الحرج للمحتوى الذي ينشئه لأن HTML مكتمل بالفعل. دليل على هذا الادعاء Google processes JavaScript through crawling, rendering, and indexing, while pre-rendered HTML is present before client execution. النطاق: Google Search JavaScript processing; indexing is not guaranteed. مستوى الثقة: مرتفع · تم التحقق: 2026-07-14 Google: JavaScript SEO basics

لهذا تعد المواقع الثابتة أكثر البنى أمانًا للوصول إلى الفهرس. فالمحتوى موجود منذ أول بايت في الاستجابة. لا توجد فجوة تطابق بين HTML الخام والمعروض، ولا اعتماد على نجاح العارض، ولا غرائب Chrome عديم الحالة تحتاج إلى مراعاتها في التصميم.

SSG مقابل العرض من جهة العميل مقابل الأطر الوصفية

ثلاث بنى، وثلاث لحظات مختلفة يظهر فيها HTML إلى الوجود:

• توليد الموقع الثابت (SSG). يُبنى HTML مرة واحدة وقت البناء، قبل أي طلب، ويُقدَّم كملفات ثابتة (غالبًا من CDN). المحتوى موجود في HTML الخام. وينطبق ذلك على Hugo وJekyll وEleventy وHexo، وكذلك Gatsby وAstro في وضعهما الثابت الافتراضي.
• العرض من جهة العميل (CSR). يرسل الخادم غلافًا بسيطًا، ثم تبني JavaScript الصفحة في المتصفح وقت الطلب/التشغيل. يعتمد المحتوى على نجاح العرض. وهذا هو وضع React أو Vue SPA الافتراضي المعتمد على CSR، وهو الإعداد الأكثر خطورة لتحسين محركات البحث (راجع JavaScript SEO).
• الأطر الوصفية (SSR / الهجينة). تستطيع أطر مثل Next.js وNuxt وSvelteKit عرض HTML على الخادم لكل طلب (SSR)، أو عرض بعض المسارات مسبقًا (SSG)، أو المزج بينهما. يكون المحتوى في HTML، لكنه يُنتج وقت الطلب، ما يضيف تكلفة خادم وزمن انتقال لا يوجدان مع مولد SSG خالص.

تتداخل الحدود عند الأطراف؛ إذ يُسمّى Gatsby وAstro أحيانًا أطرًا وصفية لأنهما يعتمدان على المكونات ويمكنهما فعل أكثر من إخراج ملفات ثابتة. لكنهما في وضعهما الأساسي مولدان ثابتان، وهكذا ينبغي التعامل معهما لتحسين محركات البحث. النموذج الذهني المهم هو: كلما وُجد HTML أبكر، قل ما يمكن أن يفسد قبل أن يراه الزاحف. وSSG هو الأبكر.

مقارنة المولدات الستة

تنتج المولدات الستة جميعها HTML ثابتًا قابلًا للفهرسة. وإليك اختلافاتها وفق المحاور التي تؤثر فعلًا في قرار تحسين محركات البحث:

بعض النقاط الجديرة باستخلاصها من الجدول:

• حمولة JS هي عامل التمييز المجاور لتحسين محركات البحث. لا يرسل Hugo وJekyll وEleventy و Hexo أي JavaScript تقريبًا ما لم تضفه. أما Gatsby فيعيد تهيئة حزمة React كاملة على العميل؛ ويظل قابلًا للفهرسة لأن HTML ثابت، لكنه يضيف تكلفة إلى Core Web Vitals لا توجد لدى الآخرين. ويوازن Astro بين الطرفين عبر بنية الجزر: HTML ثابت افتراضيًا، وJavaScript للمكونات التفاعلية المحددة («الجزر») التي تحتاج إليه فقط.
• تختلف سرعة البناء مع التوسع. يشتهر Hugo (Go) بسرعته ويتعامل بسهولة مع عشرات الآلاف من الصفحات. أما المولدات القائمة على Node فأبطأ على النطاق الكبير، وكانت أزمنة بناء Gatsby تاريخيًا أكبر شكاواه.
• حُلّت مسألة خرائط الموقع وتحسين الصور في معظم المولدات، لكن Hugo و Astro يقدمان أكثر قدر من الوظائف مباشرة، بينما يعتمد Jekyll وEleventy وHexo على إضافات جيدة الصيانة.
• تباطأت وتيرة إصدارات Gatsby بوضوح. المشروع غير مؤرشف وما زال يصدر تصحيحات، لكن مستودع GitHub الخاص به حتى يوليو 2026 يعرض عددًا قليلًا فقط من الالتزامات خلال الأيام التسعين السابقة وإصدارًا فرعيًا واحدًا منذ فبراير. يستحق ذلك الموازنة مع خيار أكثر نشاطًا في التطوير إذا كنت تختار مولدًا اليوم، إضافةً إلى تكلفة hydration/CWV أعلاه.

لماذا بنيت هذا الموقع باستخدام Astro؟

بنيت هذا الموقع — وكذلك patrickstox.com — باستخدام Astro، والمنطق ينبع مباشرةً من هذه الصفحة. أردت التأليف باستخدام Markdown/MDX ومكونات حقيقية، لكنني لم أرد دفع ضريبة JavaScript على كل صفحة لمجرد الحصول عليها. الوضع الافتراضي في Astro هو صفر JS من جهة العميل: الصفحات التي تقرؤها تُرسل كـ HTML ثابت، ولا تُحمّل JavaScript إلا للقطع التفاعلية القليلة (مثل علامات تبويب العدسات والاختبار). يمنحني ذلك قابلية فهرسة مولد SSG كلاسيكيًا ومؤشرات Core Web Vitals جيدة، من دون التخلي عن تجربة تأليف قائمة على المكونات. لو كنت أحتاج سرعة بناء فائقة لمجموعة محتوى ضخمة بلا أي تفاعل، لكان Hugo الخيار الواضح؛ ولطبقة بيانات React، Gatsby. أما لهذا الموقع — موقع كثيف المحتوى مع بعض اللمسات التفاعلية — فإن Astro هو المفاضلة الصحيحة.

المأخذ الحقيقي الوحيد: حداثة البناء

كل ما سبق مزايا. وهذه هي العقبة التي توقع الناس في المشكلات.

الموقع الثابت لا يكون أحدث من آخر بناء له. فـ HTML لقطة مجمّدة وقت البناء. غيّر سعرًا أو صحح حقيقة أو انشر تدوينة أو حدّث وسم عنوان، ولن يصل شيء من ذلك إلى محركات البحث حتى تعيد البناء والنشر. لا يوجد خادم حي يجمع الصفحة من قاعدة بيانات عند كل طلب، ولذلك لا يوجد ما يلتقط تغييرك تلقائيًا. دليل على هذا الادعاء Static build output remains a snapshot until the project is rebuilt and redeployed. النطاق: Astro static build workflow as a representative example. مستوى الثقة: مرتفع · تم التحقق: 2026-07-14 Astro: Build and deploy

يعني هذا عمليًا ما يلي:

• يجب أن تؤدي تعديلات المحتوى إلى بناء. إذا كنت تؤلف في CMS بلا واجهة أو Git، فاربط webhook بحيث يبدأ النشر عملية نشر جديدة. عملية البناء اليدوية فقط هي الطريقة التي تتسلل بها الأسعار القديمة وأخطاء 404 «الشبحية» إلى الفهرس.
• البيانات كثيرة التغير محرجة. المخزون والأسعار والأعداد الحية: إذا كانت تتغير أسرع من وتيرة بنائك، تتأخر النسخة الثابتة. وهنا تبرر عمليات البناء التزايدية أو المجدولة أو النهج الهجين (إطار وصفي مع SSR/ISR للمسارات المتقلبة) وجودها.
• الصفحات الحساسة للوقت تحتاج وتيرة محددة. إذا كانت «عروض اليوم» مدمجة وقت البناء، فيجب تشغيل البناء يوميًا على الأقل، وإلا كانت الصفحة مضللة.

لا يمثل أي من ذلك عائقًا حاسمًا، بل هو مسألة انضباط. فالسبب نفسه الذي يجعل مولدات SSG ممتازة لتحسين محركات البحث (تحديد HTML مسبقًا) هو ما يفرض عليك أن تتعمد إعادة تحديده عند تغير المحتوى.

أين تذهب بعد ذلك: مجموعة مولدات المواقع الثابتة

هذا المركز هو الخريطة. لكل مولد أدناه دليل متعمق مستقل يغطي اللغة وحمولة JS وأدوات خرائط الموقع والصور ومشكلات تحسين محركات البحث الخاصة بالإطار وكيفية إبقاء عمليات البناء حديثة:

• Hugo SEO — يعمل بـ Go، بلا JS، وبناء فائق السرعة؛ خريطة الموقع المنشأة تلقائيًا، ومعالجة الصور المدمجة، وإدارة مجموعات المحتوى الضخمة.
• Jekyll SEO — مولد SSG الأصلي وخيار GitHub Pages الافتراضي؛ jekyll-seo-tag وjekyll-sitemap وقيد الإضافات على GitHub Pages.
• Eleventy (11ty) SEO — قائم على JavaScript ومخرجاته بلا JS؛ إنشاء خرائط الموقع من القوالب وeleventy-img للصور المتجاوبة.
• Hexo SEO — مولد مدونات Node؛ إضافات خريطة الموقع والخلاصات وJS الخاص بالقالب ونظافة الروابط الدائمة/canonical.
• Gatsby SEO — توليد ثابت قائم على React؛ مفاضلة hydration/CWV، وgatsby-plugin-image وgatsby-plugin-sitemap ومصادر البيانات وقت البناء.
• Astro SEO — بلا JS افتراضيًا، بنية الجزر، @astrojs/sitemap، وastro:assets وView Transitions وسلوك الرجوع إلى Server Islands.

كل موضوع أعلاه متداخل ضمن هذا المركز ويظهر أيضًا في الشريط الجانبي.

للسياق الأوسع — كيف يعرض Google JavaScript، وأنماط فشل التطابق والتفاعل، وأي وضع عرض تختار عندما تحتاج إلى JS — راجع مركز JavaScript SEO الأصل.

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

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

• يعرض مولد SSG كل صفحة مسبقًا في صورة HTML ثابتة وقت البناء — يكون المحتوى موجودًا في الاستجابة قبل أول طلب من الزاحف. لا Web Rendering Service ولا طابور عرض ولا تأخير «Wave 2». إنها البنية الأكثر أمانًا لقابلية الفهرسة.
• ثلاث بنى بحسب وقت وجود HTML: SSG (وقت البناء، الأكثر أمانًا)، وCSR (في المتصفح وقت التشغيل، الأكثر خطورة)، والأطر الوصفية/SSR (لكل طلب على الخادم؛ المحتوى موجود لكن مع زمن انتقال/تكلفة).
• ترسل المولدات الستة جميعًا HTML ثابتًا قابلًا للفهرسة. وتختلف في اللغة وحمولة JS وأدوات خرائط الموقع والصور المدمجة:
  • Hugo (Go) — صفر JS، أسرع عمليات البناء، خريطة موقع ومعالجة صور مدمجتان.
  • Jekyll (Ruby) — صفر JS، الخيار الافتراضي لـ GitHub Pages، ويعتمد على الإضافات.
  • Eleventy (Node) — صفر JS، مرن، ويعتمد على الإضافات.
  • Hexo (Node) — صفر JS افتراضيًا، يركز على المدونات، ويعتمد على الإضافات.
  • Gatsby (React) — ينفذ hydration لحزمة React (بتكلفة على CWV)، وأدوات صور قوية، لكن وتيرة إصداراته تباطأت بوضوح حتى منتصف 2026.
  • Astro (أي إطار) — صفر JS افتراضيًا عبر الجزر، وخريطة موقع رسمية وastro:assets.
• حمولة JS هي عامل التمييز المجاور لتحسين محركات البحث — يحمل Gatsby حزمة React؛ ويرسل Astro عبر الجزر JS حيث يلزم فقط؛ أما البقية فبلا JS.
• بنى Patrick هذا الموقع (وكذلك patrickstox.com) على Astro — مكونات من دون ضريبة JS: HTML ثابت + مؤشرات Core Web Vitals جيدة.
• المأخذ الحقيقي الوحيد هو حداثة البناء: فالموقع الثابت لا يكون أحدث من آخر بناء له. اربط تعديلات المحتوى بـ webhook لإعادة البناء، واستخدم بناءً تزايديًا/مجدولًا أو مسار SSR/ISR هجينًا للبيانات سريعة التغير.

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

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

محركات البحث — العرض وHTML الثابت

• فهم أساسيات تحسين JavaScript لمحركات البحث — مراحل الزحف ← العرض ← الفهرسة التي يتيح لك البناء الثابت تجاوزها للمحتوى.
• دليل معمق لكيفية عمل بحث Google — موضع العرض ولماذا يعد HTML المعروض مسبقًا الخيار الأقل خطورة.

المولدات

• وثائق Hugo — إلى جانب وثائق قالب خريطة الموقع ومعالجة الصور.
• وثائق Jekyll — بالإضافة إلى jekyll-seo-tag وjekyll-sitemap.
• وثائق Eleventy (11ty) — وeleventy-img.
• وثائق Hexo — وإضافة hexo-generator-sitemap.
• وثائق Gatsby — وgatsby-plugin-image وgatsby-plugin-sitemap.
• وثائق Astro — إلى جانب @astrojs/sitemap وastro:assets / الصور.

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

تصريحات موثقة من Google ومن فرق المولدات نفسها، إضافة إلى ملاحظة من كتاباتي.

Google — العرض خطوة منفصلة

• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome.” (الترجمة العربية) «أثناء الزحف، يعرض Google الصفحة ويشغّل أي JavaScript يعثر عليه باستخدام إصدار حديث من Chrome». — هذه هي الخطوة التي يزيلها مولد SSG من المسار الحرج عندما يرسل HTML مكتملًا. انتقل إلى الاقتباس
• “Rendering is important because websites often rely on JavaScript to bring content to the page, and without rendering Google might not see that content.” (الترجمة العربية) «العرض مهم لأن مواقع الويب تعتمد غالبًا على JavaScript لإحضار المحتوى إلى الصفحة، ومن دون العرض قد لا يرى Google ذلك المحتوى». — إذا كان المحتوى موجودًا بالفعل في HTML الثابت، فلن يتسبب العرض في فقدان ظهوره. انتقل إلى الاقتباس

Astro — ثابت افتراضيًا

• “By default, Astro pages, routes, and API endpoints will be pre-rendered at build time as static pages. However, you can choose to render some or all of your routes on demand by a server when a route is requested.” (الترجمة العربية) «افتراضيًا، تُعرض صفحات Astro ومساراته ونقاط نهاية API مسبقًا وقت البناء كصفحات ثابتة. ومع ذلك، يمكنك اختيار عرض بعض مساراتك أو كلها عند الطلب بواسطة خادم حين يُطلب المسار». انتقل إلى الاقتباس

Hugo — السرعة

• يصف Hugo نفسه بأنه “the world’s fastest framework for building websites” (الترجمة العربية) «أسرع إطار في العالم لبناء مواقع الويب» — وهي ميزة سرعة البناء المهمة عند اتساع نطاق المحتوى. المصدر

Patrick Stox (من عملي — JavaScript SEO: A Definitive Guide)

• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines.” (الترجمة العربية) «أي إعداد يعتمد SSR أو العرض الثابت أو العرض المسبق سيكون مناسبًا لمحركات البحث» — يقع التوليد الثابت في الطرف منخفض المخاطر من هذا الطيف.

قائمة تحقق لتحسين المواقع الثابتة لمحركات البحث

مراجعة سريعة للتأكد من أن إعداد مولد SSG ملائم للبحث ويظل حديثًا:

• المحتوى المهم موجود في عرض المصدر (HTML الخام)، وليس فقط بعد تشغيل JS — فهذا هو جوهر مولد SSG.
• تُنشأ خريطة موقع XML في كل بناء وتُرسل إلى Google Search Console وBing Webmaster Tools.
• لكل صفحة <title> فريد ووصف تعريفي يُنشآن وقت البناء (عبر قوالب المولد أو إضافة/تكامل لتحسين محركات البحث).
• وسوم canonical مضبوطة وتشير إلى عناوين URL النهائية الحية (لا إلى localhost أو نطاق معاينة).
• تُحسَّن الصور وقت البناء (أحجام متجاوبة وصيغ حديثة) باستخدام أدوات المولد المدمجة أو إضافة صور.
• أي JavaScript من جهة العميل (حزمة React في Gatsby، أو جزر Astro، أو JS القالب) لا يخفي المحتوى الأساسي خلف تفاعل.
• أصول JS/CSS غير محظورة في robots.txt.
• تؤدي تعديلات المحتوى إلى إعادة البناء والنشر — يشغّل webhook من CMS/Git عملية النشر تلقائيًا.
• للصفحات الحساسة للوقت أو كثيرة التغير وتيرة إعادة بناء مجدولة (أو تُقدَّم عبر SSR/ISR بدلًا من العرض الثابت).
• لا تُترك عناوين URL القديمة من بناء سابق كملفات ثابتة يتيمة؛ نظّف مجلد الإخراج/تعامل مع الحذف بحيث تعيد الصفحات المحذوفة 404 أو 410.
• يطابق البناء المنشور أحدث محتوى (افحص عينة من صفحة تغيرت حديثًا في الإنتاج، لا محليًا فقط).

مولدات المواقع الثابتة — ورقة مرجعية سريعة

المولدات الستة في لمحة

متى يوجد HTML (ولماذا يهم ذلك)

حقائق سريعة

• SSG = لا Web Rendering Service في المسار الحرج ← لا تأخير «Wave 2» للمحتوى.
• ينفذ Gatsby hydration لحزمة React (بتكلفة على CWV)، بينما يرسل Astro JS للجزر فقط؛ ويكون Hugo/Jekyll/Eleventy/Hexo بلا JS افتراضيًا.
• تباطأت وتيرة إصدارات Gatsby حتى منتصف 2026؛ افحص نشاطه على GitHub قبل أن تراهن عليه في بناء جديد.
• Hugo (Go) بطل السرعة على النطاق الكبير.
• الفخ الوحيد: حداثة البناء — يعرض الموقع الثابت آخر بناء له. اربط تعديلات المحتوى بـ webhook لإعادة البناء.
• البيانات سريعة التغير (الأسعار والمخزون) ← بناء تزايدي/مجدول أو نهج هجين SSR/ISR.

أي مسار عرض يناسبك؟

إطار البناء ← النشر ← التحقق

• البناء: احصر المسارات المقصودة وأنشئ HTML مكتملًا والبيانات الوصفية ووسوم canonical والبيانات المنظمة.
• النشر: انشر الأثر الجديد ذريًا بحيث يظل HTML والأصول وخرائط الموقع وعمليات إعادة التوجيه متزامنة.
• التحقق: قارن HTML المصدر واستجابة الإنتاج بإصدار المحتوى الذي أدى إلى البناء.

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

تحقّق مما إذا كان المحتوى الأساسي موجودًا في HTML المصدر

curl -sS https://example.com/page/ | grep -F 'Expected visible heading'

بالنسبة إلى قائمة عناوين URL، اجعل CI يفشل عندما يكون مسار إنتاج مفقودًا أو بلا عنوان:

while IFS= read -r url; do html=$(curl -fsSL "$url") || { echo "FETCH FAIL $url"; continue; }; printf '%s' "$html" | grep -qi '<title>[^<]' || echo "TITLE FAIL $url"; done < urls.txt

شغّل هذا في DevTools Console لمقارنة عنوان الصفحة المعروضة ووسم canonical والعنوان الرئيسي:

({title: document.title, canonical: document.querySelector('link[rel="canonical"]')?.href, h1: document.querySelector('h1')?.textContent.trim()});

أدوات للمخرجات الثابتة

• تعرض أداة Raw vs. Rendered HTML Checker ما إذا كان المحتوى المهم وإشارات الرأس موجودة بالفعل في HTML الأولي.
• تفحص أداة HTTP Status Checker المسارات المنشأة وعمليات إعادة التوجيه والصفحات المفقودة على دفعات.
• تفحص أداة HTTP Header Checker رؤوس التخزين المؤقت والنشر عبر عمليات إعادة التوجيه.
• سجل بناء الإطار وبيان النشر هما مصدر الحقيقة بشأن المسارات التي أُنشئت بنجاح.

أثبت أن النشر الثابت يعمل

اختبار HTML المصدر

الاختبار: اجلب عناوين URL تمثيلية من الإنتاج باستخدام curl أو Render Gap. النتيجة المتوقعة: يظهر المحتوى الأساسي والعنوان ووسم canonical والروابط في HTML الخام. تفسير الفشل: يُعرض المسار من جهة العميل أو أغفل البناء البيانات. نافذة المراقبة: فور النشر. مشغّل التراجع: ترسل القوالب المهمة HTML مصدرًا فارغًا أو غير مكتمل.

اختبار حداثة النشر

الاختبار: انشر تغييرًا مضبوطًا في المحتوى وقارن طابعه الزمني في CMS بسجل البناء وأثر النشر وHTML الحي. النتيجة المتوقعة: يؤدي التغيير إلى بناء ناجح واحد ويصل إلى الإنتاج. تفسير الفشل: سلسلة webhook أو البناء أو ذاكرة التخزين المؤقت أو النشر قديمة. نافذة المراقبة: اتفاقية مستوى خدمة النشر المعتادة. مشغّل التراجع: يمزج الإنتاج HTML قديمًا ببيانات وصفية أو أصول جديدة.

اختبار اكتمال المسارات

الاختبار: قارن عناوين URL الأساسية المقصودة بالمسارات المنشأة/المنشورة وافحص الحالات على دفعات. النتيجة المتوقعة: يعيد كل مسار مقصود حالته المخطط لها. تفسير الفشل: أغفل اكتشاف المسار الديناميكي أو إعداد البناء بعض المسارات. نافذة المراقبة: كل بناء. مشغّل التراجع: تصبح الصفحات الأساسية أخطاء 404 أو تعيد التوجيه على نحو غير متوقع.

اختبر نفسك: مولدات المواقع الثابتة

خمسة أسئلة سريعة عن سبب كون مولدات المواقع الثابتة الوضع السهل لتحسين محركات البحث، والشيء الوحيد الذي لا يزال قادرًا على إرباكك. اختر إجابة لكل سؤال ثم تحقّق.

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

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

• JavaScript SEO: A Definitive Guide — العرض وتطابق DOM ولماذا تقع المخرجات الثابتة/المعروضة مسبقًا في الطرف منخفض المخاطر من الطيف.
• The Beginner’s Guide to Technical SEO — موضع بنية العرض في الصورة الأوسع.

محاضراتي

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

من مصادر المجال

• web.dev — Rendering on the Web — شرح فريق Chrome المرجعي لـ SSG مقابل SSR مقابل CSR والمفاضلات بينها.
• Google Search Central — أساسيات تحسين JavaScript لمحركات البحث — مراحل الزحف ← العرض ← الفهرسة التي يتيح البناء الثابت تجاوزها للمحتوى.
• Jamstack — الحركة المعمارية (ترميز معروض مسبقًا يُقدَّم من CDN) التي تمثل مولدات المواقع الثابتة محركها، مع دليل للمولدات.
• Astro — لماذا Astro؟ — أوضح بيان لنموذج «HTML ثابت، صفر JS افتراضيًا، وجزر للتفاعل».
• Hugo — المولد القائم على Go والمصمم حول سرعة البناء على نطاق محتوى كبير.
• Smashing Magazine — تغطية مولدات المواقع الثابتة — مقالات عملية عن اختيار مولدات SSG واستخدامها.

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