فهرس خرائط الموقع

الخلاصة — فهرس خرائط الموقع هو خريطة لخرائط الموقع. لا تتسع خريطة واحدة لأكثر من 50 000 عنوان URL، لذلك توزع المواقع الكبيرة عناوينها على خرائط عدة ثم تسردها في ملف «فهرس» صغير واحد. ترسل الفهرس وحده، فتتبعه محركات البحث إلى البقية.

ما فهرس خرائط الموقع؟

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

تقدم الفهرس لمحركات البحث، فتقرأه للعثور على كل خريطة يشير إليها، ثم تقرأ كل خريطة للعثور على عناوينك. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

لماذا تحتاج إليه؟

للخريطة الواحدة حدود صارمة: 50 000 عنوان URL كحد أقصى، وحجم لا يتجاوز 50 MB من دون ضغط. عندما يزيد عدد العناوين أو يكبر الملف، يجب تقسيمه إلى خرائط عدة. ويربط الفهرس هذه الأجزاء كي ترسل شيئاً واحداً فقط.

ولا يلزم انتظار بلوغ الحد. تستخدم مواقع كبيرة كثيرة الفهرس للتنظيم فحسب: خريطة للمدونة، وأخرى للمنتجات، وأخرى لكل لغة، حتى لو كان كل جزء دون 50 000 عنوان بكثير.

كم يغطي؟

الكثير. يستطيع الفهرس سرد 50 000 خريطة فرعية، وتضم كل واحدة 50 000 عنوان. أي إن فهرساً واحداً يغطي 2,5 مليار عنوان URL. مهما بلغ حجم موقعك فلن تنفد السعة.

كيف تستخدمه؟

• وزع عناوين URL على ملفات خرائط عدة؛ تنفذ معظم إضافات وأطر SEO ذلك تلقائياً.
• ضع في الأعلى ملف فهرس يسرد كل هذه الخرائط.
• أرسل الفهرس وحده في Google Search Console وBing Webmaster Tools؛ فهذا الإرسال الواحد يشمل جميع الخرائط الفرعية.

لرؤية البنية والحدود الدقيقة وقاعدة عدم تضمين فهرس داخل فهرس وحيلة التقسيم التي تحول الخرائط إلى أداة تشخيص للفهرسة، انتقل إلى تبويب متقدم.

الخلاصة — فهرس خرائط الموقع ملف <sitemapindex> يسرد عناصر <sitemap> (وسم <loc> مع <lastmod> اختياري) بدلاً من عناوين الصفحات. تحتاج إليه بعد 50 000 عنوان أو 50 MB غير مضغوطة، أو لتنظيم موقع كبير متعدد الأقسام أو المناطق. يمكنه الإشارة إلى 50 000 خريطة × 50 000 عنوان = 2,5 مليار عنوان لكل فهرس؛ ومع 500 فهرس لكل موقع في Search Console يبلغ السقف النظري 1,25 تريليون. تبقى الخرائط الفرعية على الموقع نفسه وفي مستوى الدليل نفسه أو أدنى، ولا يوضع فهرس داخل فهرس، ويُرسل الفهرس وحده. والفائدة الأهم هي التقسيم حسب القسم أو نوع المحتوى لقراءة المرسَل في مقابل المفهرس لكل شريحة.

ما ملف فهرس خرائط الموقع فعلياً؟

هو خريطة تكون عناصرها خرائط أخرى. تلف الخريطة العادية كتل <url> داخل <urlset>، بينما يلف الفهرس كتل <sitemap> داخل <sitemapindex>. وفي كل <sitemap> وسم <loc> يشير إلى ملف خريطة، ووسم <lastmod> اختياري. هذه هي البنية كلها؛ لا يحمل الفهرس عناوين صفحات بنفسه. Evidence for this claim A sitemap index contains sitemap entries with a required loc value and an optional lastmod value. Scope: Sitemaps.org protocol structure for sitemap index files. Confidence: high · Verified: 2026-07-14 Sitemaps.org: Sitemap index XML tag definitions

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

متى تحتاج إليه؟

هناك سببان:

