بهبود بودجه خزش در سئو

نگاه اجمالی

فاز	هدف فوری 🎯	اقدام مستقیم ⚡	چک سریع 🔎	اشتباه رایج 🚫
محتوا/برند/تعامل 👥	بالا رفتن Crawl Demand	آپدیت معنادار صفحات ستون + بهتر کردن مسیر مطالعه و بازگشت کاربر	کراول منظم‌تر URLهای مهم + دیده‌شدن سریع‌تر آپدیت‌ها	آپدیت ظاهری (فقط تاریخ/تایپو) و انتظار معجزه
مدیریت URL 🧭	بستن راه تولید URL مزاحم	کنترل پارامتر/فیلتر + noindex/قطع لینک سرچ داخلی + حذف UTM از لینک داخلی	افت الگوهای ?filter و /search در Crawl Stats/لاگ	درمان تک‌URL به جای بستن الگو
ایندکس‌پذیری و کیفیت 📌	کم شدن کراول بی‌خروجی	ادغام/حذف Thin + 404/410 واقعی + canonical یک‌دست + جمع کردن Duplicate	افت Soft 404 و Crawled/Discovered-not-indexed	ریدایرکت بی‌ربط به صفحه اصلی
ساختار و لینک داخلی 🧱	اولویت دادن به صفحات پول‌ساز	کاهش Click Depth + لینک contextual از صفحات قوی + سبک کردن منو/فوتر	Click Depth صفحات کلیدی ≤ ۳ + افزایش inlinks هدفمند	لینک دادن به همه‌چیز از منو/فوتر
ریدایرکت و پاسخ سرور 🔁	افزایش crawl efficiency	حذف Redirect Chain + تبدیل 302 دائمی به 301 + کم کردن ریدایرکت‌های غیرضروری	کاهش hop ریدایرکت + افت 301/302 اضافی در لاگ	ول کردن زنجیره‌ها بعد از مهاجرت
Sitemap 📄	سیگنال‌دهی تمیز به گوگل	حذف noindex/ریدایرکت/پارامتر از sitemap + تفکیک sitemap + lastmod واقعی	کاهش Submitted but not indexed + هم‌راستایی submitted/indexed	sitemap اتوماتیک شلوغ و بی‌نظارت
Robots 🤖	جلوگیری از کراول مسیرهای بی‌ارزش	بلاک هدفمند مسیرهای سیستمی + عدم بلاک CSS/JS حیاتی	رفع blocked resources در تست‌ها + افت کراول مسیرهای بی‌ارزش	بلاک کور /wp-content یا assets
زیرساخت و عملکرد ⚙️	بالا رفتن Crawl Capacity	کاهش TTFB + رفع 5xx/timeout + سبک کردن JS + جلوگیری از lazy-load مخرب	افت response time و error rate در Crawl Stats	دستکاری سئو با سرور ناپایدار
مانیتورینگ و داده 📊	کنترل هدررفت و اولویت واقعی گوگل	بررسی دوره‌ای Crawl Stats + لاگ آنالیز + بستن الگوهای هدررفت	شناخت URLهای پرکراول بی‌ارزش + بهبود نسبت crawl به ایندکس	واکنشی عمل کردن فقط وقتی افت رتبه شد

این مقاله را در چند فاز جلو می‌بریم تا به‌جای حرف‌های پراکنده، یک مسیر عملی برای کنترل Crawl Budget داشته باشیم.

1. مدیریت محتوا، برند و تعامل کاربران
2. مدیریت URL
3. ایندکس‌پذیری و کیفیت صفحات
4. ساختار سایت و لینک‌سازی داخلی
5. ریدایرکت و وضعیت پاسخ سرور
6. Sitemap و سیگنال‌دهی به گوگل
7. Robots و کنترل دسترسی کراولر
8. زیرساخت و عملکرد فنی
9. مانیتورینگ و تحلیل داده

دیدگاه شخصی من

اولین نکته‌ای که همیشه رویش تأکید دارم اینه که کراول باجت برای همه سایت‌ها مهمه، اما برای همه سایت‌ها به یک اندازه و با یک اولویت نیست. اشتباه رایجی که می‌بینم اینه که یک سایت ۳۰۰ یا ۵۰۰ صفحه‌ای خودش رو با پروژه‌ای مثل دیجی‌کالا مقایسه می‌کنه و همون‌قدر استرس می‌گیره، همون‌قدر درگیر جزئیات می‌شه و همون‌قدر دنبال کنترل میلی‌متری کراول باجت می‌ره. این مقایسه از ریشه غلطه. مسئله این نیست که کراول باجت مهم نیست، مسئله اینه که «سطح حساسیتش» بسته به مقیاس سایت فرق می‌کنه.

برای بخش بزرگی از سایت‌های کوچک و متوسط، رعایت همین اصول پایه‌ای و بیسیک کاملاً کافیه؛ ساختار URL تمیز، حذف URLهای مزاحم، sitemap درست، noindex منطقی و لینک‌سازی داخلی سالم. خیلی وقت‌ها همین‌ها مسئله رو جمع می‌کنه و نیازی نیست وارد فاز وسواس‌گونه‌ی تحلیل لاگ و ریزه‌کاری‌ها بشید، مگر اینکه واقعاً در اون مقیاس باشید.

نکته‌ای که معمولاً در بحث‌های فنی نادیده گرفته می‌شه اینه که کراول باجت فقط یک موضوع تکنیکال نیست. اگر سایتت واقعاً ارزشمند شده باشه، خیلی از این مسائل خودبه‌خود بهتر می‌شن. صفحه خوب، اعتبار دامنه، سرچ برند، ورودی درست و محتوایی که واقعاً پاسخ نیاز کاربره، همه‌شون سیگنال‌های مثبتی هستن که رفتار گوگل رو تغییر می‌دن. گوگل به سایتی که کاربر دنبالش می‌گرده و بهش برمی‌گرده، طبیعی‌تر و عمیق‌تر کراول می‌کنه. این حاصل زمانه، حاصل ثباته و حاصل اینه که سایتت در عمل ثابت کنه ارزش دیده شدن داره.

اگر نمی‌دونی این مقاله رو از کجا شروع کنی، جدول زیر مسیر مطالعه رو بر اساس نوع سایتت مشخص می‌کنه.

