نقشه سایت XML؛ lastmod، شاردینگ و مانیتورینگ

نقشه سایت شما با وضعیت Success در Search Console ثبت شده، اما ۳۰٪ URLهایش Redirect، noindex یا Duplicate هستند و تاریخ lastmod همه آن‌ها هر شب عوض می‌شود. XML از نظر Syntax سالم است؛ از نظر تصمیم ایندکس، فهرستی غیرقابل اعتماد ساخته‌اید.

نقشه سایت XML فهرست «همه URLهای قابل تولید» نیست. یک Feed عملیاتی از URLهایی است که می‌خواهید موتور جست‌وجو کشف و به‌عنوان نسخه ترجیحی بررسی کند. Sitemap نه دستور Crawl است، نه تضمین Index، نه ابزار رتبه‌دهی. ارزش آن از هماهنگی با Canonical، Status، Robots، Content lifecycle و پایش خطا می‌آید.

Sitemap چه کاری انجام می‌دهد و چه کاری نمی‌کند؟

نقشه سایت راه Discovery و سیگنال ضعیفی برای URL ترجیحی است. راهنمای رسمی Google برای Sitemap می‌گوید URLهایی را قرار دهید که می‌خواهید در نتایج دیده شوند و Google آن‌ها را دقیقاً با شکل فهرست‌شده Crawl می‌کند. بااین‌حال تصمیم Crawl، Canonical و Index همچنان به سیستم‌های دیگر وابسته است.

Google inclusion در Sitemap را فقط یک سیگنال ضعیف Canonical می‌داند؛ Redirect و rel="canonical" سیگنال قوی‌تری‌اند. پس XML نباید برای حل Duplicate، پارامتر یا Migration به‌تنهایی استفاده شود. راهکار Canonical باید در Response، لینک داخلی و Redirect نیز یکسان باشد.

چه سایت‌هایی بیشترین سود را می‌برند؟

• سایت بزرگ با URLهای فراوان یا عمق زیاد؛
• فروشگاه با Product/Category/Variant و تغییر موجودی/محتوا؛
• رسانه یا سایت با انتشار و Update مکرر؛
• سایت تازه با Link graph بیرونی یا داخلی محدود؛
• سایت دارای Video، Image، News یا نسخه‌های محلی ویژه؛
• پروژه مهاجرت که نیازمند فهرست روشن URLهای مقصد است.

در سایت کوچک با حدود ۵۰۰ صفحه یا کمتر که همه صفحات از Homepage با لینک قابل دسترسی‌اند، Google می‌گوید ممکن است Sitemap ضروری نباشد. بااین‌حال XML تمیز هنوز می‌تواند برای QA، Cohort‌بندی و مشاهده وضعیت «Submitted pages» مفید باشد. Sitemap نباید جای معماری اطلاعات و لینک‌سازی داخلی را بگیرد؛ URL یتیم حتی اگر کشف شود، مسیر کاربر و Context داخلی ضعیفی دارد.

چه چیزهایی تضمین نمی‌شوند؟

• Crawl همه URLهای فهرست‌شده؛
• Index یا نمایش در Search؛
• انتخاب همان URL به‌عنوان Canonical؛
• رتبه، Freshness bonus یا Crawl priority؛
• حذف URL از Index پس از خارج‌کردن از Sitemap.

قانون ورود: فقط URL ترجیحی، عمومی و واجد ایندکس

به‌جای «همه URLهای CMS»، یک Predicate صریح بسازید:

include(url) =
  public
  AND indexable
  AND preferred_canonical
  AND returns_200
  AND crawl_allowed
  AND content_is_live
  AND not_expired
  AND not_duplicate_or_parameter_variant

جدول Eligibility

برای وضعیت‌های 2xx/3xx/4xx/5xx و Semantics درست از راهنمای کدهای وضعیت HTTP استفاده کنید. خروجی Generator باید از همان Source of truth انتشار و Indexation policy بیاید، نه از Crawl تصادفی Frontend که ممکن است URLهای پارامتری و Redirect را جمع کند.

«در Sitemap نیست» معادل noindex نیست

حذف URL از XML مانع Discovery از Link، Feed یا Backlink نمی‌شود و URL ایندکس‌شده را الزاماً حذف نمی‌کند. برای صفحه عمومی که نباید در Search باشد، noindex قابل مشاهده برای Crawler لازم است؛ برای داده خصوصی، Authentication/Authorization. robots.txt ابزار امنیت یا noindex نیست.