1. بلوغ حدود الحجم. تتوقف الخريطة الواحدة عند 50 000 عنوان أو 50 MB غير مضغوطة، أيهما أولاً. وتقول Google: “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (ترجمة) إذا تجاوزت خريطة موقعك حدود الحجم، فستحتاج إلى تقسيمها إلى خرائط عدة. Evidence for this claim A sitemap index can list up to 50,000 sitemap files, and each sitemap is limited to 50,000 URLs or 50 MB uncompressed. Scope: Google-supported sitemap and sitemap-index limits. Confidence: high · Verified: 2026-07-14 Google Search Central: Manage sitemaps with a sitemap index file وبعد التقسيم يجمعها الفهرس.
2. تنظيم موقع كبير حتى لو كان دون الحد. يسهل إدارة المواقع متعددة الأقسام أو المناطق أو اللغات ومراقبتها عندما تكون لكل جزء خريطة تحت فهرس واحد. وهذه، في رأيي، فائدة أفضل من انتظار الحد، وسأعود إليها في تبويب الأطر.

البنية

الفهرس صغير وبسيط عمداً: <sitemapindex> ثم كتلة <sitemap> لكل خريطة فرعية، وبداخلها <loc> و<lastmod> اختياري:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap1.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap2.xml.gz</loc>
    <lastmod>2024-08-15</lastmod>
  </sitemap>
</sitemapindex>

ملاحظات مهمة:

• مساحة الأسماء هي sitemaps.org/schemas/sitemap/0.9 نفسها؛ الملف UTF-8 وقيم <loc> عناوين URL مطلقة مكتملة.
• يمكن ضغط الخرائط الفرعية بـgzip؛ صيغة .xml.gz صالحة، ويقاس حد 50 MB على الحجم غير المضغوط.
• يصف <lastmod> الاختياري متى تغيرت الخريطة الفرعية، لا صفحاتها المفردة.

كم فهرساً يمكنك إرساله، وكم صفحة يغطي؟

هنا يقلل الناس تقدير السقف. اجمع الحدود:

• تقبل Google Search Console حتى 500 ملف فهرس لكل موقع: “You can submit up to 500 sitemap index files for each site in your Search Console account.” (ترجمة) يمكنك إرسال ما يصل إلى 500 ملف فهرس لكل موقع في حساب Search Console.
• يسرد كل فهرس حتى 50 000 خريطة فرعية.
• تضم كل خريطة فرعية حتى 50 000 عنوان URL.

والناتج أن السقف النظري 500 × 50 000 × 50 000 = 1,25 تريليون عنوان URL (1 250 000 000 000). إنه سقف لا يقترب منه موقع حقيقي، لا هدفاً. بل إن فهرساً واحداً يغطي 50 000 × 50 000 = 2,5 مليار عنوان. إذا كان لديك هذا العدد من العناوين القابلة للفهرسة، فإعداد الخرائط ليس مشكلتك.

قواعد الموقع

يجب أن تكون الخرائط الفرعية على الموقع نفسه، وفي مستوى الدليل نفسه أو أدنى. يمكن لفهرس عند https://www.example.com/sitemap-index.xml الإشارة إلى https://www.example.com/sitemaps/products.xml، لا إلى مضيف آخر أو مسار أعلى. وإلا تعرض Search Console عبارة “URL not allowed”. ولا تصلح الإحالات عبر النطاقات إلا إذا كان النطاقان موثقين في Search Console، وهو غير لازم لموقع واحد عادي.

لا تضع فهرساً داخل فهرس

يسرد الفهرس خرائط لا فهارس أخرى. لا تنص صفحة بروتوكول sitemaps.org الحالية ولا وثائق Google على ذلك حرفياً. لكن البروتوكول يعرّف <loc> داخل <sitemapindex> بأنه يحدد “a Sitemap, an Atom file, RSS file or a simple text file”؛ وليس الفهرس ضمن القائمة، ولا يوجد وسم للتداخل. لذلك تتعامل مولدات الخرائط والإضافات ومحركات البحث مع فهرس الفهارس على أنه غير مدعوم. اعتبرها قاعدة صارمة: مستوى واحد فقط. وإذا رغبت في فهرس فهارس، فأعد تنظيم التقسيم داخل سعة 2,5 مليار عنوان للفهرس الواحد.

أرسل الفهرس وحده