سناریوی سایت	نشانه‌های رایج	تمرکز اصلی مطالعه	فازهای اولویت‌دار مقاله	فعلاً لازم نیست
سایت کوچک یا متوسط (زیر ~۱۰۰۰ URL ایندکس‌پذیر)	افزایش Crawled – currently not indexed، وجود تگ و آرشیو اضافی، صفحات سرچ داخلی، sitemap شلوغ، آپدیت‌نشدن صفحات مهم	جلوگیری از هدررفت کراول به‌خاطر URLهای مزاحم و تقویت سیگنال ارزش صفحات کلیدی	مدیریت URL، کنترل سرچ داخلی، canonical، noindex هدفمند، پاکسازی sitemap، آپدیت معنادار صفحات مهم	لاگ آنالیز سنگین، تنظیمات پیچیده robots، وسواس روی crawl rate
فروشگاه بزرگ / مارکت‌پلیس (ده‌ها هزار تا میلیون‌ها URL)	کراول زیاد روی پارامترها و فیلترها، ایندکس کند صفحات پول‌ساز، آپدیت دیر دیده‌شدن محصولات، رفتار ضعیف کاربر در صفحات کلیدی	هدایت Crawl Budget به صفحات پول‌ساز و افزایش اولویت واقعی آن‌ها برای گوگل	کنترل پارامترها، جلوگیری از URL بی‌نهایت، canonical تمپلیتی، لینک‌سازی داخلی، تفکیک sitemap، بهینه‌سازی سرور، بهبود UX و engagement صفحات پول‌ساز	noindex کورکورانه، بلاک گسترده robots، تمرکز صرف روی محتوا بدون اصلاح ساختار
سایت محتوایی / خبری / وبلاگی بزرگ	رشد discovered-not-indexed، آرشیو تگ و تاریخ زیاد، pagination عمیق، صفحات thin، افت بازگشت کاربر	جلوگیری از دفن محتوای ارزشمند و حفظ زنده‌بودن محتوای اصلی برای گوگل	حذف یا ادغام thin content، مدیریت آرشیوها، کنترل pagination، اصلاح لینک‌سازی داخلی، آپدیت دوره‌ای محتوای ستون	تمرکز افراطی روی پارامترها، بلاک کور مسیرها بدون قطع لینک داخلی
سایت با برند ضعیف یا تعامل پایین	نبود Brand Query، ورودی مقطعی، عدم بازگشت کاربر، crawl نامنظم صفحات جدید	افزایش اعتماد گوگل به سایت از طریق رفتار کاربر و سیگنال برند	بهبود engagement محتوا، ساخت صفحات مرجع، لینک‌سازی داخلی هوشمند، تقویت صفحات برندمحور	دستکاری افراطی crawl، تغییرات فنی سنگین بدون حل مشکل ارزش محتوا
هر نوع سایتی با مشکل سرور	خطاهای 5xx، timeout، response time بالا در Crawl Stats	بازگرداندن اعتماد زمانی گوگل قبل از هر بهینه‌سازی دیگر	اصلاح خطاهای سرور، کاهش TTFB، افزایش پایداری، جلوگیری از timeout	بازی با sitemap، canonical یا لینک داخلی قبل از حل مشکل زیرساخت

به نقل از developers.google.com

اگر سایت شما تعداد زیادی صفحه با تغییرات سریع ندارد، یا صفحات‌تان معمولاً در همان روز انتشار کراول می‌شوند، گوگل اعلام می‌کند که عملاً نیازی به درگیری عمیق با مبحث Crawl Budget ندارید و نگه‌داشتن sitemap و بررسی Index Coverage کافی است.

گوگل این راهنما را یک راهنمای پیشرفته می‌داند و آن را عمدتاً برای سایت‌های بسیار بزرگ (حدود یک میلیون URL یا بیشتر)، سایت‌هایی با بیش از ۱۰ هزار URL که روزانه تغییر می‌کنند، یا سایت‌هایی که بخش بزرگی از URLهایشان در وضعیت Discovered – currently not indexed قرار دارد، مناسب می‌داند.

مدیریت محتوا، برند و تعامل کاربران

در عمل، Crawl Budget فقط حاصل محدودیت منابع گوگل نیست؛ حاصل قضاوت گوگل درباره «ارزش دنبال کردن» یک سایته. اگر سایتی در رفتار کاربران، ثبات محتوا و برند سیگنال‌های مثبتی بده، گوگل به‌صورت طبیعی و بدون دستور مستقیم، عمیق‌تر و منظم‌تر کراولش می‌کنه.

گوگل اعلام می‌کند که میزان crawl demand بر اساس عواملی مانند محبوبیت URL، تازگی محتوا و میزان تغییرات آن تعیین می‌شود، نه صرفاً ساختار فنی سایت.

نقش آپدیت منظم و معنادار محتوا

آپدیت محتوا فقط برای رتبه گرفتن نیست؛ یکی از سیگنال‌های مهم برای زمان‌بندی کراوله. گوگل صفحاتی که به‌صورت منظم و معنادار تغییر می‌کنن رو در اولویت crawl نگه می‌داره، چون احتمال می‌ده اطلاعات جدید یا اصلاح‌شده داشته باشن. نکته کلیدی اینه که این آپدیت باید واقعی باشه، نه ظاهری. تغییر تاریخ، اصلاح یک تایپو یا جابه‌جایی چند جمله معمولاً سیگنال قوی محسوب نمی‌شه. اما اضافه شدن بخش جدید، به‌روزرسانی داده‌ها، اصلاح ساختار محتوا یا تکمیل پاسخ به نیاز کاربر، هم ایندکس رو تحریک می‌کنه هم crawl frequency رو. در سایت‌هایی که محتوای ستون یا صفحات پول‌ساز به‌طور دوره‌ای به‌روزرسانی می‌شن، معمولاً می‌بینی Googlebot فاصله crawlها رو کوتاه‌تر می‌کنه، حتی بدون تغییر خاص در sitemap یا لینک‌سازی.

نقش engagement واقعی کاربران

گوگل مستقیم آمار engagement آنالیتیکس رو نمی‌بینه، اما اثرش رو غیرمستقیم حس می‌کنه. صفحاتی که کاربر روشون می‌مونه، اسکرول می‌کنه، برمی‌گرده به سایت و دوباره وارد صفحات دیگه می‌شه، معمولاً الگوی crawl متفاوتی دارن. در پروژه‌های واقعی، بارها دیده می‌شه صفحاتی که از نظر فنی هیچ تفاوتی با بقیه ندارن، فقط به‌خاطر رفتار بهتر کاربر، crawl منظم‌تر و سریع‌تری می‌گیرن. دلیلش ساده‌ست: گوگل دنبال محتواییه که «زنده» است. اگر صفحه‌ای بعد از ایندکس عملاً فراموش می‌شه، Googlebot هم به‌مرور فاصله سر زدنش رو زیاد می‌کنه. به همین خاطر، بهبود UX، ساختار محتوا، پاسخ دقیق به intent و حتی لینک‌دهی هوشمندانه داخل محتوا، به‌طور غیرمستقیم روی Crawl Budget اثر می‌ذاره.

نقش Brand Query و بازگشت کاربر