ساختار XML، URL کامل و lastmod قابل اعتماد

طبق پروتکل Sitemaps، فایل باید UTF-۸ باشد، مقدارهای XML را Escape کند، هر <url> یک <loc> داشته باشد و URLها متعلق به Host مجاز باشند. URL نسبی، Space خام یا Ampersand بدون Entity می‌تواند Parsing را خراب کند.

نمونه حداقلی Sitemap

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.ir/products/tea-maker/</loc>
    <lastmod>2026-08-10T09:30:00+03:30</lastmod>
  </url>
</urlset>

lastmod تاریخ ساخت Sitemap نیست

lastmod باید زمان آخرین تغییر معنادار همان URL باشد، نه زمان اجرای Cron، تغییر یک Counter داخلی یا Update شدن همه رکوردها. Google می‌گوید از این مقدار وقتی استفاده می‌کند که به‌طور مداوم و قابل راستی‌آزمایی دقیق باشد. priority و changefreq را نادیده می‌گیرد.

تاریخ را در Timezone معلوم و Format W3C Datetime بسازید. اگر فقط روز با دقت کافی دارید، YYYY-MM-DD معتبر است. دقت جعلی تا ثانیه از منبعی که فقط Date دارد، ارزش اضافه نمی‌کند.

Image، Video، News و hreflang

XML می‌تواند Extensionهای پشتیبانی‌شده برای تصویر، ویدئو، خبر و نسخه محلی داشته باشد. آن‌ها را فقط برای Asset/صفحه واجد شرایط و با داده واقعی تولید کنید. XML حجیم و پیچیده‌ای که هیچ Owner یا Test ندارد بهتر از Feed ساده و درست نیست. برای International SEO، Annotationهای hreflang باید Reciprocal و با Canonical سازگار باشند؛ Sitemap یکی از روش‌های ارائه است، نه مجوز ناسازگاری.

معماری تولید: Desired set را از CMS تا XML قابل ردیابی کنید

یک Pipeline قابل اعتماد پنج لایه دارد:

1. Source: CMS/Database/Route registry و وضعیت انتشار؛
2. Policy: Eligibility، Canonical، Locale، Expiry و Content type؛
3. Transform: Absolute URL، Escape، lastmod و Shard key؛
4. Publish: فایل/Endpoint پایدار، Cache و Atomic release؛
5. Verify: XML parse، limits، URL sample/full audit، Diff و Alert.

Content/Route Source
      ↓
Eligibility + Canonical Policy
      ↓
URL Record { loc, lastmod, type, shard, reason }
      ↓
Sitemap XML / Sitemap Index
      ↓
HTTP + Parser + URL-State Verification
      ↓
Search Console + Logs + Page Indexing

برای هر حذف یک Reason نگه دارید

فقط خروجی Includeشده را ثبت نکنید. رکوردهای ردشده با Reason مانند NOINDEX، REDIRECT، NON_CANONICAL، EXPIRED یا PRIVATE برای Audit و Debug حیاتی‌اند. اگر Product مهم ناگهان حذف شد، Diff باید بگوید چرا.

محدودیت و Sitemap index

هر Sitemap حداکثر ۵۰٬۰۰۰ URL و ۵۰MB در حالت Uncompressed دارد. برای بیشتر از آن، چند فایل و یک Sitemap index بسازید. فایل Gzip پهنای باند را کم می‌کند، اما Limit حجم Uncompressed باقی است. Protocol برای Sitemap index نیز سقف ۵۰٬۰۰۰ Sitemap و ۵۰MB دارد.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.ir/sitemaps/products-01.xml.gz</loc>
    <lastmod>2026-08-12T01:00:00+03:30</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.ir/sitemaps/categories.xml.gz</loc>
    <lastmod>2026-08-11T19:15:00+03:30</lastmod>
  </sitemap>
</sitemapindex>

lastmod روی Sitemap index زمان تغییر همان فایل فرزند است، نه زمان تغییر تک‌تک صفحات. آن را فقط وقتی Shard واقعاً تغییر کرده به‌روزرسانی کنید.

چگونه Shard کنیم؟

تقسیم صرفاً هر ۵۰هزار URL فنی است، اما برای عملیات، Shardهای معنادار بهترند:

• نوع محتوا: Product، Category، Article، Location؛
• Locale/Market در معماری چندمنطقه‌ای؛
• Lifecycle: New/Recently updated در کنار Corpus پایدار، با سیاست روشن؛
• Template یا Owner برای نسبت‌دادن خطا؛
• در Catalog بسیار بزرگ، Range پایدار ID/Hash برای جلوگیری از جابه‌جایی کامل.

Shard باید Stable باشد. اگر هر اجرا URLها را میان فایل‌ها جابه‌جا کند، Diff، Cache و عیب‌یابی سخت می‌شود. اندازه عملی را کمتر از سقف بگیرید تا رشد ناگهانی فایل را خراب نکند.

Dynamic endpoint یا فایل Buildشده؟

اتصال به robots.txt و Search Console

دستور Sitemap در robots.txt

User-agent: *
Disallow: /private-preview/

Sitemap: https://example.ir/sitemap-index.xml

آدرس Sitemap باید کامل باشد. می‌توانید چند خط Sitemap: داشته باشید، اما اگر Index همه فایل‌ها را معرفی می‌کند، همان Index کافی است. خود Sitemap نباید با robots.txt، Login یا WAF برای Googlebot مسدود شود.

چرا با وجود robots.txt در Search Console هم Submit کنیم؟

گزارش Sitemaps در Search Console تاریخ Submission، آخرین Fetch و خطاهای Fetch/Parse را برای Sitemapهای Submitشده در Report یا API نشان می‌دهد. Sitemapی که فقط از robots.txt کشف شده الزاماً در این فهرست دیده نمی‌شود. Submission یعنی اعلام URL فایل؛ Upload XML به Google نیست.

پس از Submit، وضعیت Success فقط می‌گوید Google توانسته فایل را دریافت/پردازش کند؛ تضمین نمی‌کند همه URLها Crawl یا Index شوند. در Page indexing، Filter همان Sitemap را انتخاب کنید و Reasonهای Indexed/Not indexed را بر اساس Intent تحلیل کنید.

Submission lifecycle

1. HTTP فایل/Index را با User-agent معمول و Googlebot-like بررسی کنید؛
2. Content-Type، Encoding، Compression و XML parse را Test کنید؛
3. URL count/size و Absolute/same-host rules را کنترل کنید؛
4. نمونه و سپس کل URLها را با Policy تطبیق دهید؛
5. Index را در Search Console Property درست Submit کنید؛
6. Fetch/parse status و Page indexing cohort را پایش کنید؛
7. بعد از Fix، فایل را اصلاح و در صورت نیاز Resubmit کنید؛
8. Submission قدیمی/منسوخ را فقط پس از Cutover و Verification پاک کنید.

از «XML باز می‌شود» تا Observability واقعی

چهار مجموعه را جدا بسنجید:

Desired = URLهایی که Policy می‌گوید باید Indexable باشند
Generated = URLهایی که Generator در XML نوشته است
Served = فایل/URLهایی که واقعاً 200 و قابل Fetch هستند
Observed = وضعیت Fetch/Crawl/Canonical/Index در Search Console و Log

سنجه‌های سلامت

• تعداد URL هر Shard و تغییر روزانه/هفتگی؛
• سن آخرین Generation و Last successful publish؛
• Fetch status، latency، size و parse validity فایل‌ها؛
• درصد Sitemap URLهای ۲۰۰/indexable/self-canonical/crawlable؛
• تعداد Redirect/۴۰۴/5xx/noindex/non-canonical/blocked در Feed؛
• درصد lastmodهای آینده، ثابت غیرمنطقی یا تغییر جمعی؛
• Submitted vs Indexed بر اساس Shard و Reason، نه یک نرخ هدف عمومی؛
• URLهای Desired گمشده و URLهای Unexpected اضافه؛
• Googlebot fetch sitemap و نمونه URL در Log.

Alertها را بر Materiality تنظیم کنید

Decision tree برای URL ایندکس‌نشده

1. آیا URL در Desired set و Shard درست است؟
2. آیا XML Fetch/Parse و URL absolute است؟
3. آیا URL مستقیم ۲۰۰، Crawl allowed و Index allowed است؟
4. آیا Canonical اعلامی/انتخابی همان URL است؟
5. آیا Render، Soft ۴۰۴، Duplicate یا کیفیت پاسخ مسئله دارد؟
6. آیا Link graph و Demand کشف کافی‌اند؟
7. آیا تغییر تازه است و فقط زمان پردازش لازم دارد؟

