اللغات

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

كيفية تحسين مواقع Jekyll للبحث — ولماذا يكون HTML الثابت فيها ملائمًا للزواحف افتراضيًا، إلى جانب إضافتي jekyll-seo-tag وjekyll-sitemap، والروابط الدائمة، والمجموعات، وrobots.txt، وقائمة إضافات GitHub Pages المسموح بها.

نُشر أول مرة: 26 يونيو 2026 · آخر تحديث: 22 أغسطس 2026 · Advanced
اللغات
AIمن تأليفAI v2
دليل واحد في هذه الصفحة

يُخرج Jekyll ملفات HTML ثابتة ومسطحة، فتتلقى الزواحف المحتوى كاملًا من أول جلب من دون تأخير لعرض JavaScript. لذلك لا تتمثل مهمة SEO في مقاومة إطار العمل، بل في ضبطه. ثبّت jekyll-seo-tag (للعنوان والوصف والرابط الأساسي وOpen Graph وTwitter Card وJSON-LD) وjekyll-sitemap (لملف sitemap.xml)، واضبط url: في _config.yml وإلا فسيُنتجان مخرجات معطّلة. اختر روابط دائمة نظيفة (/:title/ بدل الروابط المعتمدة على التاريخ) للمحتوى الدائم. وأنشئ robots.txt بنفسك؛ فلن ينشئه Jekyll. وانتبه إلى فخين في GitHub Pages: قائمة الإضافات المسموح بها (لا تعمل من دون بناء عبر GitHub Actions إلا مجموعة ثابتة) وضبط baseurl على نحو خاطئ في مواقع المشاريع، ما يعطّل كل رابط أساسي.

الخلاصة — يُخرج Jekyll ملفات HTML ثابتة ومسطحة وقت البناء، فيوجد المحتوى في الاستجابة الخام عند أول زحف، من دون خدمة عرض الويب أو تأخير الموجة الثانية. يتمثل عمل SEO في الضبط لا في البنية. ثبّت jekyll-seo-tag (العنوان والوصف والرابط الأساسي وOG وTwitter Card وJSON-LD) وjekyll-sitemap (sitemap.xml)؛ وكلتاهما تتطلب url: في _config.yml وإلا أنتجتا مخرجات معطّلة. استخدم روابط دائمة نظيفة (/:title/) بدل المعتمدة على التاريخ للمحتوى الدائم. يهيمن فخان في GitHub Pages: قائمة الإضافات المسموح بها (يبني GitHub باستخدام --safe؛ وتحتاج الإضافات غير المسموح بها إلى بناء عبر GitHub Actions) وغياب baseurl في مواقع المشاريع، وهو ما يعطّل كل رابط أساسي مُنشأ. كما يثبّت GitHub Pages إصدارات محددة من الإضافات (الإصدار 3.10.0 من النواة، وإصدارات أقدم من jekyll-seo-tag وjekyll-sitemap)، لا مجرد تحديد الإضافات التي تعمل. تحتاج المجموعات إلى output: true وإلا فلن تُعرض. وتُستبعد المسودات والمنشورات المؤرخة للمستقبل والمستندات ذات published: false من البناء العادي، كما أن --incremental تجريبي؛ فلا تستخدمه في عمليات النشر الإنتاجية. ولا يُنشأ robots.txt تلقائيًا؛ أنشئه بنفسك.

لماذا يفيد ناتج Jekyll الثابت في SEO

Jekyll مولّد مواقع ثابتة: يمرر قوالب Markdown وLiquid عبر خطوة بناء ويُخرج HTML مكتملًا مرة واحدة قبل أي طلب. وهذا التوقيت هو ميزة SEO بأكملها. Evidence for this claim Jekyll processes text and templates into static files during a build. Scope: Jekyll build architecture. Confidence: high · Verified: Jekyll documentation

