wordpress htaccess ری ڈائریکٹ رولز: 301 کو درست طریقے سے لکھنا

کوئی url منتقل کر رہے ہیں اور چاہتے ہیں پرانا اپنی رینکنگ برقرار رکھے؟ آپ کو .htaccess میں ایک 301 چاہیے، ایسی جگہ رکھا ہوا جہاں wordpress اسے مٹا نہ سکے، درست ڈائریکٹو کے ساتھ لکھا ہوا، اور بالکل اسی url کی طرف اشارہ کرتا ہوا جو wordpress واقعی پیش کرتا ہے۔ ان تینوں میں سے کوئی ایک غلط ہوا تو آپ کو ری ڈائریکٹ چین ملے گی، یا لوپ، یا ایک 500 جو آپ کو wp-admin سے باہر بند کر دے گا۔

فیصلہ، جگہ کا اصول، اور ٹیسٹ — اسی ترتیب سے۔

کون سا ڈائریکٹو: Redirect، RedirectMatch یا RewriteRule

یہاں Apache کے دو ماڈیول کام کر رہے ہیں اور وہ ایک دوسرے کا بدل نہیں ہیں۔

Redirect (mod_alias) — ایک معلوم راستہ ایک منزل کی طرف۔ سب سے سادہ چیز جو کام کرتی ہے:

Redirect 301 /old-page/ https://example.com/new-page/

دو رویّے جاننے کے لائق ہیں۔ یہ راستے کے سابقے پر مماثلت کرتا ہے، مکمل اسٹرنگ پر نہیں، چنانچہ /old-page/ /old-page/anything/ کو بھی پکڑ لیتا ہے اور منزل کے آگے /anything/ جوڑ دیتا ہے۔ اور کوئری اسٹرنگ کو خودکار طور پر ساتھ لے جاتا ہے۔

RedirectMatch (mod_alias) — ایک ریگولر ایکسپریشن جو کئی url کا احاطہ کرے۔ پورا سیکشن اسی طرح منتقل کیا جاتا ہے:

RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

کیپچر گروپ (.*) منزل میں $1 بن جاتا ہے، چنانچہ /blog/hello-world/ /articles/hello-world/ پر پہنچتا ہے۔ ابتدائی سلیش پر دھیان دیں: mod_alias کے پیٹرن پورے url راستے سے مماثلت کرتے ہیں۔

RewriteRule (mod_rewrite) — تب ضروری ہے جب ری ڈائریکٹ کسی شرط پر منحصر ہو: ہوسٹ نام، پروٹوکول، کوئری اسٹرنگ، یوزر ایجنٹ۔ mod_alias میں کوئی چیز انہیں جانچ نہیں سکتی۔

RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

فی ڈائریکٹری .htaccess میں پیٹرن سے ابتدائی سلیش ہٹا دیا جاتا ہے — یہی وجہ ہے کہ یہاں ^(.*)$ ہے اور mod_alias کی مثال میں ^/blog/۔ اسی بات کو گڈمڈ کرنا وہ سب سے عام وجہ ہے جس کے سبب کاپی کیا ہوا رول خاموشی سے کچھ نہیں کرتا۔

ڈیفالٹ mod_alias رکھیں۔ RewriteRule کی طرف صرف تب جائیں جب کوئی شرط درکار ہو۔ کم ریگولر ایکسپریشن، غلط ہونے کے کم راستے۔

رولز کہاں جانے چاہئیں

اپنی مرضی کے ری ڈائریکٹ کی جگہ # BEGIN WordPress لائن کے اوپر ہے۔ اس کے اندر نہیں۔

# --- custom redirects ---
Redirect 301 /old-page/ https://example.com/new-page/
RedirectMatch 301 ^/blog/(.*)$ https://example.com/articles/$1

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

دو الگ الگ وجوہات:

1. wordpress اپنا بلاک خود دوبارہ لکھتا ہے۔ ترتیبات ← پرمالنکس محفوظ کرنا flush_rewrite_rules() کو پکارتا ہے، جو مارکرز کے درمیان کی ہر چیز پھینک کر نئے سرے سے بناتا ہے۔ اندر رکھا ہوا رول اگلی بار جب کوئی اس اسکرین کو چھوئے گا غائب ہو جائے گا — شاید مہینوں بعد، اور کوئی ان دو واقعات کو آپس میں نہیں جوڑے گا۔
2. ترتیب طے کرتی ہے کون جیتے گا۔ wordpress کا بلاک ایک عمومی رول پر ختم ہوتا ہے جو ہر ایسی درخواست کو جو فائل یا ڈائریکٹری نہ ہو index.php کو بھیج دیتا ہے۔ اس کے بعد رکھا گیا RewriteRule کبھی نہیں چلے گا۔

ایک پیچیدگی جسے دیانت داری سے کہنا چاہیے: mod_alias اور mod_rewrite دراصل فائل کی ترتیب سے نہیں چلتے۔ Apache mod_alias کو url ترجمے کے دوران پروسیس کرتا ہے اور فی ڈائریکٹری mod_rewrite کو بعد میں، فکس اپ کے مرحلے میں — چنانچہ ایک Redirect لائن اس RewriteRule پر بھی غالب آ سکتی ہے جو فائل میں اس سے اوپر لکھی ہو۔ اگر آپ کو ایک ہی متداخل راستے پر دونوں کی ضرورت پڑے تو اس راستے کے لیے ایک ماڈیول چنیں اور اسی کے اندر رہیں۔ mod_alias بمقابلہ mod_rewrite کی کشمکش ڈی بگ کرنا ایک گھنٹے کے قابل نہیں۔

آخری سلیش

wordpress کا اپنا کینونیکل ری ڈائریکٹ زیادہ تر پرمالنکس کے آخر میں سلیش لگا دیتا ہے۔ چنانچہ یہ:

Redirect 301 /old-page/ https://example.com/new-page

دو ہاپ پیدا کرتا ہے — آپ کا 301 بغیر سلیش والے url کی طرف، پھر wordpress کا اپنا 301 جو سلیش لگاتا ہے۔ زنجیریں رینکنگ سگنل تو منتقل کرتی ہیں، مگر کرال بجٹ ضائع کرتی ہیں اور ہر وزیٹر کے لیے ایک اضافی چکر بڑھا دیتی ہیں۔

پہلے منزل کو براؤزر میں کھولیں، ایڈریس بار میں جیسے ہی url ٹھہر جائے اسے بالکل ویسے ہی کاپی کریں، اور وہی استعمال کریں۔ اگر آپ کا پرمالنک ڈھانچہ .html پر ختم ہوتا ہے یا آخر میں سلیش نہیں رکھتا تو اسی سے مماثلت کریں۔ یہاں کوئی عالمی طور پر درست جواب نہیں، صرف یہ کہ ”جو wordpress پیش کرتا ہے اسی سے ملائیں“۔

خود کو باہر بند کیے بغیر ٹیسٹ کرنا

.htaccess ہر درخواست پر پڑھی جاتی ہے۔ ایک نحوی غلطی wp-admin سمیت پوری سائٹ کے لیے 500 دیتی ہے، اس لیے واپسی کا راستہ ضرورت پڑنے سے پہلے موجود ہونا چاہیے۔

پہلے فائل کا بیک اپ لیں۔ SSH کے ذریعے:

cp /path/to/wordpress/.htaccess /path/to/wordpress/.htaccess.bak