أرسل ملف الفهرس، فيجلب هذا الإرسال كل خريطة فرعية يشير إليها. قال John Mueller: “You can submit the individual ones, but you don’t really need to.” (ترجمة) يمكنك إرسال الخرائط المفردة، لكنك لا تحتاج إلى ذلك فعلياً. إرسال الفهرس والخرائط معاً غير ضار لكنه زائد؛ الإرسال النظيف للفهرس وحده يكفي.

ومع ذلك، إرسال الخريطة وسيلة اكتشاف لا ضمان فهرسة. يساعد الفهرس المحركات على العثور على خرائطك، لكنه لا يضمن زحفها إلى العناوين أو فهرستها.

استراتيجية التقسيم: للتقارير لا لكفاءة الزحف

لا يغير تقسيم الخرائط طريقة زحف Google أو فهرستها. سبب التقسيم المدروس هو المراقبة. يقول Mueller: “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (ترجمة) أوصي بتقسيم الخريطة إلى أجزاء منطقية لمراقبتها منفردة؛ فهذا لا يغير الزحف أو الفهرسة، وإنما يتيح لك تتبعها بصورة أفضل.

الفائدة العملية أن تقرير Sitemaps في Search Console يعرض المرسَل في مقابل المفهرس لكل خريطة. قسم حسب القسم أو نوع المحتوى أو المنطقة، فترى الشريحة ضعيفة الفهرسة بدلاً من رقم واحد للموقع كله. ولهذا أبقي خريطة للعناوين القديمة أثناء الترحيل، كي أراقب خروج تلك المجموعة من فهرس Google.

إذن قسم بحسب ما تريد قياسه، لا وفق منفعة زحف متخيلة. منفعة التقارير حقيقية.

علاقته ببقية عائلة الخرائط

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

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

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

• فهرس الخرائط خريطة لخرائط الموقع: ملف <sitemapindex> يسرد عناصر <sitemap> (<loc> و<lastmod> اختياري)، لا عناوين الصفحات.
• موعد استخدامه: عندما تبلغ الخريطة 50 000 عنوان أو 50 MB بلا ضغط، وكذلك عندما تريد ترتيب محتوى موقع واسع ذي أقسام أو مناطق متعددة.
• السعة شبه غير محدودة: 50 000 خريطة فرعية × 50 000 عنوان = 2,5 مليار عنوان لكل فهرس؛ ومع 500 فهرس لكل موقع يبلغ السقف النظري 1,25 تريليون.
• القواعد: تبقى الخرائط على الموقع نفسه وفي مستوى الدليل نفسه أو أدنى؛ لا تضع فهرساً داخل فهرس؛ ويمكن ضغط الخرائط الفرعية (.xml.gz).
• أرسل الفهرس وحده؛ فهو يشمل جميع الخرائط، وإرسالها أيضاً زائد لا ضار.
• التقسيم للتقارير لا لكفاءة الزحف. قسم حسب القسم أو نوع المحتوى لتقرأ المرسَل في مقابل المفهرس لكل شريحة في تقرير Sitemaps.

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

وثائق المصادر الأولية لملفات الفهرس والحدود التي تحكمها.

Google

• إدارة الخرائط الكبيرة بملف فهرس — التقسيم والتنسيق وحد 500 فهرس لكل موقع.
• إنشاء خريطة موقع وإرسالها — حد 50 000 عنوان و50 MB غير مضغوطة وUTF-8 والعناوين المطلقة.
• نظرة عامة على الخرائط — الخريطة وسيلة اكتشاف وليست ضمان فهرسة.

sitemaps.org

• بروتوكول XML للخرائط — المواصفة الأساسية لتنسيق <sitemapindex> وحد 50 000 خريطة و50 MB.

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

تصريحات موثقة من Google وبروتوكول sitemaps.org. يقفز كل رابط إلى النص المقتبس.

Google: حدود التقسيم والإرسال

• “If you have a sitemap that exceeds the size limits, you’ll need to split up your large sitemap into multiple sitemaps.” (ترجمة) إذا تجاوزت خريطة موقعك حدود الحجم، فستحتاج إلى تقسيمها إلى خرائط عدة. — Google، إدارة الخرائط الكبيرة. الانتقال إلى الاقتباس
• “You can submit up to 500 sitemap index files for each site in your Search Console account.” (ترجمة) يمكنك إرسال ما يصل إلى 500 ملف فهرس لكل موقع في حساب Search Console. الانتقال إلى الاقتباس