یکی از قوی‌ترین سیگنال‌های نادیده‌گرفته‌شده در Crawl رفتار برندیه. وقتی کاربران اسم برند یا دامنه رو جستجو می‌کنن، یا بعد از اولین بازدید دوباره به سایت برمی‌گردن، گوگل متوجه می‌شه با یک منبع قابل اتکا طرفه. این موضوع فقط روی رتبه اثر نمی‌ذاره؛ روی رفتار کراول هم اثر می‌ذاره. سایت‌هایی که سرچ برند دارن و کاربر بهشون برمی‌گرده، معمولاً سریع‌تر آپدیت‌هاشون دیده می‌شه و صفحات جدیدشون زودتر وارد چرخه crawl می‌شن. در مقابل، سایتی که فقط از لانگ‌تیل‌های اتفاقی ورودی می‌گیره و وفاداری ایجاد نمی‌کنه، حتی با تنظیمات فنی درست هم crawl محدودی تجربه می‌کنه.

---

مدیریت URL

بهینه‌سازی ساختار URL

• سناریوی واقعی
  این مشکل بیشترین احتمال وقوع رو در فروشگاه‌های بزرگ، مارکت‌پلیس‌ها، سایت‌های آگهی، و هر سایتی که URLها به‌صورت دیتابیس‌محور تولید می‌شن داره. ساختارهایی مثل
  /product/12345
  یا
  /item?id=98765
  یا URLهایی که معنا، سلسله‌مراتب و ارتباط مفهومی ندارن. در این سایت‌ها معمولاً URLها از منطق بک‌اند میان، نه از استراتژی سئو.
• رفتار گوگل
  Googlebot برای اولویت‌بندی کراول، به شدت به الگوهای URL، عمق مسیر و ثبات ساختاری حساسه. URLهایی که ساختار منطقی ندارن، بیشتر شبیه URLهای auto-generated دیده می‌شن و وارد صف کراول با اولویت پایین‌تر می‌شن. نتیجه؟ گوگل زمان بیشتری صرف کشف می‌کنه و زمان کمتری صرف کراول مؤثر.
• تشخیص مشکل
  در Search Console، معمولاً الگوی URLهای کراول‌شده تنوع بالایی داره ولی URLهای مهم کمتر کراول می‌شن. در لاگ سرور هم می‌بینی Googlebot روی مسیرهای بی‌معنا و غیرقابل خوشه‌بندی زیاد رفت‌وآمد داره. Screaming Frog هم معمولاً URL Structure غیرقابل پیش‌بینی رو نشون می‌ده.
• راه‌حل عملی
  ساختار URL باید بازتاب‌دهنده ساختار سایت باشه، نه دیتابیس. URLها باید قابل گروه‌بندی، قابل پیش‌بینی و پایدار باشن. حذف پارامترهای غیرضروری، استفاده از مسیرهای سلسله‌مراتبی، و جلوگیری از تولید URLهای بی‌معنا اولین قدمه. این کار مستقیماً Crawl Queue گوگل رو تمیز می‌کنه.

کنترل پارامترها و فیلترها

• سناریوی واقعی
  این مشکل امضای کلاسیک فروشگاه‌های اینترنتی، سایت‌های املاک، خودرو و هر جاییه که فیلتر زیاد داره. فیلتر قیمت، رنگ، برند، موجودی، مرتب‌سازی و… که هر ترکیبش یک URL جدید می‌سازه.
• رفتار گوگل
  گوگل به‌صورت پیش‌فرض سعی می‌کنه پارامترها رو کشف کنه، نه اینکه نادیده بگیره. اگر سیگنال مشخصی نداشته باشه، وارد مسیرهای پارامتری می‌شه و بودجه کراول رو روی URLهایی می‌سوزونه که هیچ ارزش ایندکسی ندارن.
• تشخیص مشکل
  در Crawl Stats، افزایش شدید URLهای کراول‌شده بدون افزایش ایندکس دیده می‌شه. در Coverage هم URLهای “Crawled – currently not indexed” یا “Duplicate, Google chose different canonical” بالا می‌ره. لاگ سرور معمولاً پر از ?sort=، ?price=، ?filter= هست.
• راه‌حل عملی
  پارامترها باید تفکیک بشن: کدوم برای UX لازمن و کدوم برای SEO. استفاده از canonical، noindex هدفمند، و در موارد خاص block پارامترها از طریق robots ضروریه. فیلترهایی که لندینگ پول‌ساز نیستن نباید به‌عنوان URL مستقل به گوگل معرفی بشن.

حذف URLهای تولیدشده توسط جستجوی داخلی

• سناریوی واقعی
  در سایت‌های محتوایی، فروشگاهی و حتی آموزشی، جستجوی داخلی URLهایی مثل /search?q=… می‌سازه. این مشکل در سایت‌هایی که سرچ داخلی indexable هست بسیار رایجه.
• رفتار گوگل
  گوگل این URLها رو Thin، تکراری و بدون ارزش می‌دونه، اما اگر لینکی بهشون داده شده باشه، همچنان کراول می‌کنه.
• تشخیص مشکل
  Coverage پر از Soft 404 و Crawled – not indexed می‌شه. لاگ سرور نشون می‌ده Googlebot مرتب روی /search می‌چرخه.
• راه‌حل عملی
  تمام URLهای سرچ داخلی باید noindex بشن و ideally از کراول هم خارج بشن. این URLها هیچ‌وقت نباید وارد sitemap بشن یا لینک داخلی بگیرن.

کنترل URLهای UTM و Tracking

• سناریوی واقعی
  در سایت‌هایی با کمپین‌های تبلیغاتی زیاد، مخصوصاً B2B و SaaS، URLهای UTM وارد ساختار داخلی می‌شن و لینک می‌گیرن.
• رفتار گوگل
  گوگل UTM رو پارامتر تکراری می‌دونه، ولی اگر canonical یا کنترل نداشته باشه، کراول می‌کنه.
• تشخیص مشکل
  وجود URLهای مشابه با تفاوت utm_source در Coverage و لاگ سرور.
• راه‌حل عملی
  Canonical همیشه باید به URL تمیز اشاره کنه. هیچ URL دارای UTM نباید لینک داخلی بگیره یا وارد sitemap بشه.

جلوگیری از تولید URL بی‌نهایت

• سناریوی واقعی
  Pagination اشتباه، infinite scroll بدون مدیریت، تقویم‌ها، آرشیوهای تاریخ و صفحات “بعدی” بی‌پایان باعث این مشکل می‌شن. سایت‌های خبری و وبلاگی بیشترین آسیب رو می‌بینن.
• رفتار گوگل
  گوگل تا جایی که بتونه crawl می‌کنه، نه تا جایی که منطقیه. اگر سیگنال توقف نداشته باشه، بودجه رو می‌سوزونه.
• تشخیص مشکل
  در لاگ سرور، crawl روی page=999 و date=2012 دیده می‌شه. Crawl Stats رشد داره ولی ایندکس نه.
• راه‌حل عملی
  rel=next/prev (با وجود deprecation هنوز برای سیگنال‌دهی مفهومی مفیده)، محدودسازی pagination، و بستن آرشیوهای بی‌ارزش.