يمر مسار Google بالمراحل: الزحف ← العرض ← الفهرسة، ويكون عرض JavaScript “a separate step” (ترجمة) «خطوة منفصلة» تنتظر في طابور؛ وهو ما يسميه الناس على نحو فضفاض عملية «الموجتين». تجلب الموجة الأولى HTML الخام وتفهرس النص والروابط فورًا، بينما تضع الموجة الثانية الصفحة في طابور خدمة عرض الويب لتشغيل JavaScript بعد “a few seconds to weeks” (ترجمة) «بضع ثوانٍ إلى أسابيع»، بحسب ميزانية الزحف. ومع Jekyll، تحتوي الموجة الأولى بالفعل على محتواك كله؛ فلا تلزم JavaScript لعرض المتن. الموجة الأولى = الموجة الثانية. لا تأخير في العرض ولا إنفاق لميزانيته. وهذا هو السبب نفسه الذي يجعل أي مولّد مواقع ثابتة البنية الأقل مخاطرة لقابلية الفهرسة.

وتترتب على ذلك الفوائد التالية:

  • زمن TTFB أسرع. تعني الملفات المبنية مسبقًا والمقدّمة من شبكة CDN (تقع GitHub Pages خلف Fastly، ولدى Netlify وVercel شبكاتهما الطرفية) عدم وجود استعلامات لقواعد البيانات أو معالجة على الخادم؛ وهذا مفيد لـLCP ولسائر مؤشرات أداء الويب الأساسية.
  • لا توجد حمولة JS مطلوبة للمحتوى ← ما يعني FCP وLCP أفضل من تطبيق SPA يعتمد على الإماهة.
  • رموز حالة HTTP صحيحة في طبقة CDN بدل معالجة الأخطاء من جانب العميل.

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

GitHub Pages وتحسين محركات البحث في Jekyll

أكثر طرق نشر Jekyll شيوعًا هي GitHub Pages: ادفع المحتوى إلى فرع مفعّل فيه Pages وسيبني GitHub الموقع تلقائيًا. وتأتي هذه السهولة مع قيود تؤثر في SEO.

مواقع المشاريع مقابل مواقع المستخدمين/المؤسسات — قرار عنوان URL

  • يعيش username.github.io/repo-name (موقع مشروع) على نطاق فرعي مشترك مع آلاف المواقع الأخرى غير المرتبطة. وهو مناسب للوثائق والعروض التوضيحية والمشاريع الشخصية التي لا يحتاج فيها عنوان URL نفسه إلى حمل علامتك التجارية.
  • يضع النطاق المخصص (بتوجيه سجل CNAME إلى GitHub Pages) الموقع على عنوان URL تتحكم فيه، مع توفير GitHub لشهادة HTTPS تلقائيًا. وفي المواقع التي يهم فيها النطاق نفسه، مثل موقع شركة أو مدونة تبني لها جمهورًا، يتجنب استخدام نطاق مخصص من البداية ترحيل النطاق لاحقًا.

إذا كنت تتوقع الانتقال إلى نطاق مخصص في النهاية، فأعدّه مبكرًا. يتطلب أي ترحيل للنطاق عمليات إعادة توجيه 301 (تتولاها jekyll-redirect-from) وفترة تشير فيها الروابط الواردة وأي إشارات متراكمة إلى عنوان URL القديم. ويمكن تجنب هذا الاضطراب باختيار النطاق النهائي مقدمًا بدل تغييره لاحقًا. هذه حجة تتعلق بالتخطيط للترحيل، وليست ادعاءً بأن نطاقًا فرعيًا من github.io يتعرض لعقوبة بذاته.

baseurl — الخطأ الأول في الروابط الأساسية لمواقع المشاريع

تقع مواقع المشاريع تحت مجلد فرعي (/repo-name/). وإذا لم تضبط baseurl: /repo-name في _config.yml، فسيكون كل رابط أساسي تنشئه jekyll-seo-tag — وكذلك روابطك الداخلية — خاطئًا لأنه يفتقد المجلد الفرعي. وهذا أكثر أخطاء الروابط الأساسية شيوعًا في مواقع مشاريع Jekyll. أما مواقع المستخدمين/المؤسسات المقدّمة من جذر النطاق فلا تحتاج إلى baseurl.

قائمة الإضافات المسموح بها

يشغّل GitHub Pages برنامج Jekyll بالراية --safe ولا يسمح إلا بمجموعة ثابتة من الإضافات. Evidence for this claim GitHub Pages builds Jekyll in safe mode and supports a documented set of plugins. Scope: GitHub Pages hosted builds. Confidence: high · Verified: GitHub Pages: Jekyll plugins ومن الإضافات المسموح بها ذات الصلة بـSEO:

  • jekyll-seo-tag ✓
  • jekyll-sitemap ✓
  • jekyll-redirect-from ✓ (لعمليات إعادة التوجيه 301s عند تغيير عناوين URL)
  • jekyll-paginate ✓