اگر سائٹ 500 دے تو خراب فائل کے اوپر سالم فائل واپس رکھ دیں اور سائٹ فوراً لوٹ آئے گی۔ ایک SFTP سیشن پہلے سے دوسری ونڈو میں کھلا رکھیں — سائٹ ڈاؤن ہونے کی حالت میں صفر سے لاگ ان کرنا وہ لمحہ ہے جہاں گھبراہٹ شروع ہوتی ہے۔ نوٹ رکھیں کہ apachectl configtest .htaccess کو پارس نہیں کرتا، چنانچہ وہ کنفیگ کو صحیح بتائے گا جبکہ آپ کی سائٹ مردہ پڑی ہو گی۔

curl سے ٹیسٹ کریں، براؤزر سے نہیں۔ براؤزر 301 جوابات کو سختی سے کیش کرتے ہیں اور خوشی سے آپ کو کل کا نتیجہ دکھا دیں گے:

curl -sI https://example.com/old-page/ | head -n 5

دو چیزیں پڑھیں: اسٹیٹس لائن پر 301 ہونا چاہیے، اور Location: ہیڈر بالکل وہی حتمی url ہونا چاہیے۔ پوری زنجیر دیکھنے کے لیے اس کا پیچھا کریں:

curl -sIL https://example.com/old-page/ | grep -E '^(HTTP|Location)'

ایک سے زیادہ HTTP/1.1 301 لائنوں کا مطلب ہے آپ نے زنجیر بنا دی ہے۔ تقریباً پانچ سے زیادہ کا مطلب ہے آپ نے لوپ بنا دیا ہے، اور curl رک کر یہی بتا دے گا۔

جب تک یقین نہ ہو 302 استعمال کریں۔ 302 اس طرح کیش نہیں ہوتا، اس لیے غلطی سیکنڈوں میں واپس ہو سکتی ہے۔ جب curl وہی منزل دکھائے جو آپ چاہتے تھے تب 301 پر منتقل ہوں۔ اس کی کوئی قیمت نہیں اور اس نے اس مضمون کی کسی بھی دوسری عادت سے زیادہ سائٹیں بچائی ہیں۔

اگر کوئی رول بالکل ہی بے اثر لگے تو تصدیق کریں کہ Apache فائل پڑھ بھی رہا ہے یا نہیں۔ ڈائریکٹری پر AllowOverride None ہونے سے Apache .htaccess کو مکمل نظرانداز کر دیتا ہے، اور nginx تو اسے سرے سے نہیں دیکھتا — ریگولر ایکسپریشن ڈی بگ کرنے سے پہلے curl -I سے Server: ہیڈر جانچیں۔ اپنے Apache ورژن اور انسٹال پاتھ کے لیے درست نحو کے ساتھ بلاک تیار کرنے کے لیے wordpress htaccess جنریٹر استعمال کریں۔

htaccess کب بالکل استعمال نہ کریں

چند ایسے ری ڈائریکٹ کے لیے جنہیں ایڈیٹرز خود سنبھالنا چاہتے ہوں، ایسا ری ڈائریکٹ پلگ ان بہتر اوزار ہے جو رولز ڈیٹابیس میں رکھتا ہو — وہ ہوسٹ کی منتقلی سے بچ جاتا ہے اور SSH کا محتاج نہیں۔ سودا حقیقی ہے: ری ڈائریکٹ پیش کرنے کے لیے php کو بوٹ ہونا پڑتا ہے، جو Apache کے براہِ راست جواب دینے سے سست ہے۔

.htaccess ڈھانچہ جاتی اور مستقل منتقلیوں کے لیے استعمال کریں — ڈومین کی تبدیلی، کسی سیکشن کا نام بدلنا، https یا www نافذ کرنا۔ اکا دکا ادارتی ری ڈائریکٹ کے لیے پلگ ان استعمال کریں۔ دونوں کرنا ٹھیک ہے بشرطیکہ آپ کو معلوم ہو کون سی پرت کس url کی مالک ہے، کیونکہ دو جگہ متعین کیا گیا ری ڈائریکٹ ایک ایسا بگ ہے جو کسی بری سہ پہر کا انتظار کر رہا ہے۔