---

ایندکس پذیری و کیفیت صفحات

حذف یا ادغام صفحات Thin Content

• سناریوی واقعی
  این مشکل به‌طور خاص در سایت‌های محتوایی بزرگ، وبلاگ‌های قدیمی، فروشگاه‌هایی با دسته‌های نیمه‌خالی و سایت‌هایی که سال‌ها بدون استراتژی محتوا رشد کردن دیده می‌شه. صفحاتی با ۲۰۰ تا ۳۰۰ کلمه متن تکراری، دسته‌هایی با ۲ یا ۳ محصول، یا مقالاتی که فقط برای پوشش کلمه کلیدی ساخته شدن ولی هیچ ارزشی اضافه نکردن.
• رفتار گوگل
  گوگل Thin Content رو الزاماً پنالتی نمی‌کنه، ولی به‌شدت deprioritize می‌کنه. یعنی این صفحات وارد صف کراول می‌شن، ولی نه به‌عنوان اولویت. نتیجه اینه که همون بودجه محدود، صرف صفحاتی می‌شه که شانس رتبه گرفتن ندارن.
• تشخیص مشکل
  در Search Console معمولاً این صفحات با وضعیت “Crawled – currently not indexed” یا “Discovered – currently not indexed” دیده می‌شن. در لاگ سرور، می‌بینی Googlebot گه‌گاهی سر می‌زنه، ولی خبری از کراول منظم نیست. Screaming Frog هم حجم بالای صفحات با word count پایین نشون می‌ده.
• راه‌حل عملی
  یا باید این صفحات واقعاً تقویت بشن، یا ادغام. حذف کورکورانه اشتباهه. صفحات thin مرتبط باید در یک صفحه جامع‌تر merge بشن و با ریدایرکت 301 جمع‌وجور بشن. اگر صفحه هیچ نقش استراتژیکی نداره، حذف و 410 دادن کاملاً منطقیه. هدف اینه که هر URL ایندکس‌پذیر، واقعاً شایسته کراول باشه.

noindex هدفمند صفحات کم‌ارزش

گوگل توصیه می‌کند برای URLهایی که نمی‌خواهید کراول شوند، از robots.txt استفاده شود، زیرا صفحات noindex همچنان درخواست می‌شوند و این می‌تواند باعث هدررفت Crawl Budget شود.

• سناریوی واقعی
  سایت‌های بزرگ معمولاً صفحاتی دارن که برای کاربر مفیدن ولی برای سئو نه؛ مثل صفحات فیلتر خاص، پروفایل کاربران، صفحات تشکر، یا مراحل میانی فرایند خرید.
• رفتار گوگل
  اگر صفحه‌ای noindex باشه ولی لینک داخلی قوی بگیره، گوگل همچنان کراولش می‌کنه، اما ایندکس نمی‌کنه. اگر تعداد این صفحات زیاد باشه، عملاً کراول باجت تلف می‌شه بدون هیچ خروجی.
• تشخیص مشکل
  در Coverage تعداد زیادی URL با وضعیت “Excluded by noindex” دیده می‌شه. در Crawl Stats هم می‌بینی کراول بالا رفته ولی ایندکس نه.
• راه‌حل عملی
  noindex باید همراه با مدیریت لینک داخلی باشه. صفحاتی که noindex هستن نباید لینک‌های داخلی سنگین بگیرن. در موارد خاص، حتی می‌شه این مسیرها رو از کراول هم خارج کرد، ولی فقط زمانی که مطمئنی به محتوای مهم آسیب نمی‌زنه.

مدیریت صحیح Soft 404

• سناریوی واقعی
  این مشکل در سایت‌هایی که صفحه خالی رو با پیام «موردی یافت نشد» ولی با کد 200 برمی‌گردونن خیلی رایجه. فروشگاه‌هایی با محصولات ناموجود یا سایت‌های محتوایی با صفحات حذف‌شده بیشترین آسیب رو دارن.
• رفتار گوگل
  گوگل Soft 404 رو به‌عنوان سیگنال کیفیت پایین می‌بینه. این صفحات هم کراول می‌شن، هم ایندکس نمی‌شن، و هم به اعتبار کلی سایت ضربه می‌زنن.
• تشخیص مشکل
  در Coverage بخش Soft 404 پر می‌شه. لاگ سرور نشون می‌ده Googlebot مرتب این صفحات رو می‌بینه ولی دوباره برمی‌گرده.
• راه‌حل عملی
  یا صفحه باید واقعاً محتوا داشته باشه، یا باید وضعیت پاسخ سرور درست بشه. صفحه‌ای که محتوایی نداره باید 404 یا 410 واقعی بده.

بازگرداندن 404 یا 410 واقعی

• سناریوی واقعی
  سایت‌هایی که از ترس 404، همه‌چیز رو به صفحه اصلی یا دسته‌ها ریدایرکت می‌کنن.
• رفتار گوگل
  گوگل این رفتار رو نشونه دستکاری می‌دونه. URL حذف‌شده اگر بی‌ربط ریدایرکت بشه، هم کراول هدر می‌ره هم سیگنال کیفیت منفی ایجاد می‌شه.
• تشخیص مشکل
  Coverage پر از “Redirect error” یا “Soft 404” می‌شه. در لاگ سرور، Googlebot بین URL قدیمی و مقصد بی‌ربط می‌چرخه.
• راه‌حل عملی
  URLی که برای همیشه حذف شده باید 410 بده. URLی که موقتاً حذف شده 404. ریدایرکت فقط زمانی منطقیه که ارتباط محتوایی واقعی وجود داشته باشه.

کنترل Duplicate Content

• سناریوی واقعی
  نسخه‌های مختلف یک محتوا با URLهای متفاوت، مخصوصاً در فروشگاه‌ها، سایت‌های چندزبانه، و سایت‌هایی با http/https یا www/non-www ناقص.
• رفتار گوگل
  گوگل یکی رو canonical انتخاب می‌کنه و بقیه رو کنار می‌ذاره، اما همچنان کراول می‌کنه تا مطمئن بشه چیزی تغییر نکرده.
• تشخیص مشکل
  Coverage با پیام “Duplicate, Google chose different canonical” پر می‌شه. لاگ سرور نشون می‌ده Googlebot مرتب بین نسخه‌ها می‌چرخه.
• راه‌حل عملی
  Canonical باید دقیق، یک‌دست و بدون تناقض باشه. ساختار سایت باید فقط یک نسخه واقعی از هر محتوا داشته باشه. بقیه یا ریدایرکت، یا canonical.

استفاده صحیح از Canonical

• سناریوی واقعی
  Canonicalهای خودارجاع اشتباه، canonical به URL نادرست، یا canonical متناقض بین HTML و HTTP Header در سایت‌های بزرگ زیاد دیده می‌شه.