sitemaps.org: حدود حجم البروتوكول (راجع الحاشية لإسناد قاعدة عدم التداخل)

• “Sitemap index files may not list more than 50,000 Sitemaps and must be no larger than 50MB (52,428,800 bytes) and can be compressed.” (ترجمة) لا يجوز أن تسرد ملفات الفهرس أكثر من 50 000 خريطة أو تتجاوز 50 MB، ويمكن ضغطها. — بروتوكول sitemaps.org. الانتقال إلى الاقتباس

John Mueller من Google: التقسيم للمراقبة وإرسال الفهرس وحده

• “I generally recommend splitting a sitemap file into logical parts of your site so that you can monitor those parts individually (eg, category pages vs detail pages…). … It doesn’t change how Google crawls & indexes them, it’s really just so that you can track them better on your side.” (ترجمة) أوصي بتقسيم الخريطة إلى أجزاء منطقية لمراقبتها منفردة؛ لا يغير ذلك الزحف أو الفهرسة، بل يحسن تتبعك. الانتقال إلى الاقتباس
• “You can submit the individual ones, but you don’t really need to.” (ترجمة) يمكنك إرسال الخرائط المفردة، لكنك لا تحتاج إلى ذلك فعلياً. الانتقال إلى الاقتباس

ورقة غش لحدود فهرس الخرائط

الأرقام التي تحدد السعة

حقائق سريعة

• يسرد الفهرس خرائط الموقع لا عناوين URL؛ يلف <sitemapindex> كتل <sitemap> التي تضم <loc> و<lastmod> اختياري.
• يصبح ضرورياً عندما تبلغ الخريطة 50 000 عنوان أو 50 MB، ويفيد أيضاً في تنظيم موقع متعدد الأقسام.
• يجب أن تكون الخرائط على الموقع نفسه وفي مستوى الدليل نفسه أو أدنى.
• يمكن ضغط الخرائط الفرعية (.xml.gz).
• لا تضع فهرساً داخل فهرس؛ لا وسم له ولا تدعمه المولدات أو المحركات.
• أرسل الفهرس وحده؛ إرسال الخرائط أيضاً زائد.
• قسم حسب القسم أو نوع المحتوى للتقارير لا لكفاءة الزحف.

كيف تقسم فهرس الخرائط: قسم وفق ما تقيسه

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

التقسيم حسب نوع المحتوى

• /sitemaps/blog.xml, /sitemaps/products.xml, /sitemaps/categories.xml, /sitemaps/docs.xml.
• يناسب القوالب ذات سلوك الفهرسة المختلف؛ فسترى القالب الذي يسبب المشكلة بدقة.

التقسيم حسب القسم

• خريطة فرعية لكل قسم أو مجلد فرعي رئيسي.
• يناسب المواقع الكبيرة ذات فرق مسؤولة عن أقسام مختلفة؛ فيحصل كل مسؤول على رقم واضح.

التقسيم حسب المنطقة أو اللغة

• خريطة لكل لغة (/sitemaps/en.xml و/sitemaps/de.xml وغيرها).
• يناسب المواقع الدولية؛ إذ يكشف لغة كاملة لا تُفهرس بمعزل عن مشكلات hreflang.

قاعدة القرار

• اسأل: «إذا كانت هذه الشريحة ضعيفة الفهرسة، فهل أريد رؤيتها منفردة؟» إن كان الجواب نعم فذلك حد تقسيم. وإلا فلا تنشئ ملفات إضافية بلا فائدة.

استخدام أعتمد عليه في الترحيل

• أبقي خريطة للعناوين القديمة في الفهرس مدة، لا لفهرستها بل لمراقبة خروجها من فهرس Google في GSC مع حلول العناوين الجديدة محلها.

منفعة كفاءة الزحف التي يتوقعها الناس غير حقيقية؛ منفعة التقارير حقيقية وتستحق تصميم الفهرس حولها.

فهرس صالح بأقل بنية