الإضافات غير المسموح بها (ولن تعمل بصمت أو ستُظهر خطأ):

  • jekyll-last-modified-at — مطلوبة للحصول على <lastmod> دقيق في خريطة الموقع من الطوابع الزمنية للملفات
  • إضافات البيانات المنظّمة المخصصة
  • أي شيء يوضع في مجلد _plugins/

المسألة ليست الإضافات المسموح بها فحسب، بل إصداراتها أيضًا

لا يقيّد GitHub Pages الإضافات التي تعمل فحسب؛ بل يثبّت الإصدار الدقيق من كل إضافة، كما تُثبّت بيئة البناء نفسها على إصدار أقدم من Jekyll. واعتبارًا من آخر تحديث لـقائمة التبعيات، يشغّل البناء المستضاف Jekyll 3.10.0 مع jekyll-seo-tag 2.8.0 وjekyll-sitemap 1.4.0 وjekyll-feed 0.17.0، بينما تصف وثائق jekyllrb.com الإصدار الحالي في المنبع، 4.4.1. ولا يُضمن وجود سلوك موثّق في أحدث README لإضافة ما في الإصدار الذي يشغّله GitHub Pages فعليًا؛ لذا راجع pages.github.com/versions.json لمعرفة الإصدار المثبّت قبل الاعتماد على راية أو مخرج بعينه. ويتجاوز البناء عبر GitHub Actions هذا القيد أيضًا؛ إذ تتحكم في Gemfile وتحصل على الإصدارات التي تثبّتها بدل مجموعة GitHub المثبّتة.

الحل البديل عبر GitHub Actions

ليس حل قائمة السماح «إضافة المزيد من حزم gem»، بل إيقاف تولّي GitHub للبناء. شغّل Jekyll بنفسك في CI (actions/jekyll-build-pages، أو ابنِ محليًا وادفع _site/ إلى فرع النشر باستخدام peaceiris/actions-gh-pages)، وعندها لا تعود قائمة السماح سارية. ويمكنك تشغيل أي إضافة واختيار إصدارات Jekyll والإضافات بدل وراثة المجموعة التي يثبّتها GitHub.

إضافة jekyll-seo-tag

هذه هي الإضافة الرسمية التي يجري صيانتها وتغطي معظم البيانات الوصفية الأساسية التي لا يضيفها Jekyll بنفسه. وتعتمد مخرجاتها الدقيقة على الإصدار المثبّت وملف _config.yml والبيانات الأمامية، وعلى ما إذا كان قالب التخطيط يستدعي {% seo %} فعلًا؛ فمثلًا يثبّت GitHub Pages إصدارًا محددًا بدل تقديم أحدث إصدار دائمًا، كما سيتضح أدناه. راجع دليل الاستخدام المتقدم لمعرفة المخرجات الدقيقة لإصدارك، وتحقق مما وصل فعلًا بالبحث في HTML المبني لديك بدل افتراض اكتماله.

التثبيت:

# Gemfile
gem 'jekyll-seo-tag'
# _config.yml
plugins:
  - jekyll-seo-tag
<!-- _layouts/default.html, before </head> -->
{% seo %}

ما تنشئه تلقائيًا:

  • <title> — عنوان الصفحة ملحقًا به اسم الموقع (Page Title | Site Name)
  • <meta name="description"> — من البيانات الأمامية description: أو وصف الموقع
  • <link rel="canonical"> — مبني من site.url + page.url
  • وسوم Open Graph (og:title وog:description وog:url وog:site_name وog:image)
  • وسوم Twitter Card (twitter:card وtwitter:title وtwitter:description وtwitter:creator وtwitter:image)
  • بيانات JSON-LD منظّمة (BlogPosting للمنشورات وWebSite للصفحة الرئيسية)
  • بيانات تعريف ترقيم الصفحات (عناوين URL التالية/السابقة)

إعدادات _config.yml المطلوبة — من دونها تنتج الإضافة مخرجات معطّلة:

title: Your Site Title
description: Your site description
url: "https://yourdomain.com"   # CRITICAL — drives canonical URL generation
author:
  name: Patrick Stox
  twitter: patrickstox
  url: https://patrickstox.com  # author disambiguation