• رفتار گوگل
  وقتی canonical سیگنال متناقض بده، گوگل بهش بی‌اعتماد می‌شه و دوباره وارد فاز crawl و تصمیم‌گیری می‌شه.
• تشخیص مشکل
  در Coverage، canonicalهای نادیده گرفته‌شده دیده می‌شن. Screaming Frog هم canonical mismatch گزارش می‌ده.
• راه‌حل عملی
  Canonical باید ساده، قطعی و ثابت باشه. هر صفحه فقط یک canonical داشته باشه و با sitemap، لینک داخلی و ریدایرکت‌ها هم‌راستا باشه.

مدیریت صفحات Auto-generated

• سناریوی واقعی
  برچسب‌ها، آرشیوها، صفحات پیشنهادشده خودکار، و هر چیزی که بدون تصمیم انسانی ساخته شده. سایت‌های خبری و وبلاگی بزرگ اینجا بیشترین ریسک رو دارن.
• رفتار گوگل
  گوگل این صفحات رو به‌عنوان low-value pattern شناسایی می‌کنه و در صورت زیاد شدن، بودجه کراول کل سایت آسیب می‌بینه.
• تشخیص مشکل
  افزایش URL count بدون افزایش محتوای واقعی. Crawl Stats بالا، ایندکس پایین.
• راه‌حل عملی
  یا این صفحات باید واقعاً curate بشن و ارزش بگیرن، یا noindex و حتی block بشن. auto-generated بدون کنترل، سم خاموش کراول باجته.

---

ساختار سایت و لینک سازی داخلی

کاهش Click Depth صفحات مهم

• سناریوی واقعی
  این مشکل معمولاً در سایت‌هایی دیده می‌شه که رشدشون ارگانیک و بدون معماری اولیه بوده؛ فروشگاه‌هایی که دسته‌ها لایه‌لایه اضافه شدن، سایت‌های محتوایی که سال‌ها مقاله منتشر کردن، یا پروژه‌هایی که چند بار ری‌دیزاین شدن بدون بازنگری ساختار. صفحات پول‌ساز یا استراتژیک گاهی ۴، ۵ یا حتی ۶ کلیک با صفحه اصلی فاصله دارن.
• رفتار گوگل
  Googlebot هم مثل کاربر از صفحه اصلی شروع می‌کنه و با هر کلیک، اولویت کم می‌شه. صفحات عمیق‌تر نه‌تنها دیرتر کراول می‌شن، بلکه دفعات کراول‌شون هم کمتره. این یعنی اگر صفحه‌ای پول‌سازه ولی عمیقه، عملاً تو صف انتظار مونده.
• تشخیص مشکل
  در Screaming Frog می‌تونی Click Depth رو مستقیم ببینی. معمولاً صفحات مهم تو عمق بالای ۳ قرار دارن. در لاگ سرور هم مشخصه که Googlebot کمتر به این URLها سر می‌زنه و فاصله بین crawlها زیاده.
• راه‌حل عملی
  صفحات کلیدی باید حداکثر در عمق ۲ یا ۳ باشن. این یعنی بازطراحی ساختار، افزودن لینک‌های contextual از صفحات قوی‌تر، و گاهی حتی بازتعریف منوها. کاهش Click Depth یکی از مستقیم‌ترین راه‌های افزایش crawl frequency برای صفحات مهمه.

تقویت لینک‌سازی داخلی صفحات ارزشمند

• سناریوی واقعی
  در بسیاری از سایت‌ها، لینک داخلی به‌صورت تصادفی توزیع شده. صفحات کم‌ارزش لینک زیاد دارن چون تو منو یا فوتر هستن، ولی صفحات پول‌ساز یا استراتژیک فقط یکی دو لینک پراکنده گرفتن.
• رفتار گوگل
  گوگل لینک داخلی رو به‌عنوان سیگنال اولویت کراول استفاده می‌کنه. صفحاتی که لینک داخلی بیشتری دارن، هم زودتر کراول می‌شن، هم بیشتر.
• تشخیص مشکل
  با تحلیل Inlinks در Screaming Frog یا ابزارهای مشابه می‌بینی صفحاتی که باید مهم باشن، لینک کمی دارن. در Crawl Stats هم این صفحات crawl rate پایینی دارن.
• راه‌حل عملی
  لینک‌سازی داخلی باید intentional باشه. صفحات ارزشمند باید از صفحات مرتبط، قوی و پرکراول لینک بگیرن. لینک contextual داخل محتوا بسیار مؤثرتر از لینک‌های تکراری فوتره.

حذف لینک داخلی به صفحات noindex

• سناریوی واقعی
  صفحات noindex معمولاً به‌صورت ناخواسته تو منو، فوتر یا لینک‌های داخلی باقی می‌مونن؛ مثل صفحات فیلترشده، نتایج جستجو، یا صفحات تشکر.
• رفتار گوگل
  گوگل لینک رو دنبال می‌کنه حتی اگر مقصد noindex باشه. یعنی بودجه کراول صرف صفحه‌ای می‌شه که از اول قرار نبوده ایندکس بشه.
• تشخیص مشکل
  در Screaming Frog صفحاتی با noindex ولی Inlinks بالا دیده می‌شن. در لاگ سرور هم Googlebot مرتب این URLها رو crawl می‌کنه.
• راه‌حل عملی
  صفحه noindex نباید لینک داخلی مهم بگیره. یا باید لینک‌ها حذف بشن، یا صفحه از مسیر کاربر جدا بشه. noindex بدون مدیریت لینک داخلی، نیمه‌کاره‌ست.

کنترل منوها و لینک‌های فوتر

• سناریوی واقعی
  سایت‌هایی با منوهای چندسطحی عظیم یا فوترهایی که صدها لینک دارن. این موضوع در سایت‌های شرکتی بزرگ، فروشگاه‌ها و پورتال‌ها شایعه.
• رفتار گوگل
  گوگل همه این لینک‌ها رو می‌بینه و crawl graph رو بر اساسشون می‌سازه. وقتی همه‌چیز مهمه، هیچ‌چیز مهم نیست. اولویت‌ها گم می‌شن.
• تشخیص مشکل
  در Crawl Map می‌بینی لینک‌ها بیش‌ازحد پخش شدن. صفحات کم‌ارزش crawl می‌شن هم‌سطح صفحات مهم.
• راه‌حل عملی
  منو و فوتر باید خلاصه، هدفمند و مبتنی بر اولویت تجاری باشن. لینک دادن به هر چیزی از این نواحی، یعنی اعلام اهمیت بالا به گوگل.

اولویت‌دهی ساختاری به صفحات پول‌ساز

• سناریوی واقعی
  صفحات بلاگی کم‌ارزش یا آرشیوها لینک بیشتری از صفحات فروش یا لندینگ‌های اصلی دارن، چون زودتر ساخته شدن یا تو قالب جا افتادن.