اگر Sitemap سالم است، دست‌کاری XML مشکل محتوا یا Canonical را حل نمی‌کند. مسیر کامل در راهنمای حل مشکل ایندکس نشدن صفحات آمده است.

WordPress و WooCommerce: یک Generator، یک Policy

WordPress Core از نسخه ۵.۵ زیرساخت Sitemap دارد و کلاس رسمی WP_Sitemaps Providerهای Posts، Taxonomies و Users را ثبت و Index را Render می‌کند. افزونه‌های SEO نیز ممکن است Generator خود را جایگزین کنند. دو یا سه Generator هم‌زمان نگه ندارید؛ یک Endpoint مالک و یک Policy قابل آزمون انتخاب کنید.

ممیزی WordPress

• Index اصلی و همه Child sitemapها مستقیم ۲۰۰ و XML هستند؛
• Post type، Taxonomy و Author archive واقعاً ارزش Index دارند؛
• Attachment URL، Search، Feed، Preview و Parameter وارد نشده‌اند؛
• Draft/Private/Noindex/Canonical-away حذف شده‌اند؛
• حذف/انتشار محتوا Cache مربوط به Shard را Invalidate می‌کند؛
• Plugin/Theme Update ساختار Endpoint را بی‌صدا عوض نکرده است؛
• Multi-language Plugin، Canonical و hreflang با Feed سازگارند؛
• User sitemap اطلاعات یا Archive کم‌ارزش ناخواسته افشا نمی‌کند.

فروشگاه و Facetها

در WooCommerce یا Catalog اختصاصی، Product قابل خرید/مشاهده، Category با پاسخ مستقل و Pageهای محتوایی مالک را تفکیک کنید. Sort، Filter، Pagination، Internal search، Cart و Account معمولاً Feed اصلی نیستند. Variant مستقل فقط اگر URL، موجودیت، محتوای متمایز و Policy Canonical مستقل دارد وارد شود.

محصول Out-of-stock را صرفاً به‌خاطر موجودی صفر حذف نکنید؛ Intent و Lifecycle مهم است. اگر بازمی‌گردد و صفحه پاسخ مفید دارد ممکن است ۲۰۰/indexable بماند. اگر بازنشسته شده، Substitute/Category/۴۱۰ و Redirect policy را تصمیم بگیرید. برای Catalog، Facet، Product truth و Lifecycle به راهنمای سئوی فروشگاه اینترنتی رجوع کنید.

Sitemap در Migration و Release

در مهاجرت URL، XML جدید باید مقصدهای نهایی را معرفی کند؛ فایل Redirect sourceها را نگه ندارید. اما Old URL inventory را خارج از Sitemap برای تست و Monitoring حفظ کنید. راهنمای Redirect و مهاجرت URL Mapping، Direct redirect، Test و Rollback را پوشش می‌دهد.

Runbook انتشار

1. پیش از Release: Desired set، URL map، Sample/full crawl و XML fixture را Freeze کنید.
2. Staging: Sitemap عمومی Production را به Staging اشاره ندهید؛ Environment را با Authentication جدا کنید.
3. Cutover: Redirect، Canonical، لینک داخلی و Sitemap مقصد هم‌زمان منتشر شوند.
4. Verify: Index/Childها ۲۰۰، Parse، Count، lastmod، noindex/redirect/۴۰۴ و Host را تست کنید.
5. Submit: Index جدید را در Property درست ثبت و Fetch status را ببینید.
6. Hypercare: Diff، 5xx، Redirect/۴۰۴، Googlebot logs و Page indexing cohort را رصد کنید.
7. Rollback: Sitemap و Policy با Artifact نسخه‌دار برگردند؛ URL migration را بدون بررسی Data write کور Rollback نکنید.

برای Gateهای Staging تا T+۳۰ از چک‌لیست سئو طراحی و انتشار سایت استفاده کنید.

سه Runbook رخداد

Index یا Child sitemap از دسترس خارج است

HTTP/WAF/Origin/Cache را بررسی، آخرین Artifact سالم را Serve و Age/Count را ثبت کنید. پس از رفع، Fetch زنده و Search Console را تأیید کنید. ۲۰۰ HTML با صفحه خطا Success نیست؛ Content-Type و XML parse مهم‌اند.