twitter:
  username: patrickstox
  card: summary_large_image

تجاوزات البيانات الأمامية لكل صفحة:

---
title: "Jekyll SEO Guide"
description: "How to optimize Jekyll sites for search engines."
image:
  path: /assets/jekyll-seo-og.png
  width: 1200
  height: 630
  alt: "Jekyll SEO diagram"
canonical_url: "https://example.com/jekyll-seo/"  # override if needed
robots: noindex   # per-page noindex
seo:
  type: BlogPosting          # schema.org type override
  date_modified: 2025-01-15  # dateModified override for JSON-LD
---

التعطيل (عندما يُخرج قالب التخطيط لديك وسومه الخاصة بالفعل):

{% seo title=false %}      <!-- suppress the <title> -->
{% seo canonical=false %}  <!-- suppress the canonical link -->

هناك فخ يستحق التنبيه: تأتي كثير من القوالب البسيطة (ومنها minima) من دون توصيل jekyll-seo-tag. ولا تؤدي إضافة الحزمة إلى Gemfile أي شيء ما لم يستدعِ قالب التخطيط الخاص بالسمة {% seo %} فعلًا.

خرائط المواقع باستخدام jekyll-sitemap

نمط التثبيت نفسه (Gemfile + _config.yml). وتُنشئ الإضافة ملف sitemap.xml متوافقًا مع sitemaps.org في المسار /sitemap.xml عند كل بناء.

تتطلب url: في _config.yml؛ فمن دونه لا تحتوي إدخالات خريطة الموقع على نطاق.

التحكم في <lastmod> حسب ترتيب الأولوية:

  1. last_modified_at: في البيانات الأمامية (الأفضل؛ تحكم صريح)
  2. تاريخ إنشاء المنشور (الخيار الاحتياطي؛ وكثيرًا ما يكون خاطئًا للمحتوى الدائم الذي حُدّث لاحقًا)
  3. تاريخ تعديل نظام الملفات (يحتاج إلى jekyll-last-modified-at غير المسموح بها)

أفضل ممارسة: أضف last_modified_at: YYYY-MM-DD إلى كل منشور وحدّثه عند تحديث المحتوى؛ فهذه إشارة الحداثة التي يستند إليها تحديد أولوية إعادة الزحف.

استبعاد الصفحات:

# Per-page front matter
sitemap: false

# Global pattern (in _config.yml)
defaults:
  - scope:
      path: "assets/**/*.pdf"
    values:
      sitemap: false

إعداد الروابط الدائمة

تُضبط الروابط الدائمة على مستوى الموقع في _config.yml أو تُتجاوز لكل صفحة في بياناتها الأمامية.

النمطالقالبملاحظات SEO
date (الافتراضي)/:categories/:year/:month/:day/:title.htmlمثقل بالتاريخ وهش إذا تغير تاريخ المنشور
pretty/:categories/:year/:month/:day/:title/شرطة مائلة ختامية من دون .html
none/:categories/:title.htmlلا يدفن المحتوى تحت التاريخ
مخصص/:title/ أو /:categories/:title/أكبر قدر من التحكم؛ موصى به للمحتوى الدائم

الموصى به لمعظم المواقع:

permalink: /:title/
# or
permalink: /:categories/:title/

لماذا تتجنب عناوين URL المعتمدة على التاريخ للمحتوى الدائم:

  • يؤدي تغيير date: في البيانات الأمامية للمنشور إلى تغيير عنوان URL ← فتتعطل الروابط الواردة.
  • يدفن التسلسل العميق (/2019/03/14/post-title/) المحتوى بلا سبب.
  • (تكون عناوين URL المؤرخة مناسبة ومتوقعة للأخبار والصحافة؛ فهذا قرار يعتمد على السياق وليس قاعدة عامة.)

تحتاج المجموعات إلى إعداد خاص بها للروابط الدائمة:

collections:
  case_studies:
    output: true
    permalink: /case-studies/:name/

تحذير عند تغيير الأنماط: بعد فهرسة عناوين URL، يتطلب تبديل أنماط الروابط الدائمة عمليات إعادة توجيه 301 (استخدم jekyll-redirect-from). وإذا تخطيت عمليات إعادة التوجيه، أهدرت قيمة الروابط وأنشأت أخطاء 404s في Search Console.

