نقشه سایت XML به موتور جستجو کمک می‌کند URLهای مورد نظر سایت را بشناسد. ارزش آن از درست بودن فهرست و نگهداری منظم می‌آید، نه از تعداد فایل‌ها یا ارسال مکرر. یک نقشه سالم باید با وضعیت انتشار، کنونیکال و پاسخ سرور هماهنگ باشد. اگر خروجی شامل پیش‌نویس، صفحه حذف‌شده یا آدرس منتقل‌شده باشد، به‌جای روشن کردن ساختار، مسئله تازه‌ای برای پایش می‌سازد. در این راهنما، ساخت، اعتبارسنجی و استفاده تحلیلی از سایت مپ بررسی می‌شود.
پیش از شروع بدانید
سایت مپ فهرست صفحه‌های مطلوب است و تضمین ایندکس نیست.
lastmod باید تغییر مهم و واقعی صفحه را نشان دهد.
URL خطادار، منتقل‌شده یا غیرترجیحی نباید بی‌دلیل در نقشه بماند.
چه URLهایی باید وارد نقشه سایت شوند؟
فهرست نقشه باید از داده معتبر CMS و قواعد ایندکس ساخته شود. جمع کردن هر URL دیده‌شده در خزش، به‌تنهایی روش مناسبی نیست، چون مسیرهای پارامتری و نسخه‌های قدیمی را هم وارد می‌کند. ابتدا تعریف شود کدام وضعیت انتشار و کدام نوع صفحه مجاز است. سپس قواعد فنی مانند نسخه ترجیحی و پاسخ نهایی روی همان مجموعه اعمال شوند.
صفحه‌های خصوصی و پیش‌نویس نباید در نقشه عمومی قرار بگیرند. این کنترل فقط به نبود لینک در منو مربوط نیست. اگر API یا مولد نقشه با دسترسی مدیریتی داده می‌خواند، باید فیلتر انتشار صریح داشته باشد. در تست، یک پیش‌نویس شناخته‌شده انتخاب شود و نبود آن در خروجی نهایی بررسی شود تا اعتماد به تنظیمات عمومی جای آزمون واقعی را نگیرد.
URL نقشه باید کامل باشد و طرح، میزبان و مسیر درست داشته باشد. آدرس نسبی یا میزبان محیط آزمایش می‌تواند درخواست را به مقصد اشتباه ببرد. در سایت‌های پشت پراکسی، منبع ساخت آدرس عمومی اهمیت دارد. بهتر است دامنه اصلی از تنظیم معتبر سایت خوانده شود و با هدرهای نامطمئن هر درخواست بازسازی نشود تا خروجی قابل پیش‌بینی بماند.
نمونه ساده یک رکورد XML می‌تواند <url><loc>https://example.com/guide/</loc><lastmod>2026-10-23</lastmod></url> باشد. این قطعه باید در ساختار urlset معتبر و با فضای نام درست قرار بگیرد و فایل کامل با تجزیه‌گر آزمایش شود. تاریخ نمونه صرفا برای نمایش قالب است و نباید برای همه صفحه‌ها کپی شود. اگر تغییر مهمی در راهنمای واقعی انجام نشده، تاریخ قبلی آن حفظ می‌شود. URL نیز باید نسخه عمومی، نهایی و مورد نظر همان صفحه باشد.
نسخه ترجیحی صفحه وارد نقشه شود. اگر یک مقاله با دو مسیر در دسترس است و کنونیکال یکی را معرفی می‌کند، قرار دادن هر دو در فهرست مطلوب تناقض می‌سازد. همچنین URLی که به مقصد دیگری منتقل می‌شود بهتر است با مقصد نهایی جایگزین شود. این کار مسیر درخواست را کوتاه‌تر و تحلیل وضعیت صفحه‌های ارسال‌شده را روشن‌تر می‌کند.
lastmod باید زمان تغییر مهم محتوا را بازتاب دهد. بازسازی روزانه نقشه یا تغییر یک جزء عمومی، به معنی به‌روز شدن واقعی همه مقاله‌ها نیست. اگر CMS فقط زمان آخرین ذخیره را دارد، باید بررسی شود چه تغییرهایی آن را عوض می‌کنند. ثبت تاریخ تازه برای تمام URLها بدون تغییر محتوایی، دقت این نشانه را از بین می‌برد.
برای نقشه بزرگ، محدودیت هر فایل رعایت شود. راهنمای گوگل سقف 50000 URL یا 50 مگابایت غیر فشرده را برای یک نقشه بیان می‌کند. این سقف، هدف طراحی نیست. تقسیم منطقی بر اساس نوع صفحه یا بخش سایت می‌تواند پایش را ساده کند، حتی وقتی تعداد URL بسیار کمتر است و هنوز نیازی از نظر اندازه وجود ندارد.
نقشه جدا برای محصول، دسته و مقاله زمانی مفید است که بتوان نتیجه را بر اساس همان گروه تحلیل کرد. ساخت ده‌ها فایل کوچک بدون دلیل، نگهداری را پیچیده می‌کند. نام‌گذاری پایدار و فایل شاخص روشن کافی است. اگر یک گروه مرتبا خطا می‌دهد، تفکیک آن کمک می‌کند مشکل قالب یا منبع داده از وضعیت سایر صفحه‌ها جدا دیده شود.
نقشه تصویر یا ویدئو باید بر اساس محتوای واقعی و الزامات مربوط ساخته شود. افزودن فیلدهای بیشتر به‌خودی‌خود مزیت تضمین‌شده‌ای ندارد. ابتدا روشن شود رسانه مهم چگونه کشف می‌شود و چه اطلاعاتی برای معرفی آن لازم است. اگر تصویر فقط پس از تعامل کاربر بارگذاری می‌شود، اصلاح دسترسی و HTML نیز باید کنار طراحی نقشه رسانه بررسی شود.
قواعد ورودی نقشه با تیم محتوا مستند شوند. انتشار مقاله، حذف محصول یا تغییر وضعیت دسته باید رفتار مشخصی در نقشه داشته باشد. اگر حذف URL تنها با ویرایش دستی فایل انجام شود، خروجی به‌سرعت از پایگاه داده عقب می‌ماند. اتصال مولد به وضعیت واقعی صفحه، پایه نگهداری قابل اعتماد در سایت در حال رشد است.
برای بررسی جزئیات در مستندات اصلی، ساخت و ارسال نقشه سایت را ببینید.
برای بررسی جزئیات در مستندات اصلی، گزارش Sitemaps سرچ کنسول را ببینید.
چگونه نقشه را منتشر و خطاهای آن را پیگیری کنیم؟
پیش از ارسال، XML با یک تجزیه‌گر معتبر خوانده شود. نویسه‌های ویژه مانند علامت اتصال در query باید درست کدگذاری شوند. خطای ساختاری می‌تواند کل فایل را غیرقابل پردازش کند. صرف باز شدن نقشه در مرورگر، تایید تمام محتوا نیست و نمونه‌ای از URLهای آن نیز باید از نظر پاسخ، کنونیکال و وضعیت انتشار کنترل شود.
درخواست عمومی نقشه باید پاسخ موفق و محتوای مورد انتظار بدهد. صفحه خطای HTML با کد موفق، فایل خالی و پاسخ کش قدیمی از خطاهای مهم هستند. اگر مسیر توسط CDN یا لایه امنیتی مدیریت می‌شود، دسترسی خزنده به آن بررسی شود. مولد سالم روی سرور، تا زمانی که خروجی درست به درخواست بیرونی نرسد، کار خود را کامل نکرده است.
آدرس نقشه می‌تواند در robots.txt معرفی و در سرچ کنسول ثبت شود. ثبت، درخواست تضمینی ایندکس تک‌تک URLها نیست. بعد از ارسال باید وضعیت خوانده شدن و خطاهای پردازش بررسی شود. تکرار ارسال یک فایل بدون اصلاح علت، معمولا اطلاعات تازه‌ای به فرآیند اضافه نمی‌کند و نباید جای تحلیل صفحه‌های مورد نظر را بگیرد.
گزارش صفحه‌های ارسال‌شده را با فهرست مطلوب مقایسه کنید. اگر تعداد زیادی URL در وضعیت منتقل‌شده یا خارج از ایندکس دیده می‌شوند، اول صحت نقشه و قواعد آن بررسی شود. سپس کیفیت و دسترسی صفحه‌ها تحلیل شوند. یک علت واحد برای تمام وضعیت‌ها فرض نشود، چون محدودیت فنی، تکرار محتوا و نبود ارزش مستقل می‌توانند همزمان در گروه‌های متفاوت وجود داشته باشند.
در سایت صفحه‌بندی‌شده، نقشه جای لینک قابل خزش را نمی‌گیرد. محصولات یا مقاله‌هایی که فقط در فایل XML هستند، ممکن است در تجربه واقعی سایت جای مناسبی نداشته باشند. مسیر رسیدن از دسته یا آرشیو به آن‌ها بررسی شود. نقشه ابزار مکمل کشف است و نباید برای پوشاندن ضعف معماری و صفحه‌های یتیم استفاده شود.
برای پایش خودکار، نمونه‌های کنترلی تعریف کنید. یک مقاله منتشرشده باید وجود داشته باشد، یک پیش‌نویس نباید دیده شود و یک URL منتقل‌شده باید با مقصد نهایی جایگزین شده باشد. کنترل تعداد کلی نیز مفید است، اما تنها معیار کافی نیست. افت ناگهانی تعداد می‌تواند خطای مولد باشد و رشد ناگهانی شاید از ورود پارامترهای غیرضروری آمده باشد.
تاریخ آخرین تغییر در گزارش با منبع داده بررسی شود. اگر هر بار انتشار یک مقاله، تاریخ هزاران صفحه عوض می‌شود، منطق lastmod بازبینی شود. برای صفحه‌ای که محتوایش تغییر نکرده، بهتر است تاریخ دقیق قبلی بماند. دقت این داده به تیم تحلیل نیز کمک می‌کند بفهمد کدام تغییر محتوایی واقعا در چه زمانی انجام شده است.
هنگام مهاجرت، نقشه تازه باید به URLهای نهایی اشاره کند و با قواعد تغییر مسیر هماهنگ باشد. نقشه قدیمی می‌تواند برای پایش انتقال کاربردی داشته باشد، اما نباید با فهرست مطلوب نسخه تازه اشتباه شود. هدف هر فایل و مدت نگهداری آن نوشته شود تا پس از پایان انتقال، خروجی‌های آزمایشی و قدیمی بی‌دلیل در ساختار باقی نمانند.
نگهداری نقشه سایت با یک قاعده ساده پایان می‌یابد. فهرست باید همان صفحه‌هایی را معرفی کند که سایت واقعا برای دیده شدنشان برنامه دارد. تغییر تعداد، تاریخ و وضعیت URLها باید دلیل قابل توضیح داشته باشد. با این نگاه، سایت مپ از یک فایل تشریفاتی به ابزاری برای کنترل انتشار، کشف خطای قالب و فهم وضعیت گروه‌های مختلف صفحه تبدیل می‌شود.
| کنترل | وضعیت مطلوب | نمونه خطا |
|---|---|---|
| وضعیت انتشار | فقط صفحه عمومی مطلوب | ورود پیش نویس |
| نسخه URL | مقصد نهایی ترجیحی | پارامتر یا ریدایرکت |
| تاریخ تغییر | تغییر محتوایی واقعی | تازه شدن روزانه همه |
| ساختار XML | قابل پردازش و کامل | پاسخ HTML یا فایل خالی |
برای بررسی جزئیات در مستندات اصلی، مرور کاربرد نقشه سایت را ببینید.
پرسش های رایج
ارسال سایت مپ ایندکس را تضمین می کند؟
خیر. نقشه به معرفی URLها کمک می‌کند. دسترسی، کیفیت، تکراری بودن و سایر تصمیم‌های موتور جستجو همچنان در پردازش و انتخاب صفحه نقش دارند.
تاریخ همه صفحه ها را هر روز تازه کنیم؟
خیر. lastmod باید تغییر مهم و واقعی صفحه را نشان دهد. تازه کردن خودکار تاریخ بدون تغییر محتوا، دقت داده را کاهش می‌دهد و روش نگهداری مناسبی نیست.
آیا هر نوع محتوا نقشه جدا می خواهد؟
الزام عمومی وجود ندارد. تفکیک زمانی مفید است که نگهداری و تحلیل گروه‌ها را ساده کند یا محدودیت اندازه مطرح باشد. ساخت فایل‌های فراوان بدون کاربرد مشخص لازم نیست.
محمد حسین سرمد
محمد حسین سرمد، متخصص و مشاور سئو و بنیان‌گذار سئودانا است. فعالیت او در سئو از سال 1392 آغاز شده و تجربه نویسندگی و بررسی فناوری، در کنار شناخت توسعه و مدیریت وب‌سایت، به رویکرد کاری او شکل داده است. تمرکز این رویکرد بر پیوند دادن نیاز مخاطب، ساختار درست سایت و هدف کسب‌وکار است.
پروفایل و زمینه های تخصصی