گاهی در بررسی وضعیت ایندکس یک سایت وردپرسی با صحنهای عجیب مواجه میشویم: بهجای اینکه گوگل فقط مقالات، صفحات خدمات و محتوای اصلی سایت را نمایش دهد، URLهایی مانند wp-includes، wp-content/plugins، فایلهای CSS و JavaScript و حتی صفحات Index of در نتایج جستجو دیده میشوند.
این اتفاق دقیقاً برای سایت Mafia GP رخ داد.
در جستجوی عبارت site:mafiagp.ir مشخص شد که تعداد قابل توجهی از URLهای سایت در گوگل ایندکس شدهاند که هیچ ارتباطی با محتوای اصلی سایت ندارند؛ برای مثال:
/wp-includes/css/dist/customize-widgets//wp-includes/js/dist/script-modules//wp-includes/css/dist/reusable-blocks//wp-includes/css/dist/block-directory//wp-includes/js/tinymce/plugins/wpeditimage//wp-content/plugins/elementskit/modules/header-footer/assets//wp-content/plugins/elementskit/libs/framework/
برخی از این URLها حتی صفحهای با عنوان Index of نمایش میدادند و فایلهای داخلی پوشههای وردپرس را در معرض مشاهده قرار میدادند.
این مقاله یک بررسی موردی واقعی از این مشکل است؛ از تشخیص علت تا جلوگیری از ایندکس مجدد و حذف URLهای نامرتبط از نتایج گوگل.
مشکل دقیقاً چه بود؟
در حالت عادی، فایلها و پوشههای داخلی وردپرس نباید به شکل صفحات قابل ایندکس در نتایج جستجوی گوگل ظاهر شوند.
اما در این سایت، دسترسی مستقیم به بعضی از پوشهها باعث میشد سرور بهجای نمایش خطای 403 یا جلوگیری از دسترسی، یک Directory Listing نمایش دهد.
برای مثال، مراجعه به چنین آدرسی:
/wp-includes/css/dist/customize-widgets/
بهجای دریافت خطای دسترسی، صفحهای با عنوان:
Index of /wp-includes/css/dist/customize-widgets/
نمایش داده میشد.
در نتیجه گوگل میتوانست این URL را مانند یک صفحه وب معمولی مشاهده و در صورت مناسب بودن شرایط، آن را وارد ایندکس کند.
چرا عبارت Index of مهم است؟
عبارت Index of معمولاً نشانه فعال بودن Directory Listing روی سرور است.
وقتی Directory Listing فعال باشد و یک پوشه فایل index مناسب نداشته باشد، سرور ممکن است فهرست فایلها و پوشههای داخل آن را به کاربر نمایش دهد.
برای یک سایت وردپرسی، نمایش عمومی چنین مسیرهایی معمولاً مطلوب نیست؛ بهخصوص وقتی این مسیرها مربوط به فایلهای سیستمی، افزونهها و منابع داخلی سایت باشند.
آیا ایندکس شدن wp-includes و wp-content برای سئو بد است؟
باید بین دو موضوع تفاوت قائل شویم.
صرف وجود فایلهای CSS، JavaScript یا فایلهای داخلی وردپرس در وب بهخودیخود یک جریمه سئویی محسوب نمیشود.
اما ایندکس شدن تعداد زیادی URL بیارزش و غیرمرتبط میتواند وضعیت سایت را از نظر فنی و مدیریتی نامطلوب کند.
در این کیس، مشکل اصلی فقط «تعداد صفحات ایندکسشده» نبود؛ بلکه این بود که گوگل به URLهایی دسترسی پیدا کرده بود که اساساً قرار نبود بهعنوان صفحات محتوایی سایت در نتایج جستجو ظاهر شوند.
مشکلاتی که این وضعیت ایجاد میکند
۱. افزایش URLهای بیارزش در ایندکس
بهجای اینکه تمرکز ایندکس روی صفحات مهم سایت باشد، URLهای مربوط به فایلها و پوشههای سیستمی نیز وارد تصویر میشوند.
۲. ایجاد Index Bloat
اگر تعداد زیادی URL کمارزش یا غیرضروری توسط موتور جستجو شناسایی و ایندکس شوند، میتوانیم با چیزی مواجه شویم که در سئو به آن Index Bloat گفته میشود.
البته نباید هر URL اضافی را بهصورت خودکار Index Bloat دانست؛ اما در این کیس، حجم قابل توجه URLهای سیستمی و غیرمحتوایی ارزش سئویی برای سایت نداشتند.
۳. نمایش نتایج نامرتبط برای جستجوی برند
یکی از مهمترین نشانههای این مشکل این بود که با جستجوی:
site:mafiagp.ir
تعداد زیادی نتیجه نامرتبط با محتوای اصلی سایت مشاهده میشد.
این موضوع باعث میشود بررسی وضعیت واقعی ایندکس سایت دشوارتر شود.
۴. افشای ساختار فایلها
فعال بودن Directory Listing فقط مسئله SEO نیست.
وقتی ساختار پوشهها و فایلهای سایت بهصورت عمومی نمایش داده میشود، اطلاعات بیشتری درباره ساختار WordPress، افزونهها و فایلهای موجود روی سرور در اختیار کاربران قرار میگیرد.
بنابراین بهتر است این مشکل از دید امنیت و Hardening وردپرس نیز بررسی شود.
علت اصلی مشکل چه بود؟
در بررسی سایت مشخص شد مسئله فقط robots.txt نبود.
مشکل اصلی این بود که بعضی پوشهها از سمت سرور به شکل قابل مشاهده در دسترس بودند و Directory Listing امکان نمایش محتویات آنها را فراهم میکرد.
به زبان ساده:
گوگل URL را پیدا میکرد → URL باز میشد → سرور محتوای پوشه را نمایش میداد → گوگل صفحه را میدید → URL میتوانست وارد فرآیند ایندکس شود.
بنابراین صرفاً اضافه کردن Disallow در robots.txt راهحل کامل نیست.
robots.txt چه نقشی در حل مشکل دارد؟
در این سایت، فایل robots.txt شامل دستور زیر است:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /search/
Disallow: /?s=
Disallow: /page/*/?s=
Disallow: /wp-content/uploads/wc-logs/
Disallow: /wp-content/uploads/woocommerce_transient_files/
وجود:
Disallow: /wp-includes/
برای جلوگیری از Crawl شدن این مسیر توسط رباتها مفید است.
اما یک نکته بسیار مهم وجود دارد:
robots.txt ابزار حذف URL از ایندکس نیست.
اگر URL قبلاً توسط گوگل شناخته یا ایندکس شده باشد، صرفاً قرار دادن آن در robots.txt الزاماً باعث حذف آن از نتایج نمیشود.
حتی اگر URL را در robots.txt مسدود کنیم، گوگل ممکن است URL را بدون Crawl مجدد همچنان بشناسد.
بنابراین باید مشکل را در چند مرحله حل کرد.
مرحله اول؛ جلوگیری از نمایش Directory Listing
اولین و مهمترین کار این است که سرور دیگر فهرست فایلهای یک پوشه را نمایش ندهد.
در Apache میتوان از این دستور استفاده کرد:
Options -Indexes
این دستور باعث میشود وقتی کاربر مستقیماً وارد یک پوشه بدون فایل index میشود، بهجای نمایش فهرست فایلها، دسترسی به Directory Listing متوقف شود.
در نتیجه URLهایی مانند:
/wp-includes/css/dist/customize-widgets/
دیگر نباید صفحهای با عنوان Index of نمایش دهند.
اگر سرور LiteSpeed باشد چه؟
LiteSpeed نیز از بسیاری از دستورات Apache و .htaccess پشتیبانی میکند.
اما بهتر است قبل از اعمال تغییرات گسترده، مطمئن شوید تنظیمات سرور اجازه استفاده از Options -Indexes را میدهد.
اگر پس از اضافه کردن این دستور با خطای 403 مواجه شدید، الزاماً به این معنی نیست که مشکل جدیدی ایجاد شده است.
اتفاقاً در سناریوی ما، 403 برای این مسیرها میتواند رفتار مطلوبی باشد؛ چون هدف این است که فایلهای داخلی وردپرس بهعنوان صفحه عمومی در دسترس نباشند.
مرحله دوم؛ جلوگیری از Crawl شدن مسیرهای سیستمی
بعد از اصلاح دسترسی سرور، میتوان مسیرهای غیرضروری را در robots.txt نیز مسدود کرد.
برای مثال:
Disallow: /wp-includes/
و در صورت نیاز، مسیرهای خاص دیگری که نباید توسط موتورهای جستجو Crawl شوند.
اما بهتر است robots.txt را بیش از حد محدودکننده نکنیم.
برای مثال، مسدود کردن کل /wp-content/ بدون بررسی دقیق میتواند تصمیم مناسبی نباشد؛ زیرا داخل این مسیر فایلهای مهمی مانند تصاویر و منابع مورد استفاده صفحات سایت نیز قرار دارند.
بنابراین:
wp-includes و مسیرهای واقعاً سیستمی را هدف قرار دهید، نه اینکه کورکورانه تمام wp-content را مسدود کنید.
این نکته یکی از مهمترین بخشهای این کیس است.
مرحله سوم؛ بررسی وضعیت URLهای ایندکسشده در Google
بعد از اصلاح سرور و robots.txt، باید ببینیم چه URLهایی قبلاً توسط گوگل شناخته شدهاند.
یکی از سریعترین روشهای بررسی اولیه:
site:mafiagp.ir
است.
اما برای بررسی دقیقتر باید از Google Search Console استفاده کرد.
در Search Console میتوان بخشهای مربوط به Pages / Indexing را بررسی کرد و URLهای مربوط به مسیرهای سیستمی را پیدا کرد.
برای بررسیهای تخصصیتر، استفاده از یک چکلیست منظم Technical SEO نیز کمک میکند تا مشکل فقط از زاویه ایندکس بررسی نشود و سایر خطاهای فنی سایت نیز از قلم نیفتند.
مطالعه بیشتر
- Social Channels Insights در Google Search Console: برای آشنایی با قابلیت جدید Social Channels Insights و اطلاعاتی که Google Search Console درباره عملکرد شبکههای اجتماعی ارائه میدهد.
مرحله چهارم؛ حذف URLهای قبلی از نتایج گوگل
اگر URLهای غیرضروری قبلاً در نتایج گوگل نمایش داده شدهاند، باید آنها را جداگانه مدیریت کرد.
در Google Search Console میتوانید از بخش Removals برای درخواست حذف موقت URLها از نتایج استفاده کنید.
این ابزار برای حذف سریعتر نتایج فعلی مفید است، اما نباید آن را جایگزین اصلاح فنی سایت دانست.
یعنی این کار اشتباه است:
URL را Remove کنیم و مشکل سرور را رها کنیم.
چون اگر URL همچنان قابل دسترسی باشد، احتمال دارد گوگل دوباره آن را پیدا کند.
ترتیب صحیح این است:
اصلاح سرور → جلوگیری از تولید/نمایش URL → کنترل Crawl → حذف نتایج قبلی → پایش مجدد
آیا باید تکتک URLها را حذف کنیم؟
اگر تعداد URLها کم باشد، میتوان URLهای خاص را بررسی کرد.
اما وقتی صدها URL مشابه در یک مسیر وجود دارد، بهتر است بهجای برخورد دستی با تکتک آنها، ریشه مشکل را برطرف کنیم.
برای مثال اگر دهها URL زیر این ساختار وجود داشته باشد:
/wp-includes/...
بهتر است ابتدا مشکل دسترسی و Crawl این مسیر را حل کنیم.
در غیر این صورت، حذف تکتک URLها فقط یک کار تکراری و موقتی خواهد بود.
مرحله پنجم؛ بررسی Status Code URLها
یکی از مهمترین کارهایی که در این کیس باید انجام شود، بررسی Status Code URLهای مشکلدار است.
برای URLهای سیستمی که قرار نیست صفحه عمومی باشند، بهتر است رفتار سرور مشخص و قابل پیشبینی باشد.
مثلاً اگر مسیر:
/wp-includes/css/dist/customize-widgets/
دیگر نباید بهعنوان یک صفحه عمومی قابل مشاهده باشد، نباید همچنان یک صفحه HTML با عنوان Index of تحویل دهد.
بعد از اصلاح، باید با ابزارهایی مانند HTTP Header Checker یا ابزارهای Crawl، وضعیت پاسخ را بررسی کرد.
هدف این است که URL مشکلدار دیگر به شکل یک صفحه قابل ایندکس در اختیار Googlebot قرار نگیرد.
مرحله ششم؛ پاک کردن Cache
اگر روی سایت از افزونههایی مانند WP Rocket استفاده میکنید، بعد از تغییر تنظیمات سرور و .htaccess بهتر است Cache سایت نیز بررسی و در صورت نیاز پاک شود.
در این کیس، نباید Cache باعث شود نسخه قدیمی پاسخها همچنان در دسترس باشد.
بنابراین بعد از تغییرات:
- Cache افزونه را پاک کنید.
- Cache سمت سرور را بررسی کنید.
- اگر CDN دارید، Cache آن را نیز بررسی کنید.
- URL مشکلدار را در مرورگر ناشناس تست کنید.
- Status Code و محتوای پاسخ را بررسی کنید.
یک اشتباه مهم: فقط robots.txt را تغییر ندهید
یکی از رایجترین اشتباهات در چنین شرایطی این است که مدیر سایت بلافاصله وارد robots.txt میشود و مسیر مشکلدار را Disallow میکند.
مثلاً:
Disallow: /wp-includes/
و تصور میکند مشکل تمام شده است.
اما این فقط بخشی از کار است.
اگر گوگل URL را قبلاً پیدا کرده باشد، Disallow بهتنهایی تضمین نمیکند که URL از نتایج جستجو حذف شود.
از طرف دیگر، اگر Directory Listing همچنان فعال باشد، مشکل زیرساختی سایت نیز باقی مانده است.
پس باید این دو موضوع را از هم جدا کنیم:
کنترل Crawl
با robots.txt
کنترل دسترسی و نمایش محتوا
با تنظیمات سرور و .htaccess
این دو ابزار وظایف متفاوتی دارند.
نتیجه بررسی سایت Mafia GP
در این کیس، با جستجوی:
site:mafiagp.ir
بیش از ۱۰۰ نتیجه مرتبط با مسیرهای داخلی WordPress و افزونهها مشاهده شد.
نمونههایی مانند:
/wp-includes/css/dist/customize-widgets/
/wp-includes/js/dist/script-modules/
/wp-includes/css/dist/reusable-blocks/
/wp-includes/css/dist/block-directory/
/wp-includes/js/tinymce/plugins/wpeditimage/
/wp-content/plugins/elementskit/modules/header-footer/assets/
/wp-content/plugins/elementskit/libs/framework/
در بسیاری از این URLها نیز صفحهای شبیه Directory Listing یا Index of قابل مشاهده بود.
این نشان میدهد که مسئله فقط یک خطای ساده در Search Console نبود؛ بلکه یک مشکل ترکیبی شامل:
Directory Listing + دسترسی عمومی به مسیرهای داخلی + Crawl شدن URLها + ورود URLهای غیرمحتوایی به نتایج گوگل
وجود داشت.
چکلیست حل مشکل
اگر با مشکل مشابهی مواجه شدید، این مراحل را بهترتیب انجام دهید:
۱. با site: سایت را بررسی کنید
site:example.com
به دنبال URLهایی مانند موارد زیر باشید:
/wp-includes/
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/
/Index of/
۲. یکی از URLهای مشکلدار را مستقیم باز کنید
بررسی کنید آیا صفحه واقعاً باز میشود یا با خطای 403/404 مواجه میشوید.
۳. Directory Listing را غیرفعال کنید
در Apache/LiteSpeed در صورت پشتیبانی:
Options -Indexes
۴. robots.txt را بررسی کنید
برای مسیرهای سیستمی غیرضروری، Crawl را کنترل کنید.
۵. کل wp-content را کورکورانه مسدود نکنید
چون ممکن است منابع موردنیاز سایت داخل آن قرار داشته باشند.
۶. URLهای ایندکسشده قبلی را در Search Console بررسی کنید
بهخصوص در گزارش Pages و بخش Removals.
۷. Cache را پاک کنید
WP Rocket، سرور و CDN در صورت استفاده.
۸. URLهای اصلاحشده را دوباره تست کنید
مطمئن شوید دیگر Directory Listing نمایش داده نمیشود.
۹. چند روز و چند هفته وضعیت ایندکس را پایش کنید
تغییرات ایندکس گوگل همیشه بلافاصله اتفاق نمیافتد.
۱۰. بعد از مدتی دوباره site: را بررسی کنید
هدف این نیست که صرفاً امروز تعداد نتایج کم شود؛ هدف این است که منبع تولید و Crawl شدن URLهای بیارزش برای همیشه برطرف شود.
آیا این مشکل باعث جریمه گوگل میشود؟
نباید از مشاهده این URLها فوراً نتیجه گرفت که سایت توسط گوگل جریمه شده است.
وجود چند URL سیستمی در نتایج جستجو بهتنهایی به معنی Penalty نیست.
اما اگر تعداد زیادی URL غیرضروری، صفحات تکراری، صفحات بیمحتوا یا مسیرهای سیستمی وارد ایندکس شدهاند، باید آن را بهعنوان یک مشکل فنی SEO جدی بررسی کرد.
در واقع، مهمتر از ترس از جریمه، این است که بفهمیم:
چرا Googlebot اصلاً توانسته این URLها را پیدا و Crawl کند؟
وقتی علت مشخص شد، اصلاح آن بسیار منطقیتر از حذف دستی صدها URL است.
مهمترین درس این کیس استادی
این تجربه یک نکته مهم برای سئوکارها و مدیران سایتهای وردپرسی دارد:
هر URL ای که در گوگل دیده میشود الزاماً یک صفحه واقعی از سایت نیست.
گاهی یک تنظیم اشتباه روی سرور، Directory Listing، پارامترهای URL، فایلهای افزونهها یا ساختارهای داخلی WordPress میتواند صدها URL جدید ایجاد کند.
به همین دلیل، بررسی site: باید فقط برای شمارش صفحات استفاده نشود.
بلکه باید به ساختار URLهای نمایشدادهشده نیز دقت کنیم.
اگر ناگهان در نتایج گوگل چیزهایی مانند:
Index of
wp-includes
wp-content/plugins
wp-content/themes
assets
css
js
framework
dist
دیدید، بهتر است قبل از اینکه شروع به حذف دستی URLها کنید، منبع تولید این URLها را پیدا کنید.
جمعبندی
در کیس سایت Mafia GP، مشکل اصلی مشاهده تعداد زیادی URL نامرتبط با محتوای سایت در نتایج گوگل بود؛ URLهایی که عمدتاً به مسیرهای داخلی WordPress و فایلهای افزونهها مربوط میشدند.
بررسی دقیق نشان داد که مشکل را نباید فقط با robots.txt حل کرد.
راهکار اصولی شامل چند مرحله است:
۱. غیرفعال کردن Directory Listing
۲. کنترل دسترسی به مسیرهای سیستمی
۳. تنظیم صحیح robots.txt
۴. بررسی URLهای قبلاً ایندکسشده
۵. حذف URLهای غیرضروری از Search Console در صورت نیاز
۶. پاک کردن Cache
۷. بررسی مجدد Status Code و رفتار URLها
۸. پایش مستمر Indexing
نکته کلیدی این است که حذف URL از گوگل آخرین مرحله نیست؛ پیدا کردن علت ایجاد و قابل Crawl شدن آن URLها مهمتر است.
اگر مشکل از سمت سرور برطرف نشود، حتی بعد از حذف URLهای فعلی، احتمال تولید و ایندکس شدن URLهای مشابه در آینده وجود دارد.
برای سایتهای وردپرسی، بررسی چنین مشکلاتی باید بخشی از فرآیند Technical SEO باشد و در کنار مواردی مثل Crawlability، Indexability، Sitemap، Canonical و Core Web Vitals بررسی شود.
در نهایت، اگر با یک جستجوی ساده site: متوجه شدید گوگل تعداد زیادی فایل و پوشه داخلی سایت شما را نمایش میدهد، آن را نادیده نگیرید؛ ابتدا مشخص کنید گوگل این URLها را از کجا پیدا کرده و سرور در مقابل آنها چه پاسخی میدهد.
