वेबसाइट किंवा ॲप डिप्लॉय केल्यानंतर 404 एरर कसे दुरुस्त करावे

तुमचे ॲप स्थानिक पातळीवर चालते पण डिप्लॉयनंतर पेजेसना 404 येते, तर सर्वात सामान्य कारण म्हणजे सिंगल-पेज ॲप (SPA) राउटिंग नसणे: सर्व्हर /dashboard नावाची फाइल शोधतो जी अस्तित्वात नसते, कारण तो राउट फक्त JavaScript मध्ये असतो. उपाय म्हणजे ॲप राउट्ससाठी index.html देणारा फॉलबॅक नियम. इतर कारणे म्हणजे बिल्ड आउटपुटमध्ये गहाळ फाइल्स, केस-सेन्सिटिव्ह पाथ, ट्रेलिंग-स्लॅशमधील फरक, चुकीचा बेस पाथ, आणि कधीही डिप्लॉय न झालेले API राउट्स.

नेमका कोणता 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" त्रुटीसह रिकामे पेज मिळेल. रिकामे पांढरे पेज कसे दुरुस्त करावे पहा.

तसेच राउटरला कॅच-ऑल राउट द्या, म्हणजे कोणत्याही पेजशी न जुळणारे URL्स काहीही न दाखवता मैत्रीपूर्ण "पेज सापडले नाही" संदेश दाखवतील.

