WordPress کی robots.txt فائل میں کیا ہونا چاہیے؟

چار چیزیں اور بس: ایک وائلڈ کارڈ user-agent لائن، /wp-admin/ کے لیے Disallow، /wp-admin/admin-ajax.php کے لیے Allow، اور آپ کے مکمل سائٹ میپ URL کی طرف اشارہ کرتی ایک Sitemap ہدایت۔ اس سے آگے سب کچھ اختیاری ہے اور آن لائن گھومتی زیادہ تر لمبی بلاک لسٹیں فائدے سے زیادہ نقصان کرتی ہیں۔

کیا WordPress خودبخود robots.txt فائل بناتا ہے؟

ہاں، مگر صرف ورچوئل۔ جب /robots.txt پر درخواست آتی ہے اور ڈسک پر کوئی حقیقی فائل موجود نہیں ہوتی تو WordPress جواب میموری میں تیار کرتا ہے۔ اس میں wp-admin کے قواعد شامل ہوتے ہیں اور ورژن 5.5 سے wp-sitemap.xml کے لیے ایک Sitemap لائن بھی۔ آپ کے سرور پر کچھ لکھا نہیں جاتا۔

میری robots.txt وہ کیوں نہیں دکھاتی جو WordPress کو دکھانا چاہیے؟

تقریباً ہمیشہ اس لیے کہ آپ کی ویب روٹ میں ایک جسمانی robots.txt فائل موجود ہے۔ ویب سرور وہی فائل براہِ راست پیش کر دیتا ہے اور WordPress چلتا ہی نہیں، اس لیے ورچوئل آؤٹ پٹ اور robots_txt فلٹر دونوں خاموشی سے نظرانداز ہو جاتے ہیں۔ کچھ اور ڈیبگ کرنے سے پہلے اپنی سائٹ کی جڑ میں اصل فائل تلاش کریں۔

کیا مجھے robots.txt میں wp-content یا wp-includes بلاک کرنا چاہیے؟

نہیں۔ ان ڈائریکٹریوں میں وہی CSS، جاوا اسکرپٹ اور تصاویر ہوتی ہیں جن کے بغیر آپ کے صفحات بن ہی نہیں سکتے۔ انہیں بلاک کرنے سے Google یہ اثاثے حاصل نہیں کر پاتا، اس لیے وہ آپ کے لے آؤٹ کا ٹوٹا ہوا نمونہ دیکھ کر فیصلہ کرتا ہے۔ برسوں پہلے یہ عام مشورہ تھا اور اب یہ باقاعدہ نقصان دہ ہے۔

کیا robots.txt کسی صفحے کو Google سے باہر رکھ سکتی ہے؟

نہیں۔ Robots.txt کرالنگ کو کنٹرول کرتی ہے، انڈیکسنگ کو نہیں۔ بلاک کیا گیا URL پھر بھی انڈیکس ہو سکتا ہے اگر دوسرے صفحات اس سے لنک کرتے ہوں، اور وہ نتائج میں بغیر تفصیل کے ظاہر ہوگا۔ کسی صفحے کو انڈیکس سے باہر رکھنے کے لیے کرالنگ کی اجازت دیں اور اس کے بجائے noindex میٹا روبوٹس ٹیگ یا X-Robots-Tag ہیڈر پیش کریں۔

کیا robots.txt کوئی حفاظتی اقدام ہے؟

نہیں، بلکہ الٹا۔ یہ فائل yoursite.com/robots.txt پر سب کے لیے کھلی ہے اور کوئی بھی اسے پڑھ سکتا ہے، اس لیے کسی نجی ڈائریکٹری کا ذکر کرنا اس کا پتہ بتانے کے مترادف ہے۔ شریف کرالرز اس کی پابندی اپنی مرضی سے کرتے ہیں اور بدنیت اسکینرز اسے بالکل نظرانداز کرتے ہیں۔ حساس راستوں کی حفاظت تصدیق یا سرور قواعد سے کریں۔

2026 میں WordPress robots.txt کا بہترین طریقہ (اس میں اصل میں کیا ڈالنا چاہیے)

ایک اچھی WordPress robots.txt تقریباً پانچ سطروں کی ہوتی ہے۔ /wp-admin/ بلاک کریں، admin-ajax.php کی اجازت دیں، کرالرز کو اپنے سائٹ میپ کی طرف بھیجیں، اور بس یہیں رک جائیں — فورمز پر ملنے والی چالیس سطروں والی پھیلی ہوئی بلاک لسٹیں زیادہ تر یا تو رینڈرنگ خراب کرتی ہیں یا کچھ بھی نہیں کرتیں۔ پوری فائل یہ ہے:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml

ڈومین بدل لیں، اور اگر آپ کوئی ایسا SEO پلگ اِن استعمال کرتے ہیں جو سائٹ میپ خود سنبھالتا ہے تو Sitemap لائن کو اُس پلگ اِن کے انڈیکس کی طرف موڑ دیں۔ بس اتنا ہی۔ اگر آپ کی فائل اس سے لمبی ہے تو اضافی سطریں غالباً آپ کو کچھ نہ کچھ مہنگی پڑ رہی ہیں۔

WordPress پہلے ہی ایک بنا دیتا ہے — جب تک آپ اصل فائل نہ بنائیں

WordPress ایک ورچوئل robots.txt کے ساتھ آتا ہے۔ جب /robots.txt کے لیے درخواست آتی ہے اور آپ کی ویب روٹ پر کوئی اصل فائل موجود نہیں ہوتی، تو WordPress درخواست کو پکڑ کر جواب میموری میں تیار کر کے دکھا دیتا ہے۔ ڈسک پر کچھ نہیں لکھا جاتا۔ ڈیفالٹ آؤٹ پٹ وہی اوپر والا wp-admin بلاک ہے، اور ساتھ wp-sitemap.xml کے لیے ایک Sitemap: لائن جو کور WordPress 5.5 سے دے رہا ہے۔

دو چیزیں اس آؤٹ پٹ کو بدل دیتی ہیں۔ اگر Settings → Reading → Discourage search engines from indexing this site پر نشان لگا ہو تو WordPress پوری فائل کی جگہ Disallow: / رکھ دیتا ہے، جو سب کچھ بلاک کر دیتا ہے۔ لانچ کے بعد سائٹ کے سرچ سے غائب ہو جانے کی سب سے عام وجہ یہی چیک باکس ہے۔ دوسری بات، پلگ اِنز اور تھیمیں robots_txt فلٹر کے ذریعے ورچوئل آؤٹ پٹ بدل سکتی ہیں، اور SEO پلگ اِنز اسی طرح اپنی سائٹ میپ لائنیں اور قواعد شامل کرتے ہیں۔

اب وہ حصہ جو لوگوں کی دوپہریں کھا جاتا ہے۔ آپ کی ویب روٹ میں پڑی جسمانی robots.txt فائل خاموشی سے اِن سب پر بھاری پڑتی ہے۔ آپ کا ویب سرور ڈسک پر اصل فائل پاتا ہے، اسے پیش کر دیتا ہے، اور WordPress لوڈ ہی نہیں ہوتا۔ ورچوئل جنریٹر نہیں چلتا۔ robots_txt فلٹر نہیں چلتا۔ آپ کا SEO پلگ اِن اپنے robots.txt ایڈیٹر میں شاید ایک خوبصورت انٹرفیس اور درست قواعد دکھاتا رہے، اور ان میں سے کچھ بھی کسی کرالر تک نہ پہنچے۔

قواعد کہاں ہیں	WordPress ایڈمن میں ایڈٹ ہو سکتے ہیں	لائیو درخواست پر کون جیتتا ہے
ورچوئل (ڈسک پر کوئی فائل نہیں)	ہاں، `robots_txt` فلٹر یا کسی پلگ اِن کے ذریعے	صرف تب جب کوئی جسمانی فائل موجود نہ ہو
ویب روٹ میں جسمانی فائل	صرف تب جب پلگ اِن ڈسک پر لکھتا ہو	ہمیشہ

تو کچھ بھی ڈیبگ کرنے سے پہلے: براؤزر میں https://yoursite.com/robots.txt کھولیں، پھر SFTP یا اپنے ہوسٹ کے فائل مینیجر سے جڑ کر دیکھیں کہ wp-config.php اور .htaccess کے پہلو میں کوئی اصل robots.txt تو نہیں پڑی۔ اگر ہے، تو وہی آپ کی robots.txt ہے۔ یا اسے وہیں ایڈٹ کریں یا حذف کر کے WordPress کو سنبھالنے دیں — مگر ایک ہی راستہ چنیں۔ دونوں ساتھ چلانے سے ہی سائٹس پر ایسا پرانا سائٹ میپ URL رہ جاتا ہے جو کسی کو ملتا نہیں۔

/wp-admin/ کیوں بلاک ہے مگر admin-ajax.php کی اجازت ہے

/wp-admin/ میں ڈیش بورڈ ہوتا ہے۔ یہ URLs سرچ نتائج میں بےکار ہیں اور انہیں کرال کرنا اُن صفحات پر کرال بجٹ ضائع کرتا ہے جو لاگ اِن اسکرین پر بھیج دیتے ہیں۔ اس ڈائریکٹری کو بلاک کرنے پر کوئی اختلاف نہیں۔