هذه هي بنية الملف كاملة: جذر <sitemapindex>، ثم كتلة <sitemap> لكل خريطة فرعية، وفيها <loc> و<lastmod> اختياري. يمكن ضغط الخرائط بـgzip (.xml.gz)؛ ويقاس حد 50 MB من دون ضغط.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/blog.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/products.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/categories.xml.gz</loc>
    <lastmod>2026-06-22</lastmod>
  </sitemap>
</sitemapindex>

القواعد المطبقة في المثال:

• الجذر <sitemapindex> لا <urlset> ضمن مساحة الأسماء sitemaps.org/schemas/sitemap/0.9، والملف UTF-8.
• كل <loc> عنوان مطلق مكتمل على الموقع نفسه وفي مستوى الدليل نفسه أو أدنى.
• <lastmod> اختياري ويصف وقت تغير الخريطة الفرعية.
• لا تضف عنصراً يشير إلى فهرس آخر؛ مستوى واحد فقط.

طريقة الإرسال

أرسل ملف الفهرس وحده؛ فتتبعه المحركات إلى كل خريطة فرعية، ولا حاجة إلى إرسال الخرائط منفردة.

# robots.txt — point engines at the index (the Sitemap: line takes the index URL)
Sitemap: https://www.example.com/sitemap-index.xml

ثم أضف عنوان الفهرس نفسه في Google Search Console ضمن تقرير Sitemaps وفي Bing Webmaster Tools. وستتبع الخرائط الفرعية تلقائياً.

أدوات إنشاء فهرس الخرائط وفحصه

• Google Index Checker — لفحص عينة من عناوين خريطة فرعية والتأكد من وصولها إلى فهرس Google بدلاً من انتظار الرقم الإجمالي.
• تقرير Sitemaps في Google Search Console — المكان الأساسي لمراقبة حالة جلب كل خريطة وأعداد المرسَل في مقابل المفهرس لكل شريحة.
• Sitemaps في Bing Webmaster Tools — التقرير المكافئ لدى Bing؛ أرسل إليه عنوان الفهرس نفسه.
• مولد الخرائط أو إضافة CMS — تنشئ معظم الأطر والإضافات الفهرس والخرائط تلقائياً مع نمو عدد العناوين؛ وXML اليدوي مفيد لفهم البنية أو إنشائها بنفسك.

قائمة فحص قبل إرسال فهرس الخرائط

راجعها قبل توجيه Search Console أو Bing Webmaster Tools إلى فهرس جديد أو معاد التنظيم:

• كل خريطة فرعية دون 50 000 عنوان و50 MB غير مضغوطة مع هامش أمان.
• يسرد الفهرس خرائط موقع فقط، ولا يسرد فهرساً آخر.
• كل <loc> فرعي على الموقع نفسه وفي مستوى الدليل نفسه أو أدنى.
• الفهرس والخرائط XML صالح بترميز UTF-8 والجذر الصحيح: <sitemapindex> للفهرس و<urlset> لكل خريطة.
• يحتوي robots.txt سطر Sitemap: يشير إلى الفهرس لا خريطة فرعية.
• توافق حدود التقسيم شيئاً تريد مراقبته منفرداً، لا تقسيماً اعتباطياً.
• الفهرس وحده في قائمة الإرسال؛ لا حاجة إلى إرسال كل خريطة منفردة.

أخطاء ينبغي تجنبها في فهرس الخرائط

• تضمين فهرس داخل فهرس. لا يتيح <loc> ذلك، ولا تدعمه المولدات أو المحركات. أبق مستوى واحداً وأعد تنظيم التقسيم داخل سعة 2,5 مليار عنوان.
• إرسال كل خريطة فرعية إضافة إلى الفهرس. ليس ضاراً لكنه زائد؛ أرسل الفهرس وحده في Search Console وBing Webmaster Tools.
• التقسيم أملاً في تحسين ميزانية الزحف أو الترتيب. التقسيم لا يغير الزحف أو الفهرسة؛ قسم للتقارير وفق الشرائح التي تريد مراقبتها.
• الإشارة إلى مضيف أو نطاق فرعي آخر أو دليل أعلى. تعرض Search Console عبارة “URL not allowed”؛ أبق الخرائط على الموقع نفسه وفي المستوى نفسه أو أدنى.
• ترك الخريطة تتجاوز 50 000 عنوان أو 50 MB. قسم القسم استباقياً قبل بلوغ الحد.