• رفتار گوگل
  گوگل ساختار رو جدی می‌گیره. اگر صفحه پول‌ساز در ساختار سایت جایگاه ضعیفی داشته باشه، رفتار کراول هم ضعیفه.
• تشخیص مشکل
  مقایسه crawl frequency صفحات پول‌ساز با صفحات کم‌ارزش در لاگ سرور. معمولاً اختلاف واضحه.
• راه‌حل عملی
  ساختار سایت باید بازتاب‌دهنده اولویت تجاری باشه. صفحات پول‌ساز باید نزدیک‌تر به ریشه، با لینک داخلی قوی‌تر و مسیر واضح‌تر باشن.

---

ریدایرکت و وضعیت پاسخ سرور

حذف Redirect Chain

• سناریوی واقعی
  این مشکل بیشتر در سایت‌هایی دیده می‌شه که چند بار مهاجرت داشتن؛ تغییر CMS، تغییر ساختار URL، HTTPS شدن، یا اصلاحات مقطعی بدون پاک‌سازی قبلی. نتیجه؟ URL A می‌ره به B، B می‌ره به C، و گاهی حتی C می‌ره به D. فروشگاه‌های قدیمی و سایت‌های محتوایی چندساله معمولاً قربانی اصلی‌ان.
• رفتار گوگل
  Googlebot ریدایرکت رو دنبال می‌کنه، اما نه بی‌نهایت. هر hop اضافه، هم latency ایجاد می‌کنه هم از crawl budget کم می‌کنه. زنجیره‌های طولانی باعث می‌شن گوگل کمتر به مقصد نهایی سر بزنه یا دیرتر.
• تشخیص مشکل
  Screaming Frog به‌وضوح redirect chain رو نشون می‌ده. در لاگ سرور هم می‌بینی چندین درخواست پشت‌سرهم برای رسیدن به یک URL نهایی ثبت شده. Crawl Stats معمولاً crawl time بالاتر از حد انتظار نشون می‌ده.
• راه‌حل عملی
  همیشه باید ریدایرکت‌ها flatten بشن. هر URL قدیمی باید مستقیم به مقصد نهایی ریدایرکت بشه. ریدایرکت زنجیره‌ای حتی اگر کوتاه باشه، در مقیاس بزرگ سم محسوب می‌شه.

کاهش ریدایرکت‌های غیرضروری

• سناریوی واقعی
  ریدایرکت‌های ظاهراً بی‌ضرر مثل اسلش آخر، حروف بزرگ و کوچک، پارامترهای تمیزنشده یا www/non-www نصف سایت رو درگیر می‌کنن، بدون اینکه کسی متوجه باشه.
• رفتار گوگل
  گوگل این ریدایرکت‌ها رو تحمل می‌کنه، ولی به‌عنوان هزینه اضافی. وقتی تعدادشون زیاد بشه، crawl efficiency افت می‌کنه.
• تشخیص مشکل
  در لاگ سرور تعداد بالای status code 301/302 در مسیرهای پرترافیک دیده می‌شه. Crawl Stats زمان دانلود صفحات بالا می‌ره.
• راه‌حل عملی
  باید یک نسخه canonical از URL در کل سایت enforce بشه. لینک داخلی، sitemap و canonical باید همگی به همون نسخه اشاره کنن تا ریدایرکت اصلاً اتفاق نیفته.

تبدیل 302های دائمی به 301

• سناریوی واقعی
  در خیلی از پروژه‌ها، 302 به‌عنوان راه‌حل موقت گذاشته شده و سال‌ها همون‌طور باقی مونده. مخصوصاً در کمپین‌ها، تغییر دسته‌ها یا اصلاح URLها.
• رفتار گوگل
  گوگل می‌گه 302 رو می‌فهمه، ولی در عمل سیگنال‌ها کندتر منتقل می‌شن و crawl priority مقصد پایین‌تره.
• تشخیص مشکل
  در Screaming Frog یا گزارش‌های سرور، URLهایی با 302 دائمی دیده می‌شن که ماه‌هاست تغییری نکردن.
• راه‌حل عملی
  اگر تغییر دائمیه، 301 بده. 302 فقط برای واقعاً موقته. استفاده اشتباه از 302 یعنی معلق نگه داشتن گوگل.

اصلاح خطاهای 5xx

• سناریوی واقعی
  این مشکل معمولاً در سایت‌های پرترافیک، فروشگاه‌ها در زمان کمپین، یا سرورهای ضعیف دیده می‌شه. خطاهایی که شاید کاربر نبینه ولی Googlebot می‌بینه.
• رفتار گوگل
  خطاهای 5xx مستقیماً crawl rate رو کاهش می‌دن. اگر تکرار بشن، گوگل عمداً کمتر سر می‌زنه تا به سرور فشار نیاره.
• تشخیص مشکل
  Search Console در بخش Crawl Stats افزایش error rate نشون می‌ده. لاگ سرور هم پر از 500، 502 یا 504 می‌شه.
• راه‌حل عملی
  پایداری سرور خط قرمز کراوله. مانیتورینگ uptime، بررسی resource usage و بهینه‌سازی backend ضروریه. هیچ تکنیک سئویی جای سرور سالم رو نمی‌گیره.

جلوگیری از Timeout

• سناریوی واقعی
  صفحات سنگین، کوئری‌های دیتابیس کند، یا JS بیش‌ازحد باعث می‌شن پاسخ سرور دیر برگرده. سایت‌های JS-heavy و فروشگاه‌های بزرگ اینجا ضربه می‌خورن.
• رفتار گوگل
  اگر پاسخ دیر برسه، Googlebot درخواست رو رها می‌کنه. این یعنی URL عملاً کراول نشده.
• تشخیص مشکل
  در لاگ سرور requestهای نیمه‌کاره یا timeout دیده می‌شن. Crawl Stats average response time بالا می‌ره.
• راه‌حل عملی
  بهینه‌سازی TTFB، کش سمت سرور، و کاهش محاسبات سنگین حیاتی‌ان. هر ثانیه تأخیر یعنی کراول کمتر.

---

سایت مپ

پاکسازی URLهای بی‌ارزش از Sitemap

• سناریوی واقعی
  این مشکل به‌طور خاص در سایت‌هایی دیده می‌شه که sitemap رو اتوماتیک ساختن و سال‌ها دست نزدن. فروشگاه‌ها، سایت‌های وردپرسی با پلاگین‌های پیش‌فرض، و سایت‌هایی که هر URL جدیدی رو بدون فیلتر وارد sitemap می‌کنن. نتیجه؟ sitemap پر از صفحات فیلترشده، پارامتری، noindex یا حتی 404.
• رفتار گوگل
  گوگل sitemap رو به‌عنوان لیست پیشنهادی کراول می‌بینه. وقتی URL بی‌ارزش زیاد باشه، اعتماد به sitemap کم می‌شه و سیگنال اولویت مخدوش می‌شه. یعنی حتی URLهای خوب هم دیرتر کراول می‌شن.
