Deploy के बाद वेबसाइट या ऐप में 404 एरर कैसे ठीक करें
अगर आपकी ऐप लोकल पर ठीक चलती है, लेकिन deploy के बाद पेज 404 देते हैं, तो सबसे आम कारण single-page app (SPA) routing की कमी है: server /dashboard नाम की ऐसी file ढूंढता है जो मौजूद नहीं है, क्योंकि वह route सिर्फ़ JavaScript में होता है। हल है एक fallback नियम जो ऐप के routes के लिए index.html भेजे। दूसरे कारण हैं build output में गायब files, case-sensitive paths, trailing slash का अंतर, गलत base path, और ऐसे API routes जो कभी deploy ही नहीं हुए।
पहले यह नोट करें कि ठीक कौन सा URL 404 दे रहा है और आप वहां तक कैसे पहुंचे। पैटर्न सीधे कारण की ओर इशारा करता है।
चरण 1: पैटर्न पहचानें
| आप क्या देखते हैं | सबसे संभावित कारण | कहां जाएं |
|---|---|---|
| होम पेज चलता है; लिंक पर क्लिक करना काम करता है; पर रीफ़्रेश करने या सीधे deep link खोलने पर 404 | SPA fallback नहीं है | चरण 2 |
| हर पेज 404 देता है, होम पेज भी | गलत folder publish हुआ, या build deploy नहीं हुआ | चरण 3 |
| पेज लोड होते हैं, लेकिन images, fonts या scripts 404 देते हैं | Build में files नहीं हैं, या paths गलत हैं | चरण 4 |
/about/ के साथ चलता है, /about के साथ फेल होता है (या उल्टा) | Trailing-slash का व्यवहार | चरण 5 |
/About फेल होता है लेकिन /about चलता है | Case-sensitive server | चरण 4 |
पेज लोड होता है, लेकिन /api/... के data calls 404 देते हैं | API deploy नहीं हुई या routed नहीं है | चरण 6 |
| पुरानी साइट के पुराने URLs 404 देते हैं | Redirects गायब हैं | चरण 7 |
| सिर्फ़ custom domain पर | DNS या domain सेटअप | चरण 8 |
असली status code देखने के लिए developer tools खोलें (right-click → Inspect), Network tab पर जाएं, रीलोड करें, और पहली request का status देखें।
चरण 2: SPA fallback जोड़ें
यह सबसे क्लासिक मामला है। React, Vue या Svelte single-page app में server के पास सिर्फ़ कुछ असली files होती हैं: index.html और कुछ JavaScript व CSS। /dashboard या /projects/42 जैसे routes एक router संभालता है जो ब्राउज़र में चलता है।
- लिंक पर क्लिक करना काम करता है: router URL बदलता है और server से पूछे बिना नया पेज बना देता है।
- रीफ़्रेश करना या सीधा link खोलना फेल होता है: browser server से
/dashboardमांगता है, server के पास ऐसी कोई file नहीं है, और वह 404 लौटाता है।
हल एक ऐसा नियम है जो कहता है: अगर request किसी असली file से मेल नहीं खाती, तो index.html को 200 status के साथ भेजो, और router को काम संभालने दो। यह कैसे जोड़ा जाए, यह host पर निर्भर करता है (विवरण बदलते रहते हैं, इसलिए host के मौजूदा डॉक्स जांचें):
| Host | सामान्य fallback नियम |
|---|---|
| Netlify | Published folder में _redirects file, जिसमें /* /index.html 200 हो |
| Vercel | vercel.json में एक rewrite जो सभी paths को /index.html पर भेजे (framework presets अक्सर यह खुद संभालते हैं) |
| Cloudflare Pages | अगर ऊपरी स्तर पर 404.html नहीं है, तो डिफ़ॉल्ट रूप से SPA-style fallback देता है |
| Nginx | location / block में try_files $uri $uri/ /index.html; |
| Apache | .htaccess में एक rewrite नियम जो गैर-file requests को index.html पर भेजे |
| GitHub Pages | Server-side rewrites नहीं; आम उपाय hash routing या एक 404.html है जो redirect करे |
ध्यान रखें कि नियम असली files को न निगले: /assets/app.js जैसी requests को अब भी JavaScript file ही लौटानी चाहिए। अगर वे index.html लौटाती हैं, तो आपको खाली पेज और "Failed to load module script" एरर मिलेगी। देखें सफ़ेद पेज कैसे ठीक करें।
इसके अलावा router को एक catch-all route दें, ताकि जो URLs किसी पेज से मेल न खाएं वे खाली स्क्रीन की जगह एक दोस्ताना "Page not found" दिखाएं।
अगर आप server settings नहीं बदल सकते, तो hash routing (/#/dashboard जैसे URLs) समस्या से बचाता है, क्योंकि # के बाद का हिस्सा कभी server को नहीं भेजा जाता। यह पहली पसंद नहीं, बल्कि एक समाधान है: URLs कम सुंदर होते हैं और search engines के लिए कम अनुकूल।
वे frameworks जो सर्वर पर पेज बनाते हैं या build के समय बनाते हैं (Next.js, Astro और इसी तरह के), उनमें आम तौर पर हर पेज के लिए असली files या server routes होते हैं, इसलिए यह समस्या वहां कम होती है। उनके समकक्ष मामले में वह पेज होता है जो build के समय कभी बना ही नहीं।
चरण 3: जांचें कि असल में क्या deploy हुआ
अगर सब कुछ 404 दे रहा है, तो server शायद आपकी built ऐप नहीं दे रहा।
- सही folder। Host को build output publish करना चाहिए (Vite के लिए आमतौर पर
dist, Create React App के लिएbuild, static Next.js export के लिएout), project का root नहीं। - Build चला। Deploy log पढ़ें। अगर build फेल हुआ, तो host शायद कुछ भी deploy न करे, या पुराना version दे।
index.htmlpublish हुए folder के सबसे ऊपरी स्तर पर हो, किसी sub-folder में नहीं।- Base path मेल खाता है। अगर ऐप
example.com/app/पर चलती है, तो उसे उसी base के साथ build होना चाहिए (Vite काbase, React Router काbasename), वरना हर route और asset गलत जगह जाएगा।
चरण 4: गायब files और गलत paths ठीक करें
जब पेज लोड हों लेकिन assets 404 दें:
- Case sensitivity। macOS और Windows आमतौर पर
Logo.pngऔरlogo.pngको एक ही file मानते हैं। ज़्यादातर Linux servers ऐसा नहीं करते। हर reference का नाम असली file के नाम से बिल्कुल मेल खाना चाहिए। - Build से बाहर की files। Vite में
public/की files बिना बदले कॉपी होती हैं और root से (/logo.png) रेफ़र होती हैं। Code में import की गई files bundle हो जाती हैं। Project में कहीं और रखी file शायद deploy ही नहीं हुई। - Relative paths।
images/photo.jpgमौजूदा URL के हिसाब से resolve होता है, इसलिए/blog/post-1पर टूट जाता है।/images/photo.jpgइस्तेमाल करें। - Upload की गई files जो लोकल disk पर सेव हुईं। अगर users की uploads server के अपने folder में लिखी गईं, तो नया version deploy होने पर वे गायब हो जाती हैं। उचित file storage इस्तेमाल करें।
चरण 5: Trailing slashes को एक जैसा रखें
/about और /about/ अलग URLs हैं। Hosts अलग-अलग तरीके से slash जोड़ते या हटाते हैं, और अगर यह आपके links या router से मेल न खाए, तो 404 या redirect loops बन सकते हैं। एक शैली चुनें, अपने links उसी का इस्तेमाल करें, और host को दूसरे रूप को उसी पर redirect करने के लिए कॉन्फ़िगर करें। इससे search engines को भी हर पेज की एक ही प्रति दिखती है, दो नहीं।
चरण 6: 404 देने वाले API routes ठीक करें
अगर पेज लोड होता है, लेकिन Network tab में /api/... requests 404 दे रही हैं:
- Backend deploy नहीं हुआ। Static host सिर्फ़ files देता है; backend को कहीं चलना होता है।
- Production में path अलग तरह से route होता है। Development में शायद proxy
/apiको एक अलग server पर भेज रहा था। Production में host को समकक्ष rewrite चाहिए, या frontend को API का असली address कॉल करना होगा। - SPA fallback ने उसे पकड़ लिया। अगर API request
index.htmlको 200 status के साथ लौटाती है, तो fallback नियम बहुत व्यापक है। उसमें से/api/*बाहर रखें।
Published ऐप की
/api/ordersrequests 404 दे रही हैं, जबकि वे preview में काम करती हैं। Preview और published ऐप में/apiको कैसे route किया गया है, यह जांचो, और published frontend को उसी तरह backend तक पहुंचाओ।
चरण 7: पुराने URLs को redirect करें
अगर आप किसी दूसरी साइट से आए हैं या structure बदला है, तो लोगों और search engines के इस्तेमाल किए जा रहे पुराने URLs 404 देंगे। हर पुराने URL से उसके नए पते पर 301 (स्थायी) redirect जोड़ें। एक सूची रखें और लॉन्च के बाद कुछ नमूने जांचें। WordPress साइट के स्थानांतरण के लिए यह सूची कैसे बनाएं, यह WordPress साइट कैसे माइग्रेट करें में है।
चरण 8: Domain जांचें
अगर ऐप host के address पर काम करती है, लेकिन आपके custom domain पर 404 देती है, तो domain शायद गलत project की ओर इशारा कर रहा है, या host ने अभी तक domain को आपकी site से नहीं जोड़ा है। DNS records और host की domain सेटिंग्स जांचें। देखें custom domain कैसे जोड़ें।
असली 404 पेज को उपयोगी बनाएं
कुछ 404 सही होते हैं: किसी ने URL गलत टाइप कर दिया। उस पेज को मददगार बनाएं:
- एक छोटा संदेश और होम पेज व मुख्य सेक्शन के लिंक
- अगर साइट में search है, तो search box
- बाकी साइट जैसा ही header और navigation
जहां आपका setup अनुमति दे, वहां जो पेज मौजूद नहीं हैं उनके लिए असली 404 status लौटाएं। 200 status के साथ आने वाले "not found" संदेश को search engines soft 404 कहते हैं, और यह उनका crawl समय बर्बाद करता है और indexing को भ्रमित कर सकता है।
आम गलतियां
- सिर्फ़ क्लिक करके टेस्ट करना। हमेशा deep URLs को नए tab में चिपकाकर और रीफ़्रेश करके टेस्ट करें।
- ऐसा fallback जो सब कुछ पकड़ ले। Assets और API routes
index.htmlलौटाते हैं, जिससे खाली पेज और भ्रमित API एरर बनती हैं। - Capitalisation का मेल न खाना जो सिर्फ़ server पर टूटता है।
- Source folder deploy करना build output की जगह।
- URLs बदलना बिना redirects के। हर पुराना link 404 बन जाता है।
Mythex में 404
Mythex में आप workspace से publish करते हैं, और static frontends static sites के रूप में deploy होते हैं। अगर कोई published पेज 404 देता है, तो एजेंट को ठीक वह URL दें, बताएं कि यह रीफ़्रेश पर होता है या क्लिक पर, और Network tab में क्या दिखता है, फिर routing जांचने को कहें। फिक्स के बाद फिर से publish करें, क्योंकि live ऐप तब तक एक snapshot है जब तक आप दोबारा publish न करें। अगर हाल में project बदला है और live साइट पुरानी लगती है, तो फिर से publish करें और hard-refresh करें। Build फेल हो तो publish dialog में Fix with AI इस्तेमाल करें। देखें How to publish और Publish troubleshooting डॉक्स में, और हमारी गाइड AI से बने app को debug कैसे करें।
404 चेकलिस्ट
- नोट किया कि कौन से URLs 404 देते हैं, और क्लिक पर, रीफ़्रेश पर, या दोनों पर
- SPA fallback ऐप के routes के लिए 200 status के साथ
index.htmlभेजता है - Fallback असली files और
/api/*को बाहर रखता है - Router में "not found" का catch-all route है
- Publish हो रहा folder build output है, और build सफल रहा
- Base path उस जगह से मेल खाता है जहां ऐप चल रही है
- File नाम के अक्षरों का case हर reference से मेल खाता है
- Asset paths
/से शुरू होते हैं - Trailing-slash की शैली एक जैसी है
- API routes deploy हुए और production में routed हैं
- पुराने URLs के लिए 301 redirects हैं
- Deep links नए tab में चिपकाकर टेस्ट किए
सवाल
मेरी React ऐप में पेज रीफ़्रेश करने पर 404 क्यों आता है?
Single-page ऐप में `/dashboard` जैसे routes सिर्फ़ JavaScript में होते हैं। लिंक पर क्लिक करना काम करता है क्योंकि router ब्राउज़र में ही उसे संभालता है, लेकिन रीफ़्रेश करने पर browser server से `/dashboard` नाम की ऐसी file मांगता है जो मौजूद नहीं है। हल है एक fallback नियम जो ऐप के routes के लिए `index.html` भेजे।
Netlify, Vercel या Nginx पर SPA fallback कैसे जोड़ूं?
Netlify पर, `_redirects` file में `/* /index.html 200` लिखें। Vercel पर, `vercel.json` में एक rewrite जोड़ें जो सभी paths को `/index.html` पर भेजे। Nginx पर, `location` block में `try_files $uri $uri/ /index.html;` इस्तेमाल करें। नियम बदलते रहते हैं, इसलिए अपने host के डॉक्स जांचें।
Deploy के बाद मेरी images या files 404 क्यों देती हैं?
आमतौर पर इसलिए कि file build output में नहीं है, path के अक्षरों का case मेल नहीं खाता (servers अक्सर case-sensitive होते हैं, जबकि आपका laptop नहीं), या path relative है जबकि उसे slash से शुरू होना चाहिए था।
गायब पेज के लिए असली 404 status लौटना चाहिए?
हां। गायब पेज का संदेश दिखाएं, लेकिन जहां आपकी सेटिंग अनुमति दे वहां 404 status के साथ। Search engines 200 status के साथ 'not found' संदेश को soft 404 मानते हैं, जिससे crawl का समय बर्बाद होता है और indexing में गड़बड़ी हो सकती है।