مشكلات فهرس الخرائط الشائعة

العَرَض: تعرض Search Console عبارة “Couldn’t fetch” للفهرس. السبب المرجح: يعيد عنوان الفهرس 404 أو تنتهي مهلته أو يحجبه robots.txt. الإصلاح: افتح العنوان نفسه في المتصفح أو Sitemap Validator وتأكد من أنه يعيد 200 مع XML صالح قبل إعادة الإرسال.

العَرَض: يُجلب الفهرس بنجاح لكن خريطة فرعية محددة تعرض خطأ. السبب المرجح: يشير <loc> إلى عنوان 404 أو غير أساسي أو في نطاق خاطئ، أو XML للخريطة مشوه. الإصلاح: افتح الخريطة وافحص عناصر <loc> وأصلح الملف أو أعد توليده.

العَرَض: «لا يمكن لملف فهرس خرائط الموقع الإشارة إلى فهرس آخر» أو تجاهل العنصر بصمت. السبب المرجح: وضعت فهرساً داخل فهرس، وهو غير مدعوم ولا يتيح له <loc> حكماً. الإصلاح: سوّ البنية إلى مستوى واحد يشير مباشرة إلى خرائط العناوين.

العَرَض: “URL not allowed” على خريطة فرعية. السبب المرجح: تقع على مضيف أو نطاق فرعي مختلف، أو فوق مسار دليل الفهرس. الإصلاح: انقلها إلى الموقع نفسه وفي المستوى نفسه أو أدنى. لا تعمل إحالات النطاقات إلا مع توثيق النطاقين في Search Console، ولا يحتاجها موقع واحد عادي.

العَرَض: رفض فهرس أو خريطة بسبب الحجم. السبب المرجح: تجاوز 50 000 عنوان أو 50 MB غير مضغوطة. الإصلاح: قسم أكثر بإضافة خريطة فرعية، أو فهرس آخر للمواقع الضخمة، بدلاً من حشر مزيد في الملف.

أثبت أن فهرس الخرائط الجديد يعمل فعلاً

الاختبار: حمّل عنوان الفهرس مباشرة في المتصفح أو بـcurl -I. النتيجة المتوقعة: HTTP 200 وXML صالح وجذر <sitemapindex>. تفسير الفشل: 404 أو انتهاء المهلة يعني أن Search Console لا تصل إليه أيضاً. نافذة المراقبة: فوراً. محفز التراجع: استمرار استجابة غير 200؛ استعد الإعداد السابق.

الاختبار: أرسل الفهرس في تقرير Sitemaps، أو مرره أولاً عبر Sitemap Validator. النتيجة المتوقعة: تتحول الحالة إلى جلب ناجح وتظهر صفوف الخرائط الفرعية. تفسير الفشل: “Couldn’t fetch” مشكلة عنوان أو استضافة أو robots.txt، لا فهرسة بعد. نافذة المراقبة: ساعات إلى يوم. محفز التراجع: تكرر فشل الجلب بعد إعادة الإرسال.

الاختبار: قارن عينة من عدد عناوين كل خريطة بما يحتويه القسم فعلياً. النتيجة المتوقعة: أعداد قريبة من حجم القسم أو نوع المحتوى. تفسير الفشل: الفرق الكبير يعني غالباً أن المولد يضم عناوين قديمة أو غير أساسية أو مكررة. نافذة المراقبة: فور التوليد. لا تراجع؛ أصلح منطق المولد وأعد التوليد.

الاختبار: راقب المرسَل في مقابل المفهرس لكل خريطة. النتيجة المتوقعة: يتجه عدد المفهرس نحو المرسَل لكل شريحة بمرور الوقت. تفسير الفشل: بقاء شريحة منخفضة يشير إلى محتوى ضعيف أو تكرار أو noindex فيها، لا إلى الفهرس نفسه. نافذة المراقبة: 2–4 أسابيع. محفز التراجع: انخفاض فعلي بعد التغيير.

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

مؤشرات الأداء الدائمة لفهرس الخرائط