URLهای noindex/redirect ناگهان زیاد شده‌اند

Diff را بر Shard و Release marker تطبیق دهید. Source status، Canonical policy، Plugin update و Cache را بررسی کنید. ابتدا Generator را Fix کنید؛ Mass remove یا Request indexing جای Root cause نیست.

lastmod همه URLها تغییر کرده است

Deployment timestamp، ORM updated_at، Import job و Template touch را بررسی کنید. مقدار را از Content-visible change lineage بسازید، Artifact غلط را جایگزین و Rule regression اضافه کنید. تغییر دوباره همه تاریخ‌ها Fix قابل اعتماد نیست.

چک‌لیست QA نقشه سایت

• Endpoint و Childها مستقیم ۲۰۰، قابل Fetch و XML معتبرند.
• UTF-۸، Entity escaping، Absolute URL و Host/Protocol درست است.
• هر فایل زیر ۵۰٬۰۰۰ URL و ۵۰MB Uncompressed است.
• فقط URLهای ۲۰۰/indexable/preferred-canonical/live وارد شده‌اند.
• Redirect، ۴۰۴/۴۱۰، 5xx، noindex، blocked و private وجود ندارد.
• lastmod از تغییر معنادار صفحه می‌آید و آینده/همگانی نیست.
• priority/changefreq برای Google ارزش تصمیمی فرض نشده‌اند.
• Shardها معنادار، پایدار، مالک‌دار و دارای Headroom هستند.
• Desired/Generated/Served/Observed قابل تطبیق و Diff است.
• Search Console، Log، Alert، Runbook و Rollback فعال‌اند.

در ممیزی سراسری، Sitemap فقط یکی از لایه‌هاست. برای پیوند آن با Crawl، Canonical، Content، Schema، Performance و Measurement از چک‌لیست ممیزی کامل سئو استفاده کنید.

پرسش‌های متداول

آیا Sitemap باعث ایندکس‌شدن همه صفحات می‌شود؟

خیر. Sitemap به Discovery و اعلام URL ترجیحی کمک می‌کند، اما Crawl و Index تضمین نمی‌شوند. Status، Robots، noindex، Canonical، Render، Duplicate، کیفیت پاسخ و Link graph مستقل‌اند.

چه URLهایی باید در نقشه سایت باشند؟

URLهای کامل و عمومی که مستقیم ۲۰۰، Crawl allowed، indexable، زنده و نسخه Canonical ترجیحی‌اند. Redirect، خطا، noindex، private، staging، پارامتر و Duplicate معمولاً نباید وارد شوند.

lastmod را چه زمانی تغییر دهیم؟

وقتی محتوای قابل مشاهده یا اطلاعات معنادار همان URL واقعاً تغییر کرده است. زمان ساخت XML، Deploy عمومی، Cache، View count یا تغییر تاریخ نمایشی بدون اصلاح واقعی نباید lastmod همه صفحات را عوض کند.

آیا changefreq و priority برای Google مهم‌اند؟

Google در مستند رسمی خود می‌گوید این دو مقدار را نادیده می‌گیرد. زمان تیم را صرف Eligibility، Canonical consistency، lastmod دقیق، Availability و Monitoring کنید.

Sitemap را در robots.txt معرفی کنیم یا Search Console؟

هر دو می‌توانند مکمل باشند. خط Sitemap در robots.txt محل فایل را به Crawler اعلام می‌کند؛ Submit در Search Console تاریخ Fetch و خطاهای پردازش را برای Sitemap ثبت‌شده قابل مشاهده می‌سازد. اگر Sitemap index دارید، معرفی همان Index معمولاً کافی است.

جمع‌بندی

نقشه سایت XML یک Feed مالک‌دار از Desired indexable set است، نه انبار URL. کیفیت آن با تعداد بیشتر سنجیده نمی‌شود؛ با سازگاری Status، Canonical، Robots، lastmod و Lifecycle، قابلیت Fetch و امکان تشخیص Drift سنجیده می‌شود.

اگر فقط یک اقدام انجام می‌دهید، تمام URLهای Sitemap را به پنج ستون تبدیل کنید: Status، Indexability، Canonical، lastmod source و Inclusion reason. هر تناقض، یا Bug در Generator است یا تصمیم Indexation حل‌نشده.