सर्व्हर सेटिंग्ज बदलता येत नसतील तर हॅश राउटिंग (/#/dashboard सारखे URL्स) समस्या टाळते, कारण # नंतरचा भाग कधीही सर्व्हरला पाठवला जात नाही. हा पहिला पर्याय नसून तात्पुरता उपाय आहे: URL्स कमी सुंदर असतात आणि सर्च इंजिनसाठी कमी अनुकूल.

सर्व्हरवर पेजेस रेंडर करणारे किंवा बिल्ड वेळी ती तयार करणारे फ्रेमवर्क (Next.js, Astro, आणि तत्सम) सहसा प्रत्येक पेजसाठी खऱ्या फाइल्स किंवा सर्व्हर राउट्स देतात, त्यामुळे तिथे ही विशिष्ट समस्या कमी दिसते. त्यांच्याकडील समतुल्य समस्या म्हणजे बिल्ड वेळी कधीही तयार न झालेले पेज.

पायरी 3: प्रत्यक्षात काय डिप्लॉय झाले ते तपासा

सर्व काही 404 देत असेल, तर सर्व्हर कदाचित तुमचे बिल्ड केलेले ॲप सर्व्ह करत नाही.

• योग्य फोल्डर. होस्टने बिल्ड आउटपुट प्रकाशित करायला हवे (Vite साठी सामान्यतः dist, Create React App साठी build, स्टॅटिक Next.js एक्सपोर्टसाठी out), प्रोजेक्टचे रूट नव्हे.
• बिल्ड चालले. डिप्लॉय लॉग वाचा. बिल्ड अयशस्वी झाले असेल तर होस्टने काहीच डिप्लॉय केले नसेल, किंवा जुनी आवृत्ती डिप्लॉय झाली असेल.
• index.html वरच्या पातळीवर प्रकाशित फोल्डरमध्ये आहे, कोणत्याही सब-फोल्डरमध्ये नाही.
• बेस पाथ जुळतो. ॲप example.com/app/ वर सर्व्ह होत असेल तर ते त्या बेससह बिल्ड झाले पाहिजे (Vite चा base, React Router चा basename), नाहीतर प्रत्येक राउट आणि मालमत्ता चुकेल.

पायरी 4: गहाळ फाइल्स आणि चुकीचे पाथ दुरुस्त करा

पेजेस लोड होतात पण मालमत्तांना 404 येते तेव्हा:

• केस-सेन्सिटिव्हिटी. macOS आणि Windows सहसा Logo.png आणि logo.png एकच फाइल मानतात. बहुतेक Linux सर्व्हर तसे मानत नाहीत. प्रत्येक संदर्भ खऱ्या फाइल नावाशी तंतोतंत जुळवा.
• बिल्डबाहेरील फाइल्स. Vite मध्ये public/ मधील फाइल्स जशाच्या तशा कॉपी होतात आणि रूटपासून संदर्भित केल्या जातात (/logo.png). कोडमध्ये इम्पोर्ट केलेल्या फाइल्स बंडल होतात. प्रोजेक्टमध्ये इतरत्र असलेली फाइल कदाचित अजिबात डिप्लॉय होणार नाही.
• रिलेटिव्ह पाथ. images/photo.jpg सध्याच्या URL च्या सापेक्ष सोडवले जाते, त्यामुळे /blog/post-1 वर ते तुटते. /images/photo.jpg वापरा.
• लोकल डिस्कवर सेव्ह केलेल्या अपलोड फाइल्स. वापरकर्त्यांचे अपलोड सर्व्हरच्या स्वतःच्या फोल्डरमध्ये लिहिले असतील, तर नवीन आवृत्ती डिप्लॉय झाल्यावर ते नाहीसे होतात. योग्य फाइल स्टोरेज वापरा.

पायरी 5: ट्रेलिंग स्लॅश सातत्याने हाताळा

/about आणि /about/ वेगळे URL्स आहेत. होस्ट स्लॅश जोडतात की काढतात यात फरक असतो, आणि तुमच्या लिंक्स किंवा राउटरशी जुळत नसेल तर 404 किंवा रीडायरेक्ट लूप येऊ शकतो. एक शैली निवडा, तुमच्या लिंक्स तीच वापरोत, आणि दुसऱ्या स्वरूपाला तिच्याकडे रीडायरेक्ट करण्यासाठी होस्ट कॉन्फिगर करा. सातत्यामुळे सर्च इंजिनलाही मदत होते, जे अन्यथा प्रत्येक पेजच्या दोन प्रती पाहू शकतात.

पायरी 6: 404 देणारे API राउट्स दुरुस्त करा

पेज लोड होते पण Network टॅब /api/... रिक्वेस्ट्सना 404 दाखवत असेल तर:

• बॅकएंड डिप्लॉय नाही. स्टॅटिक होस्ट फक्त फाइल्स सर्व्ह करतो; बॅकएंड कुठेतरी चालावे लागते.
• प्रोडक्शनमध्ये पाथ वेगळ्या प्रकारे राउट होतो. डेव्हलपमेंटमध्ये प्रॉक्सीने /api ला वेगळ्या सर्व्हरकडे पाठवले असेल. प्रोडक्शनमध्ये होस्टला समतुल्य rewrite हवा, किंवा फ्रंटएंडने API चा खरा पत्ता वापरायला हवा.
• SPA फॉलबॅकने ते पकडले. API रिक्वेस्टला 200 स्टेटससह index.html परत येत असेल तर फॉलबॅक नियम खूप व्यापक आहे. त्यातून /api/* वगळा.

प्रकाशित ॲपच्या /api/orders रिक्वेस्ट्सना 404 येते, पण प्रिव्ह्यूमध्ये त्या चालतात. प्रिव्ह्यू आणि प्रकाशित ॲपमध्ये /api कसे राउट होते ते तपासा, आणि प्रकाशित फ्रंटएंड बॅकएंडपर्यंत त्याच प्रकारे पोहोचेल याची खात्री करा.

पायरी 7: जुने URL्स रीडायरेक्ट करा

दुसऱ्या साइटवरून स्थलांतर केले असेल किंवा रचना बदलली असेल, तर लोक आणि सर्च इंजिन अजूनही वापरत असलेले जुने URL्स 404 देतील. प्रत्येक जुन्या URL पासून त्याच्या नव्या ठिकाणापर्यंत 301 (कायमस्वरूपी) रीडायरेक्ट जोडा. एक यादी ठेवा आणि लाँचनंतर नमुना चाचणी करा. ती यादी बनवण्याबद्दल आमचे WordPress साइट स्थलांतरित करण्याचे मार्गदर्शक सांगते.

पायरी 8: डोमेन तपासा

होस्टच्या पत्त्यावर ॲप चालते पण तुमच्या कस्टम डोमेनवर 404 येते, तर डोमेन चुकीच्या प्रोजेक्टकडे निर्देश करत असेल, किंवा होस्टच्या साइटला डोमेन अजून जोडलेले नसेल. DNS रेकॉर्ड्स आणि होस्टच्या डोमेन सेटिंग्ज तपासा. कस्टम डोमेन कसे जोडावे पहा.

तुमचे खरे 404 पेज उपयुक्त बनवा

काही 404 योग्य असतात: कोणी URL चुकीचा टाइप केला. ते पेज उपयुक्त बनवा:

• एक छोटा संदेश आणि होम पेज व महत्त्वाच्या विभागांच्या लिंक्स
• साइटवर शोध असेल तर शोध बॉक्स
• उर्वरित साइटसारखाच हेडर आणि नेव्हिगेशन

तुमची सेटअप परवानगी देत असेल तिथे अस्तित्वात नसलेल्या पेजेससाठी खऱ्या 404 स्टेटसचा परतावा द्या. 200 स्टेटससह परत आलेला "सापडले नाही" संदेश म्हणजे सर्च इंजिन ज्याला सॉफ्ट 404 म्हणतात, आणि त्यामुळे त्यांचा क्रॉल वेळ वाया जातो आणि इंडेक्सिंगमध्ये गोंधळ होतो.

सामान्य चुका

• फक्त क्लिक करून चाचणी. नेहमी खोल URL्स नवीन टॅबमध्ये पेस्ट करून रिफ्रेश करून चाचणी करा.
• सर्वकाही पकडणारा फॉलबॅक. मालमत्ता आणि API राउट्स index.html परत करतात, ज्यामुळे रिकामी पेजेस आणि गोंधळात टाकणाऱ्या API त्रुटी येतात.
• फक्त सर्व्हरवर तुटणारे मोठ्या-लहान अक्षरांतील फरक.
• बिल्ड आउटपुटऐवजी सोर्स फोल्डर डिप्लॉय करणे.
• रीडायरेक्ट्शिवाय URL्सची रचना बदलणे. प्रत्येक जुनी लिंक 404 बनते.

Mythex मधील 404

Mythex मध्ये तुम्ही वर्कस्पेसमधून प्रकाशित करता, आणि स्टॅटिक फ्रंट एंड स्टॅटिक साइट्स म्हणून डिप्लॉय होतात. प्रकाशित पेज 404 देत असेल तर एजंटला नेमका URL द्या, रिफ्रेशवर होते की क्लिकवर, आणि Network टॅबमध्ये काय दिसते ते सांगा, आणि राउटिंग तपासायला सांगा. दुरुस्तीनंतर पुन्हा प्रकाशित करा, कारण तुम्ही पुन्हा प्रकाशित करेपर्यंत लाईव्ह ॲप एक स्नॅपशॉट असतो. तुम्ही प्रोजेक्ट अलीकडे बदलला आणि लाईव्ह साइट जुनी दिसत असेल तर पुन्हा प्रकाशित करा आणि हार्ड-रिफ्रेश करा. बिल्ड अयशस्वी झाल्यास प्रकाशन डायलॉगमधील Fix with AI वापरा. डॉक्समधील How to publish आणि Publish troubleshooting पहा, आणि AI ने बांधलेले ॲप डीबग कसे करावे हे आमचे मार्गदर्शकही पहा.

404 चेकलिस्ट

• नेमके कोणते URL्स 404 देतात ते नोंदवले, आणि क्लिकवर, रिफ्रेशवर, की दोन्हीवर ते ठरवले
• SPA फॉलबॅक ॲप राउट्ससाठी 200 स्टेटससह index.html देतो
• फॉलबॅकमधून खऱ्या फाइल्स आणि /api/* वगळले आहेत
• राउटरमध्ये "सापडले नाही" साठी कॅच-ऑल राउट आहे
• प्रकाशित होणारे फोल्डर बिल्ड आउटपुट आहे, आणि बिल्ड यशस्वी झाले
• बेस पाथ ॲप जिथे सर्व्ह होते त्याच्याशी जुळतो
• फाइल नावांचे मोठे-लहान अक्षर प्रत्येक संदर्भाशी जुळते
• मालमत्ता पाथ / ने सुरू होतात
• ट्रेलिंग-स्लॅश शैली सातत्यपूर्ण आहे
• API राउट्स प्रोडक्शनमध्ये डिप्लॉय आणि राउट केलेले आहेत
• जुन्या URL्ससाठी 301 रीडायरेक्ट्स आहेत
• खोल लिंक्स नवीन टॅबमध्ये पेस्ट करून चाचणी केल्या

प्रश्न