ویب سائٹ یا ایپ ڈیپلائے کرنے کے بعد 404 غلطیاں کیسے ٹھیک کریں

اگر آپ کی ایپ لوکل پر کام کرتی ہے مگر deploy کے بعد صفحات 404 دیتے ہیں، تو سب سے عام وجہ سنگل پیج ایپ (SPA) روٹنگ کی کمی ہے: سرور /dashboard نامی فائل ڈھونڈتا ہے جو موجود نہیں، کیونکہ یہ راستہ صرف JavaScript میں ہوتا ہے۔ حل ایک فال بیک رول ہے جو ایپ کے راستوں کے لیے index.html دے۔ دوسری وجوہات میں بلڈ آؤٹ پٹ سے غائب فائلیں، کیس حساس راستے، ٹریلنگ سلیش کا فرق، غلط base path، اور وہ API روٹس شامل ہیں جو کبھی deploy ہی نہیں ہوئے۔

پہلے نوٹ کریں کہ کون سا URL عین کس طرح 404 دے رہا ہے۔ پیٹرن ہی وجہ کی طرف اشارہ کرتا ہے۔

مرحلہ 1: پیٹرن تلاش کریں

اصل اسٹیٹس کوڈ دیکھنے کے لیے ڈویلپر ٹولز کھولیں (دائیں کلک → Inspect)، Network ٹیب پر جائیں، ری لوڈ کریں، اور پہلی درخواست کا اسٹیٹس دیکھیں۔

مرحلہ 2: SPA فال بیک شامل کریں

یہ کلاسک مسئلہ ہے۔ React، Vue یا Svelte کی سنگل پیج ایپ میں سرور کے پاس صرف چند اصل فائلیں ہوتی ہیں: index.html اور کچھ JavaScript اور CSS۔ /dashboard یا /projects/42 جیسے راستے براؤزر میں راؤٹر سنبھالتا ہے۔

• لنک پر کلک کام کرتا ہے: راؤٹر URL بدلتا ہے اور سرور سے پوچھے بغیر نیا صفحہ بناتا ہے۔
• ری فریش یا براہ راست لنک کھولنا ناکام ہوتا ہے: براؤزر سرور سے /dashboard مانگتا ہے، سرور کے پاس ایسی فائل نہیں، اور وہ 404 دیتا ہے۔

حل ایک ایسا رول ہے جو کہے: اگر درخواست کسی اصل فائل سے مماثل نہ ہو تو index.html 200 اسٹیٹس کے ساتھ دیں، اور راؤٹر کو کنٹرول دے دیں۔ یہ کیسے ہوگا، یہ ہوسٹ پر منحصر ہے (تبدیلیوں کے لیے ہوسٹ کی موجودہ دستاویزات دیکھیں):

یقینی بنائیں کہ رول اصل فائلوں کو نگل نہ جائے: /assets/app.js کی درخواست پر اب بھی JavaScript فائل ہی واپس آنی چاہیے۔ اگر وہ index.html دے تو آپ کو خالی صفحہ اور "Failed to load module script" خرابی ملے گی۔ دیکھیں سفید خالی صفحہ ٹھیک کرنا۔

راؤٹر کو ایک catch-all route بھی دیں تاکہ وہ URLs جو کسی صفحے سے مماثل نہ ہوں، خالی صفحے کے بجائے ایک دوستانہ "Page not found" دکھائیں۔