• تشخیص مشکل
  مقایسه sitemap با Coverage در Search Console نشون می‌ده تعداد زیادی URL ارسال‌شده، ایندکس نشده‌ان. پیام‌هایی مثل “Submitted URL not indexed” یا “Submitted URL has noindex” نشونه واضحه.
• راه‌حل عملی
  Sitemap باید فقط شامل URLهای ایندکس‌پذیر، canonical و ارزشمند باشه. هر URLی که noindex، ریدایرکت، پارامتری یا حذف‌شده‌ست، جاش تو sitemap نیست. sitemap تمیز یعنی کراول هدفمند.

تفکیک Sitemap بر اساس نوع محتوا

• سناریوی واقعی
  سایت‌های بزرگ معمولاً همه‌چیز رو تو یک sitemap می‌ریزن؛ مقاله، محصول، دسته، تگ، لندینگ. این اتفاق در سایت‌های محتوایی و فروشگاهی رایجه.
• رفتار گوگل
  وقتی sitemap تفکیک‌شده باشه، گوگل بهتر می‌فهمه کدوم نوع محتوا مهم‌تره و کدوم کمتر تغییر می‌کنه. این مستقیماً روی crawl frequency اثر داره.
• تشخیص مشکل
  در Search Console فقط یک sitemap ثبت شده که شامل هزاران URL ناهمگنه. تغییرات ایندکس هم نامنظمه.
• راه‌حل عملی
  تفکیک sitemap بر اساس نوع محتوا، مثل product، category، blog، landing. این کار هم تحلیل رو راحت‌تر می‌کنه، هم سیگنال اولویت‌دهی رو شفاف‌تر.

به‌روزرسانی واقعی lastmod

• سناریوی واقعی
  lastmod خیلی وقت‌ها یا همیشه یک تاریخه، یا با هر تغییر جزئی آپدیت می‌شه. هر دو حالت اشتباهه. این مشکل در سایت‌هایی که lastmod رو اتوماتیک می‌سازن زیاده.
• رفتار گوگل
  گوگل از lastmod برای تصمیم‌گیری کراول استفاده می‌کنه. اگر غیرواقعی باشه، یا نادیده گرفته می‌شه یا باعث کراول بی‌هدف می‌شه.
• تشخیص مشکل
  در Crawl Stats، صفحات بدون تغییر واقعی مدام کراول می‌شن. یا برعکس، صفحات مهم دیر به دیر.
• راه‌حل عملی
  lastmod فقط باید وقتی تغییر محتوایی معنادار اتفاق افتاده آپدیت بشه. نه تغییر view count، نه تغییر قیمت جزئی، نه اصلاح تایپو.

تطابق Sitemap با وضعیت ایندکس

• سناریوی واقعی
  سایت‌هایی که URL رو حذف یا noindex می‌کنن ولی همچنان تو sitemap نگه می‌دارن. این تضاد خیلی رایجه.
• رفتار گوگل
  گوگل تضاد سیگنال رو دوست نداره. وقتی sitemap می‌گه «بیا کراول کن» ولی صفحه می‌گه «ایندکس نکن»، نتیجه بی‌اعتمادیه.
• تشخیص مشکل
  Coverage پر از خطاهای مربوط به sitemap می‌شه. اختلاف شدید بین URLهای submitted و indexed دیده می‌شه.
• راه‌حل عملی
  هر تغییری در ایندکس‌پذیری باید در sitemap هم اعمال بشه. sitemap نباید عقب‌تر از تصمیمات سئویی باشه.

---

Robots و کنترل دسترسی کراولر

جلوگیری از بلاک منابع حیاتی CSS و JS

• سناریوی واقعی
  این مشکل بیشتر در سایت‌هایی دیده می‌شه که برای سبک شدن کراول، مسیرهای /wp-content/، /assets/ یا /static/ رو کورکورانه در robots.txt بلاک کردن. سایت‌های وردپرسی، SPAها و پروژه‌هایی که رندر فرانت‌اند براشون مهمه، بیشترین ریسک رو دارن.
• رفتار گوگل
  گوگل برای درک واقعی صفحه، نیاز به رندر داره. وقتی CSS یا JS بلاک باشه، صفحه به‌صورت ناقص رندر می‌شه و گوگل برداشت اشتباهی از محتوا، layout و حتی لینک‌ها پیدا می‌کنه. این یعنی کراول انجام شده، ولی عملاً بی‌کیفیت.
• تشخیص مشکل
  در Search Console بخش Page indexing یا URL inspection پیام‌هایی درباره blocked resources دیده می‌شه. در Mobile-Friendly Test یا Rich Results Test هم رندر ناقص مشخصه.
• راه‌حل عملی
  هیچ‌وقت منابع حیاتی رو بلاک نکن. robots.txt فقط برای مسیرهای واقعاً بی‌ارزشه، نه فایل‌هایی که برای درک صفحه لازمن. اگر فایلی برای سئو مهم نیست ولی برای رندر لازمه، بلاکش نکن.

بلاک هدفمند مسیرهای بی‌ارزش

• سناریوی واقعی
  سایت‌هایی با مسیرهای سیستمی مثل /cart/، /checkout/، /compare/، /user/، /panel/ یا آرشیوهای بی‌مصرف. این‌ها معمولاً ارزش ایندکس ندارن ولی شدیداً کراول می‌شن.
• رفتار گوگل
  اگر این مسیرها آزاد باشن، Googlebot بدون تعارف واردشون می‌شه. حتی اگر ایندکس نشن، کراول می‌شن و بودجه مصرف می‌کنن.
• تشخیص مشکل
  در لاگ سرور می‌بینی Googlebot مرتب این مسیرها رو می‌زنه. Coverage هم پر از Excluded می‌شه.
• راه‌حل عملی
  مسیرهای بی‌ارزش و غیرایندکس‌پذیر باید یا noindex بشن یا در صورت اطمینان کامل، از طریق robots.txt بلاک بشن. بلاک باید هدفمند باشه، نه گسترده و کور.

مدیریت آرشیوها (تگ، تاریخ، نویسنده)

• سناریوی واقعی
  وردپرس و CMSهای مشابه به‌صورت پیش‌فرض آرشیو تگ، تاریخ، نویسنده و ترکیب‌های مختلف می‌سازن. در سایت‌های محتوایی بزرگ، این آرشیوها هزاران URL کم‌ارزش تولید می‌کنن.
• رفتار گوگل
  گوگل این صفحات رو auto-generated می‌بینه. اگر زیاد باشن، هم کراول می‌شن هم ارزش ایندکسی ندارن و سیگنال کیفیت رو پایین می‌کشن.
• تشخیص مشکل
  Coverage پر از صفحات آرشیوی Excluded می‌شه. لاگ سرور نشون می‌ده Googlebot مرتب بین tagها و authorها می‌چرخه.