المجموعات وSEO

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

  1. يجب ضبط output: true. فمن دونه لا تُعرض مستندات المجموعة أبدًا في صورة ملفات HTML منفردة، ولذلك لا يمكن فهرستها. وهذا قاتل صامت للفهرسة؛ فالمحتوى موجود في المستودع لكنه لا يصبح صفحة قابلة للزحف.

    collections:
  docs:
    output: true          # REQUIRED for indexable pages
    permalink: /docs/:name/

  2. يحتاج كل مستند إلى بيانات أمامية، حتى لو كانت كتلة --- فارغة. ومن دونها يتعامل Jekyll مع الملف على أنه ملف ثابت ثنائي: لا معالجة لـLiquid ولا بيانات وصفية ولا تكامل مع jekyll-seo-tag.

لاحظ أن المجموعات لا تدخل في خلاصات RSS (فالخلاصات تشمل المنشورات وحدها). وعادةً ما تكون المجموعات البنية المناسبة لمواقع الوثائق الكبيرة رغم ذلك.

حالات النشر وعمليات البناء التزايدية

لدى Jekyll عدة مفاتيح مستقلة تتحكم فيما ينتهي فعليًا في الموقع المبني. ويؤدي الخلط بينها إما إلى صفحات لا تُبنى بصمت، أو إلى شحن محتوى مسودة/مستقبلي إلى الإنتاج عن طريق الخطأ:

  • تُستبعد المسودات (_drafts/) بالكامل من البناء العادي. ولا تظهر إلا عند تشغيل bundle exec jekyll serve --drafts (أو build --drafts) محليًا؛ فنقل منشور إلى _posts/ مع تاريخ حقيقي هو ما ينشره فعليًا.
  • تُستبعد المنشورات المؤرخة للمستقبل (ذات date: اللاحق للوقت الحالي) افتراضيًا. ويؤدي future: true في _config.yml أو الراية --future إلى تضمينها؛ وهو أمر مفيد للمعاينة المحلية، لكن إبقاءه مفعّلًا في إعداد الإنتاج يعني أن المنشورات المجدولة تصبح حية لحظة البناء لا في تاريخها المقصود.
  • تستبعد published: false في البيانات الأمامية المستند من البناء بصرف النظر عن تاريخه؛ وهي مفتاح منفصل عن المسودات والمنشورات المستقبلية، ومن السهل نسيانه بعد اختبار صفحة كنت تنوي شحنها.
  • توثّق Jekyll إعادة التوليد التزايدية (--incremental) بوصفها تجريبية، وهي تتتبع رسم تبعيات محدودًا، ولا سيما التضمينات وقوالب التخطيط. وقد تصبح صفحة تمر على site.posts أو بيانات مجموعات أخرى (فهرس وسوم أو أرشيف أو منطق منشورات ذات صلة) قديمة تحت --incremental من دون أن يكتشف Jekyll تغير المنشورات الأساسية. لا تشغّلها ضمن نشر إنتاجي؛ بل استخدم bundle exec jekyll build كاملًا لأي شيء تدفعه إلى الموقع الحي.

قبل الوثوق بأي من ذلك، ابنِ الموقع من دون الرايات التي تستخدمها محليًا (--drafts و--future و--incremental)، وتأكد أن الناتج في _site/ يطابق ما تنوي نشره؛ فالخيار الافتراضي الأكثر أمانًا لمسار النشر هو بناء نظيف وكامل وغير تزايدي.

أجزاء الرأس المخصصة باستخدام Liquid

عندما لا تكفي jekyll-seo-tag، أنشئ ملف _includes/head.html الخاص بك:

<head>
  <meta charset="UTF-8">
  <title>
    {% if page.title %}{{ page.title }} | {{ site.title }}
    {% else %}{{ site.title }}{% endif %}
  </title>
  <meta name="description" content="
    {%- if page.description -%}{{ page.description }}
    {%- elsif page.excerpt -%}{{ page.excerpt | strip_html | strip_newlines }}
    {%- else -%}{{ site.description }}
    {%- endif -%}">
  <link rel="canonical" href="{{ page.url | prepend: site.url }}">
  {% seo %}
</head>