اگر آپ سرور کی ترتیبات نہیں بدل سکتے تو hash routing (جیسے /#/dashboard) مسئلہ ٹال دیتا ہے، کیونکہ # کے بعد کا حصہ کبھی سرور کو نہیں بھیجا جاتا۔ یہ پہلی ترجیح نہیں بلکہ ایک متبادل ہے: URLs بدصورت ہوتے ہیں اور سرچ انجنوں کے لیے کم دوستانہ۔

جو فریم ورک سرور پر صفحات رینڈر کرتے ہیں یا بلڈ کے وقت بناتے ہیں (Next.js، Astro اور اسی طرح کے)، ان کے پاس عموماً ہر صفحے کے لیے اصل فائلیں یا سرور روٹس ہوتے ہیں، اس لیے وہاں یہ مسئلہ کم ہوتا ہے۔ ان کا مساوی مسئلہ وہ صفحہ ہے جو بلڈ کے وقت بنایا ہی نہ گیا ہو۔

مرحلہ 3: دیکھیں کہ اصل میں کیا deploy ہوا

اگر سب کچھ 404 دے رہا ہے تو امکان ہے کہ سرور آپ کی بنی ہوئی ایپ پیش ہی نہیں کر رہا۔

• درست فولڈر۔ ہوسٹ کو بلڈ آؤٹ پٹ شائع کرنا چاہیے (Vite کے لیے عموماً dist، Create React App کے لیے build، static Next.js export کے لیے out)، پروجیکٹ کا روٹ نہیں۔
• بلڈ چلا۔ deploy لاگ پڑھیں۔ اگر بلڈ ناکام ہوئی تو ہوسٹ نے کچھ deploy نہ کیا ہو، یا پرانا ورژن دے رہا ہو۔
• index.html اوپری سطح پر شائع شدہ فولڈر میں ہو، کسی ذیلی فولڈر میں نہیں۔
• base path میل کھاتا ہو۔ اگر ایپ example.com/app/ پر پیش ہو رہی ہے تو اسے اسی base کے ساتھ بنانا ہوگا (Vite کا base، React Router کا basename)، ورنہ ہر راستہ اور اثاثہ نہیں ملے گا۔

مرحلہ 4: غائب فائلیں اور غلط راستے ٹھیک کریں

جب صفحات لوڈ ہوں مگر اثاثے 404 دیں:

• کیس حساسیت۔ macOS اور Windows عموماً Logo.png اور logo.png کو ایک ہی فائل سمجھتے ہیں۔ زیادہ تر Linux سرور ایسا نہیں کرتے۔ ہر حوالہ فائل کے اصل نام سے بالکل مطابقت رکھے۔
• بلڈ سے باہر فائلیں۔ Vite میں public/ کی فائلیں جوں کی توں کاپی ہوتی ہیں اور روٹ سے حوالہ دی جاتی ہیں (/logo.png)۔ کوڈ میں امپورٹ ہونے والی فائلیں بنڈل ہوتی ہیں۔ پروجیکٹ میں کسی اور جگہ پڑی فائل شاید deploy ہی نہ ہو۔
• Relative راستے۔ images/photo.jpg موجودہ URL کے حساب سے حل ہوتا ہے، اس لیے /blog/post-1 پر ٹوٹ جاتا ہے۔ /images/photo.jpg استعمال کریں۔
• مقامی ڈسک پر محفوظ اپلوڈز۔ اگر صارفین کے اپلوڈز سرور کے اپنے فولڈر میں لکھے گئے تو نیا ورژن deploy ہونے پر وہ غائب ہو جائیں گے۔ مناسب فائل اسٹوریج استعمال کریں۔

مرحلہ 5: ٹریلنگ سلیشز کو یکساں طریقے سے ہینڈل کریں

/about اور /about/ مختلف URLs ہیں۔ ہوسٹس اس میں مختلف ہیں کہ وہ سلیش شامل کرتے ہیں یا ہٹاتے ہیں، اور آپ کے لنکس یا راؤٹر سے عدم مطابقت 404 یا redirect loops پیدا کر سکتی ہے۔ ایک انداز چنیں، اپنے لنکس اسی انداز میں رکھیں، اور ہوسٹ کو دوسری شکل کو اس کی طرف ری ڈائریکٹ کرنے کے لیے ترتیب دیں۔ یکسانیت سرچ انجنوں کی بھی مدد کرتی ہے، ورنہ وہ ہر صفحے کی دو کاپیاں دیکھ سکتے ہیں۔

مرحلہ 6: 404 دینے والے API روٹس ٹھیک کریں

اگر صفحہ لوڈ ہو مگر Network ٹیب میں /api/... درخواستیں 404 دیں:

• بیک اینڈ deploy نہیں ہوا۔ static ہوسٹ صرف فائلیں پیش کرتا ہے؛ بیک اینڈ کہیں چلنا چاہیے۔
• پروڈکشن میں راستہ مختلف روٹ ہوتا ہے۔ ڈیولپمنٹ میں ایک proxy شاید /api کو الگ سرور پر بھیج رہا تھا۔ پروڈکشن میں ہوسٹ کو اس کے مساوی rewrite چاہیے، یا فرنٹ اینڈ کو API کے اصل پتے پر کال کرنا ہوگا۔
• SPA فال بیک نے اسے پکڑ لیا۔ اگر کوئی API درخواست index.html کو 200 اسٹیٹس کے ساتھ واپس کرے تو فال بیک رول بہت وسیع ہے۔ اس سے /api/* کو خارج کریں۔

شائع شدہ ایپ کی درخواستیں /api/orders پر 404 دیتی ہیں، جبکہ پریویو میں وہ کام کرتی ہیں۔ دیکھیں کہ پریویو اور شائع شدہ ایپ میں /api کیسے روٹ ہوتا ہے، اور شائع شدہ فرنٹ اینڈ کو بیک اینڈ تک اسی طرح پہنچنے دیں۔

مرحلہ 7: پرانے URLs ری ڈائریکٹ کریں

اگر آپ کسی اور سائٹ سے منتقل ہوئے ہیں یا ڈھانچہ بدلا ہے، تو پرانے URLs جنہیں لوگ اور سرچ انجن اب بھی استعمال کرتے ہیں 404 دیں گے۔ ہر پرانے URL سے اس کے نئے گھر تک 301 (مستقل) ری ڈائریکٹ شامل کریں۔ ایک فہرست رکھیں اور لانچ کے بعد نمونے کے طور پر کچھ ٹیسٹ کریں۔ WordPress سائٹ کی منتقلی پر ہماری گائیڈ میں یہ فہرست بنانے کا طریقہ شامل ہے۔

مرحلہ 8: ڈومین چیک کریں

اگر ایپ ہوسٹ کے پتے پر کام کرتی ہے مگر آپ کے کسٹم ڈومین پر 404 دیتی ہے، تو ڈومین شاید غلط پروجیکٹ کی طرف اشارہ کر رہا ہے، یا ہوسٹ پر ابھی تک ڈومین آپ کی سائٹ سے منسلک نہیں ہوا۔ DNS ریکارڈز اور ہوسٹ کی ڈومین ترتیبات چیک کریں۔ دیکھیں کسٹم ڈومین کیسے جوڑیں۔

اپنا اصل 404 صفحہ مفید بنائیں

کچھ 404 درست ہوتے ہیں: کسی نے URL غلط ٹائپ کیا۔ تب وہ صفحہ مددگار بنائیں:

• ایک مختصر پیغام اور ہوم پیج اور اہم حصوں کے لنکس
• سرچ باکس، اگر سائٹ میں سرچ ہو
• باقی سائٹ جیسا ہیڈر اور نیویگیشن

جہاں آپ کا سیٹ اپ اجازت دے، وہاں ایسے صفحات کے لیے حقیقی 404 اسٹیٹس واپس کریں جو موجود نہیں۔ 200 اسٹیٹس کے ساتھ آنے والا "not found" پیغام وہ ہے جسے سرچ انجن soft 404 کہتے ہیں، اور یہ ان کا کرال وقت ضائع کر کے انڈیکسنگ کو الجھا سکتا ہے۔

عام غلطیاں

• صرف کلک کر کے ٹیسٹ کرنا۔ ہمیشہ گہرے URLs کو نئے ٹیب میں چسپاں کر کے ری فریش کر کے ٹیسٹ کریں۔
• ایک فال بیک جو سب کچھ پکڑ لے۔ اثاثے اور API روٹس index.html دیتے ہیں، جس سے خالی صفحات اور الجھانے والی API خرابیاں آتی ہیں۔
• کیس کا فرق جو صرف سرور پر ٹوٹتا ہے۔
• سورس فولڈر deploy کرنا بجائے بلڈ آؤٹ پٹ کے۔
• URLs کی ساخت بدلنا بغیر ری ڈائریکٹس کے۔ ہر پرانا لنک 404 بن جاتا ہے۔

Mythex میں 404

Mythex میں آپ ورک اسپیس سے شائع کرتے ہیں، اور static فرنٹ اینڈز static سائٹس کے طور پر deploy ہوتے ہیں۔ اگر کوئی شائع شدہ صفحہ 404 دے تو ایجنٹ کو بالکل درست URL دیں، بتائیں کہ یہ ری فریش پر ہوتا ہے یا کلک پر، اور Network ٹیب میں کیا دکھتا ہے، اور اس سے روٹنگ چیک کرنے کو کہیں۔ فکس کے بعد دوبارہ شائع کریں، کیونکہ لائیو ایپ اس وقت تک پرانی کاپی رہتی ہے جب تک آپ دوبارہ شائع نہ کریں۔ اگر آپ نے حال ہی میں پروجیکٹ بدلا ہے اور لائیو سائٹ پرانی لگ رہی ہے تو دوبارہ شائع کریں اور ہارڈ ری فریش کریں۔ اگر بلڈ ناکام ہو تو شائع کرنے کے ڈائیلاگ میں Fix with AI استعمال کریں۔ دیکھیں دستاویزات میں How to publish اور Publish troubleshooting، اور ہماری گائیڈ AI سے بنی ایپ کی ڈیبگنگ۔

404 چیک لسٹ

• نوٹ کیا کہ کون سے URLs 404 دیتے ہیں اور کلک پر، ری فریش پر یا دونوں پر
• SPA فال بیک ایپ کے راستوں کے لیے index.html 200 اسٹیٹس کے ساتھ دیتا ہے
• فال بیک اصل فائلوں اور /api/* کو خارج کرتا ہے
• راؤٹر میں catch-all "not found" روٹ موجود ہے
• شائع ہونے والا بلڈ آؤٹ پٹ فولڈر درست ہے، اور بلڈ کامیاب ہوئی
• base path اس جگہ سے میل کھاتا ہے جہاں ایپ پیش ہو رہی ہے
• فائل نام کی کیپٹلائزیشن ہر حوالے سے میل کھاتی ہے
• اثاثوں کے راستے / سے شروع ہوتے ہیں
• ٹریلنگ سلیش کا انداز یکساں ہے
• API روٹس پروڈکشن میں deploy اور روٹ ہیں
• پرانے URLs کے لیے 301 ری ڈائریکٹس
• گہرے لنکس کو نئے ٹیب میں چسپاں کر کے ٹیسٹ کیا

سوالات