admin-ajax.php اسی ڈائریکٹری میں ہے مگر یہ ایڈمن صفحہ نہیں ہے۔ یہ وہ اینڈ پوائنٹ ہے جسے پلگ اِنز اور تھیمیں فرنٹ اینڈ کی AJAX درخواستوں کے لیے استعمال کرتی ہیں — “مزید لوڈ کریں” بٹن، فلٹر ہونے والے پروڈکٹ گرڈ، کیلکولیٹر، فارم۔ اگر کرالر اسے حاصل نہ کر سکے تو وہ اُس مواد کو نہیں دیکھ پاتا جو یہ فیچرز لاتے ہیں، اور Google آپ کا صفحہ ویسے ہی رینڈر کرتا ہے جیسے کوئی وزیٹر اُس ٹوٹے ہوئے فیچر کے ساتھ دیکھتا۔

آپ کی مخصوص سائٹ پر Google کو واقعی admin-ajax.php حاصل کرنے کی ضرورت ہے یا نہیں، اس کا انحصار اس پر ہے کہ آپ کا فرنٹ اینڈ اسے استعمال کرتا ہے یا نہیں۔ سچ یہ ہے: بہت سی جدید سائٹس پر اس سے کوئی فرق نہیں پڑتا، کیونکہ تھیم /wp-json/ پر REST API استعمال کرتی ہے۔ Allow لائن ایک حقیقی خرابی کے خلاف سستی انشورنس ہے، کوئی رینکنگ فیکٹر نہیں۔ اسے رہنے دیں کیونکہ اس کی کوئی قیمت نہیں۔

/wp-content/ یا /wp-includes/ کو بلاک نہ کریں

robots.txt کے بارے میں آج بھی گردش کرتا یہ سب سے برا مشورہ ہے، اور یہ اُس دور کا ہے جب Google صفحات رینڈر نہیں کرتا تھا۔

/wp-content/ میں آپ کی تھیمیں، پلگ اِنز اور اپلوڈز ہوتے ہیں — یعنی وہ اسٹائل شیٹس، اسکرپٹس اور تصاویر جن کی وجہ سے آپ کے صفحات صفحات لگتے ہیں۔ /wp-includes/ میں کور کی جاوا اسکرپٹ ہوتی ہے جس پر پلگ اِنز کا انحصار ہوتا ہے۔ Google فیصلہ کرنے سے پہلے آپ کے صفحات کو ہیڈ لیس براؤزر میں رینڈر کرتا ہے۔ ان ڈائریکٹریوں کو بلاک کریں تو رینڈرر کو ایسا صفحہ ملتا ہے جس میں نہ CSS ہے نہ تصاویر۔ Google جس چیز کو پرکھتا ہے وہ بغیر اسٹائل کے متن کی ایک دیوار اور ٹوٹا ہوا لے آؤٹ ہے، جو اس کے آپ کے مواد کو سمجھنے اور موبائل یوزیبلٹی کے اسکور دونوں پر اثر ڈالتا ہے۔

اگر آپ کو ورثے میں ایسی فائل ملی ہے جس میں یہ سطریں ہیں تو انہیں حذف کر دیں:

Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/

آپ یہ نقصان خود Google Search Console کے URL Inspection ٹول میں دیکھ سکتے ہیں۔ کسی بھی صفحے پر لائیو ٹیسٹ چلائیں، رینڈر شدہ اسکرین شاٹ دیکھیں، اور صفحے کے وسائل کی فہرست میں بلاک شدہ اشیاء جانچیں۔ اگر آپ کی CSS بلاک شدہ دکھائی دے تو وجہ یہی ہے۔

Sitemap ہدایت

ایک سطر، مکمل URL، اور یہ فائل میں کہیں بھی ہو سکتی ہے — یہ کسی User-agent گروپ سے بندھی ہوئی نہیں۔

Sitemap: https://example.com/wp-sitemap.xml

وہی URL استعمال کریں جو واقعی کھلتا ہو۔ WordPress کور wp-sitemap.xml پیش کرتا ہے۔ زیادہ تر SEO پلگ اِنز کور کے سائٹ میپ بند کر کے اپنا انڈیکس کسی اور راستے پر دیتے ہیں، عموماً sitemap_index.xml پر۔ اپنا URL طے کرنے سے پہلے اسے براؤزر میں کھول لیں — 404 کی طرف اشارہ کرتی Sitemap لائن کوئی لائن نہ ہونے سے بھی بدتر ہے، کیونکہ آڈٹ میں وہ درست دکھائی دیتی ہے۔

ایک سے زیادہ سائٹ میپ درج کرنے میں کوئی حرج نہیں، ہر ایک الگ سطر پر۔ Search Console میں سائٹ میپ الگ سے جمع کرانا اب بھی فائدہ مند ہے؛ robots.txt کی ہدایت اُن کرالرز کے لیے ہے جو آپ کا Search Console اکاؤنٹ کبھی نہیں دیکھتے۔

robots.txt نہ noindex ہے، نہ حفاظت