• راه‌حل عملی
  یا این آرشیوها باید curate بشن و واقعاً ارزش بگیرن، یا noindex بشن. در مواردی حتی بلاک در robots منطقیه، ولی فقط بعد از قطع لینک داخلی.

---

زیرساخت و عملکرد فنی

بهبود TTFB

• سناریوی واقعی
  این مشکل معمولاً در سایت‌های دیتابیس‌محور، فروشگاه‌های بزرگ، پروژه‌های وردپرسی سنگین و سایت‌هایی با هاست ضعیف یا معماری اشتباه دیده می‌شه. بیشتر در حوزه‌هایی مثل فروشگاه آنلاین، املاک، آگهی و SaaS که هر درخواست نیاز به پردازش داره.
• رفتار گوگل
  Googlebot به‌شدت به زمان پاسخ اولیه حساسه. وقتی TTFB بالا باشه، گوگل crawl rate رو به‌صورت خودکار کم می‌کنه تا به سرور فشار نیاره. یعنی حتی اگر URLها مهم باشن، کمتر کراول می‌شن.
• تشخیص مشکل
  در Crawl Stats، average response time بالاست. در لاگ سرور هم زمان پاسخ برای Googlebot مشابه یا بدتر از کاربره. ابزارهایی مثل PageSpeed Insights یا WebPageTest هم TTFB غیرعادی نشون می‌دن.
• راه‌حل عملی
  بهینه‌سازی بک‌اند، کش سمت سرور، بهبود دیتابیس، و در موارد جدی‌تر، تغییر معماری یا هاست. TTFB بالا یعنی گوگل به سایتت اعتماد زمانی نداره.

افزایش پایداری سرور

• سناریوی واقعی
  سایت‌هایی که روی منابع اشتراکی هستن، یا زیر بار کمپین‌ها، ترافیک ناگهانی یا بات‌ها ناپایدار می‌شن. این وضعیت در فروشگاه‌ها و سایت‌های خبری شایع‌تره.
• رفتار گوگل
  گوگل وقتی خطا یا ناپایداری ببینه، crawl رو کاهش می‌ده و حتی بعد از رفع مشکل هم با احتیاط برمی‌گرده.
• تشخیص مشکل
  نوسان crawl rate، افزایش خطاهای 5xx در Crawl Stats، و لاگ سرور پر از spikeهای error.
• راه‌حل عملی
  مانیتورینگ دائمی، auto-scaling، و جلوگیری از single point of failure. کراول پایدار بدون سرور پایدار وجود نداره.

مدیریت نسخه‌های دامنه

• سناریوی واقعی
  http/https، www/non-www، نسخه‌های موبایل قدیمی، یا دامنه‌های تست که هنوز در دسترسن. این مشکل در پروژه‌های قدیمی زیاد دیده می‌شه.
• رفتار گوگل
  گوگل همه نسخه‌ها رو کشف می‌کنه و برای تصمیم‌گیری بینشون کراول انجام می‌ده. این یعنی دوباره‌کاری.
• تشخیص مشکل
  Coverage و لاگ سرور نشون می‌ده Googlebot چند نسخه از یک محتوا رو می‌بینه.
• راه‌حل عملی
  فقط یک نسخه باید زنده باشه. بقیه یا ریدایرکت قطعی یا کاملاً بسته. دامنه تمیز یعنی کراول تمیز.

کاهش بار JS سنگین

• سناریوی واقعی
  سایت‌های SPA، React، Vue یا فروشگاه‌هایی با اسکریپت‌های تبلیغاتی زیاد. این مشکل در پروژه‌های مدرن خیلی رایجه.
• رفتار گوگل
  گوگل JS رو رندر می‌کنه، ولی با تأخیر و هزینه. هرچه JS سنگین‌تر، کراول کمتر و دیرتر.
• تشخیص مشکل
  در URL Inspection، render delay مشخصه. Crawl Stats هم crawl time بالا نشون می‌ده.
• راه‌حل عملی
  SSR یا dynamic rendering برای صفحات مهم، حذف اسکریپت‌های غیرضروری، و اولویت‌دهی به محتوای قابل crawl.

جلوگیری از Lazy Load مخرب

• سناریوی واقعی
  Lazy load اشتباه که محتوا یا لینک‌ها فقط بعد از interaction لود می‌شن. این اتفاق در قالب‌ها و پلاگین‌های آماده زیاده.
• رفتار گوگل
  اگر محتوا در viewport اولیه یا بدون JS در دسترس نباشه، گوگل ممکنه اصلاً نبینتش.
• تشخیص مشکل
  مقایسه HTML خام با DOM رندرشده. تفاوت فاحش یعنی خطر.
• راه‌حل عملی
  Lazy load فقط برای تصاویر و منابع غیرحیاتی. محتوا و لینک مهم باید همیشه در HTML اولیه باشه.

---

مانیتورینگ و تحلیل داده

تحلیل Crawl Stats در Search Console

• سناریوی واقعی
  بیشتر سایت‌ها این بخش رو فقط وقتی مشکل پیش میاد نگاه می‌کنن، نه به‌عنوان ابزار تصمیم‌سازی.
• رفتار گوگل
  Crawl Stats آینه رفتار Googlebotـه. افزایش، کاهش یا نوسانش معنی‌دارن.
• تشخیص مشکل
  کاهش crawl بدون تغییر ترافیک یا محتوا نشونه هشدار جدیه.
• راه‌حل عملی
  Crawl Stats باید دوره‌ای بررسی بشه، نه واکنشی. تغییراتش معمولاً قبل از افت رتبه اتفاق می‌افته.

تحلیل لاگ سرور

• سناریوی واقعی
  سایت‌های بزرگ بدون لاگ‌آنالیز عملاً کورن. این بیشتر در پروژه‌های فروشگاهی و پورتال‌ها خطرناکه.
• رفتار گوگل
  رفتار واقعی گوگل فقط در لاگ دیده می‌شه، نه در ابزارهای نمایشی.
• تشخیص مشکل
  با دیدن اینکه Googlebot دقیقاً کجا وقت می‌ذاره و کجا نه.
• راه‌حل عملی
  لاگ آنالیز منظم برای شناسایی هدررفت کراول، صفحات orphan، و اولویت واقعی گوگل.

شناسایی الگوهای هدررفت کراول

• سناریوی واقعی
  کراول روی URLهایی که هیچ ارزشی ندارن؛ پارامترها، آرشیوها، سرچ داخلی.
• رفتار گوگل
  اگر الگو باشه، گوگل ادامه می‌ده. اگر قطع بشه، مسیر رو عوض می‌کنه.
• تشخیص مشکل
  الگوهای تکراری در لاگ سرور.
• راه‌حل عملی
  بستن الگو، نه تک URL. درمان علامت فایده نداره.