المقياس: المرسَل في مقابل المفهرس لكل شريحة. ما يكشفه: القسم أو نوع المحتوى أو المنطقة ضعيفة الفهرسة بدلاً من رقم ممزوج للموقع. طريقة سحبه: تقرير Sitemaps في Search Console لكل خريطة مرسلة. المعيار: لا هدف عالمي صادق؛ الصحة هي اتجاه المفهرس نحو المرسَل، والفجوة الكبيرة المستمرة في شريحة دون غيرها هي الإشارة. الوتيرة: أسبوعياً أثناء الترحيل، وشهرياً عادة.

المقياس: حالة جلب الفهرس وكل خريطة فرعية. ما يكشفه: هل تستطيع المحركات قراءة الملفات أصلاً، وهو شرط لما بعده. طريقة سحبه: عمود الحالة في التقرير أو Sitemap Validator. المعيار: “Success” الحالة المقبولة الوحيدة؛ و”Couldn’t fetch” أو “Has errors” فشل يُصلح فوراً. الوتيرة: بعد تعديل التوليد أو إضافة خريطة، وإلا شهرياً.

المقياس: عدد العناوين وحجم كل ملف إزاء الحدود. ما يكشفه: الهامش المتبقي قبل الحاجة إلى مزيد من التقسيم. طريقة سحبه: أعداد المولد أو Sitemap Validator. المعيار: ابق دون 50 000 عنوان و50 MB غير مضغوطة بهامش مريح. الوتيرة: راقب مع نمو العناوين وأعد التقسيم قبل بلوغ الحد.

مطالبات ذكاء اصطناعي لفهرس الخرائط

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

I'm building a sitemap index for a site with these sections and approximate
URL counts:
- Blog: <N> URLs
- Product pages: <N> URLs
- Category pages: <N> URLs
- <other sections>

I want to split these into child sitemaps under one sitemap index so I can
read submitted-vs-indexed coverage per section in Google Search Console.
Given these counts, suggest a sensible way to split them into child
sitemaps (staying well under 50,000 URLs and 50MB uncompressed per file),
and flag any section that's small enough it probably doesn't need its own
child sitemap.

توقع اقتراحاً لتجميع الأقسام في خرائط فرعية، مع ملاحظة أي قسم أصغر من أن يستحق الفصل.

المطالبة: راجع فهرساً قائماً بحثاً عن أخطاء بنيوية. الصق XML الخام للفهرس أو مقتطفاً ممثلاً واطلب مراجعة البنية:

Here is my sitemap index XML:

<paste your <sitemapindex> XML here>

Check it against these rules and flag any violation:
1. The root element is <sitemapindex>, not <urlset>.
2. No <sitemap> entry points at another sitemap index file.
3. Every <loc> is a fully-qualified, absolute URL on the same site as this
   index.
4. No <loc> sits at a directory level above this index's own path.
List any entries that break these rules and explain which rule each one
breaks.

توقع قائمة سطراً بسطر للعناصر المخالفة لقواعد التداخل أو الموقع كي تصلحها قبل إعادة الإرسال.

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

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

• متى تقلق بشأن ميزانية الزحف؟ — موضع الخرائط النظيفة والكاملة في كفاءة الزحف للمواقع الكبيرة.
• ترحيل المواقع: قائمة ما قبل الإطلاق وبعده — إبقاء خريطة العناوين القديمة لمراقبة خروجها من الفهرس.
• تحسين محركات البحث التقني للمؤسسات — أتمتة الخرائط وتشخيص المرسَل في مقابل المفهرس على نطاق واسع.
• دليل المبتدئ إلى SEO التقني — موقع الخرائط والاكتشاف في الصورة الأشمل.

رسمي

• Google — إدارة الخرائط الكبيرة بملف فهرس.
• بروتوكول sitemaps.org — مواصفة <sitemapindex> وحدودها.

من الآخرين

• r/TechSEO — مجتمع لتصحيح مشكلات الخرائط والزحف والفهرسة.
• Bing Webmaster Tools: إرسال خريطة — إرشادات Bing للإرسال والتحقق.
• تغطية Search Engine Journal للخرائط — أسئلة Mueller وموضوعات الزحف والفهرسة.
• موارد Onely للخرائط — تعمق تقني في مشكلات الخرائط والتشخيص على نطاق واسع.

اختبر نفسك: فهرس خرائط الموقع

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

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