robots.txt سے ہونے والا زیادہ تر نقصان انہی دو غلط فہمیوں سے ہوتا ہے۔

کسی URL کو بلاک کرنے سے وہ Google سے ہٹتا نہیں۔ Robots.txt کرالنگ پر حکم چلاتی ہے۔ اگر کوئی دوسری سائٹ بلاک شدہ URL سے لنک کرے تو Google خود URL کو انڈیکس کر سکتا ہے — آپ کو نتیجہ صرف پتے کی صورت میں ملے گا اور ساتھ یہ نوٹ کہ کوئی معلومات دستیاب نہیں۔ اور ایک زیادہ خطرناک پھندا بھی ہے: اگر کسی صفحے پر پہلے سے noindex میٹا ٹیگ ہو اور پھر آپ اسے robots.txt میں بلاک کر دیں، تو Google اسے کرال ہی نہیں کر پاتا، noindex دیکھ نہیں پاتا، اور صفحہ غیر معینہ مدت تک انڈیکس میں رہ سکتا ہے۔ صفحہ ہٹانے کے لیے کرالنگ کی اجازت دیں اور صفحے کے ہیڈ میں noindex میٹا روبوٹس ٹیگ یا X-Robots-Tag HTTP ہیڈر پیش کریں۔ Google نے 2019 میں robots.txt کے اندر noindex ہدایات کی حمایت ختم کر دی تھی۔

کسی راستے کو بلاک کرنے سے اس کی حفاظت نہیں ہوتی۔ آپ کی robots.txt بنیادی طور پر عوامی ہے۔ /private-client-files/ درج کرنا ہر وزیٹر اور ہر اسکینر کو بتا دیتا ہے کہ دیکھنا کہاں ہے، اور پابندی رضاکارانہ ہے — Google اس کا احترام کرتا ہے، دشمن بوٹس نہیں۔ جس چیز کی حفاظت درکار ہو اسے تصدیق، IP پابندی، یا .htaccess میں سرور کی سطح کے قواعد چاہئیں، نہ کہ ایک ٹیکسٹ فائل کی سطر جو ہدف کا پتہ ہی بتا دے۔

کون سے قواعد شامل کرنے لائق ہیں اور کون سے چھوڑنے لائق

دو اضافے بہت سی سائٹس پر واقعی مفید ہیں۔ سرچ نتائج کا راستہ بلاک کرنے سے کرالرز آپ کی اندرونی سرچ سے لامتناہی کم قدر URLs بنانا چھوڑ دیتے ہیں۔ WooCommerce پر کارٹ یا چیک آؤٹ کا راستہ بلاک کرنے سے سیشن پیرامیٹر والے URLs کرال سے باہر رہتے ہیں۔

Disallow: /?s=
Disallow: /search/

یہ چھوڑ دیں:

Crawl-delay — Google اسے بالکل نظرانداز کرتا ہے۔ اگر سرور پر واقعی بوجھ کا مسئلہ ہو تو Search Console کے کرال ریٹ کنٹرول استعمال کریں۔
/feed/ یا /trackback/ بلاک کرنا — یہ بےضرر URLs ہیں، اور فیڈز کارآمد ہیں۔
انفرادی بوٹ ناموں کی لمبی فہرستیں — لوگ جن بوٹس کو روکنے کی کوشش کرتے ہیں ان میں سے زیادہ تر ویسے بھی ایمانداری سے اپنی شناخت نہیں بتاتے۔
/wp-json/ بلاک کرنا — ہو سکتا ہے آپ کی تھیم مواد دکھانے کے لیے یہی استعمال کرتی ہو۔

فائل WordPress robots.txt جنریٹر سے بنائیں، جو کم سے کم اور درست ورژن تیار کرتا ہے اور آپ کو سنٹیکس ہاتھ سے لکھے بغیر سرچ اور کامرس کے قواعد شامل کرنے دیتا ہے۔

تبدیلی کے بعد

https://yoursite.com/robots.txt براہِ راست کھولیں اور تصدیق کریں کہ پیش کیے گئے بائٹس وہی ہیں جن کی آپ کو توقع ہے — نہ کہ وہ جو آپ کے پلگ اِن کا ایڈیٹر دکھا رہا ہے۔ پھر Search Console میں کسی عام صفحے پر لائیو URL انسپیکشن چلائیں اور دیکھیں کہ کوئی CSS یا جاوا اسکرپٹ وسیلہ بلاک شدہ تو نہیں آ رہا۔ Google robots.txt کو تقریباً ایک دن کے لیے کیش کرتا ہے، اس لیے نہ درستی فوراً اثر دکھائے گی اور نہ غلطی۔ یہی تاخیر وہ وجہ ہے کہ لائیو سائٹ پر آزما کر انتظار کرنے کے بجائے احتیاط سے تصدیق کر لینی چاہیے۔