مرشحات Liquid الأساسية لـSEO:

  • | strip_html — يزيل الوسوم من المقتطف التلقائي (ضروري للأوصاف النظيفة)
  • | strip_newlines — يزيل فواصل الأسطر من المقتطفات
  • | truncate: 160 — حد اختياري لعدد الأحرف من جانب القالب، وليس حدًا تفرضه Google. فضّل وصفًا مؤلفًا ومخصصًا للصفحة وعاين المقتطف المعروض؛ إذ يختلف مدى ملاءمته حسب طلب البحث والجهاز واللغة ونظام الكتابة.
  • | prepend: site.url — يبني عناوين URL مطلقة للروابط الأساسية ووسوم OG
  • | date_to_xmlschema — تواريخ ISO 8601 لحقلي datePublished وdateModified في JSON-LD
  • | default: fallback — قيمة احتياطية عندما يكون المتغير nil

بيانات JSON-LD مخصصة تتجاوز ما تُخرجه jekyll-seo-tag:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": {{ page.title | jsonify }},
  "datePublished": "{{ page.date | date_to_xmlschema }}",
  "dateModified": "{{ page.last_modified_at | default: page.date | date_to_xmlschema }}",
  "author": {
    "@type": "Person",
    "name": "{{ page.author.name | default: site.author.name }}",
    "url": "{{ page.author.url | default: site.author.url }}"
  }
}
</script>

لا يُنشأ robots.txt تلقائيًا

لا ينشئ Jekyll ملف robots.txt. عليك إنشاؤه بنفسك في جذر الموقع. ضمّن كتلة بيانات أمامية فارغة كي يعالج Liquid الملف (وبذلك تُحل {{ site.url }}):

---
---
User-agent: *
Allow: /

Sitemap: {{ site.url }}/sitemap.xml

من دون ذلك، لا توجد إشارة إلى خريطة الموقع في robots.txt، وبعض الزواحف تستخدمها آليةً للاكتشاف. (يتحكم robots.txt في الزحف لا الفهرسة؛ وللصورة الكاملة راجع الزحف.)

خرافات شائعة عن SEO في Jekyll

«يتولى Jekyll تحسين محركات البحث تلقائيًا». الناتج الثابت ملائم للزواحف، لكن البيانات الوصفية تحتاج إلى إعداد صريح. وكثيرًا ما تأتي القوالب الافتراضية من دون أي وسوم SEO.

«GitHub Pages مناسب لـSEO؛ فهو مجاني». GitHub Pages نفسه مناسب؛ فالناتج الثابت ملائم للزواحف بصرف النظر عن المضيف. وتتمثل المحاذير في قائمة الإضافات المسموح بها (والإصدارات المحددة التي تثبّتها، لا مجرد أسماء الإضافات)، وكذلك في اختيار نطاق مخصص قبل بناء جمهور على github.io إذا كانت علامتك التجارية تعتمد على عنوان URL.

«المواقع الثابتة لا تحتاج إلى خرائط مواقع». تستطيع Google العثور على الصفحات عبر الروابط، لكن خريطة الموقع تسرّع اكتشافها وتحمل إشارات <lastmod>. وتجعل jekyll-sitemap ذلك أمرًا بسيطًا.

«Jekyll ميت». إنه في وضع صيانة ناضج؛ فقد صدر الإصدار v4.4.1 في يناير 2025. توجد ميزات جديدة قليلة، لكنه يخضع للصيانة ويظل آمنًا، وستدعمه GitHub Pages إلى أجل غير مسمى. وهو خيار راسخ وممل بالمعنى الجيد للمدونات والوثائق البسيطة.

«يمكنني استخدام أي إضافة على GitHub Pages». لا؛ فهناك --safe وقائمة سماح ثابتة. والحل هو GitHub Actions، لا المزيد من حزم gem.

موقع Jekyll ضمن الصورة الأوسع

Jekyll واحد من المولّدات الستة في مجموعة مولّدات المواقع الثابتة؛ وهو الخيار الافتراضي في GitHub Pages وأول مولّد يقابله معظم المطورين. وللسياق الأوسع حول كيفية عرض Google لـJavaScript ومتى تحتاج إليها فعلًا، راجع مركز SEO لـJavaScript. كما ينطبق على Jekyll انضباط حداثة البناء الذي يسري على كل مولّد مواقع ثابتة: لا يكون الموقع الثابت أحدث من آخر عملية بناء له، ولا تصل التعديلات إلى محركات البحث حتى تعيد البناء والنشر.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.