வலைத்தளம் அல்லது ஆப்பை deploy செய்த பின் 404 பிழைகளை எப்படிச் சரிசெய்வது

உங்கள் ஆப் உள்ளூரில் வேலை செய்து deploy-க்குப் பின் பக்கங்கள் 404 தந்தால், மிகப் பொதுவான காரணம் ஒரே பக்க ஆப் (SPA) routing இல்லாதது: அந்த route JavaScript-இல் மட்டுமே உள்ளதால், சர்வர் இல்லாத /dashboard கோப்பைத் தேடுகிறது. தீர்வு என்னவென்றால், ஆப் routes-க்கு index.html-ஐ வழங்கும் fallback விதி. மற்ற காரணங்கள்: build output-இல் விடுபட்ட கோப்புகள், எழுத்து வடிவம் சார்ந்த பாதைகள், trailing slash வேறுபாடுகள், தவறான base path, மற்றும் ஒருபோதும் deploy செய்யப்படாத API routes.

எந்த URL 404 தருகிறது, அதற்கு எப்படி வந்தீர்கள் என்பதை முதலில் குறித்துக்கொள்ளுங்கள். வடிவம் நேரடியாக காரணத்தைச் சுட்டும்.

படி 1: வடிவத்தைக் கண்டறியுங்கள்

உண்மையான status code-ஐப் பார்க்க, developer tools-ஐத் திறந்து (வலது-கிளிக் → Inspect), Network tab-க்குச் சென்று, reload செய்து, முதல் request-இன் status-ஐப் பாருங்கள்.

படி 2: SPA fallback-ஐச் சேர்க்கவும்

இது உன்னதமான ஒன்று. React, Vue அல்லது Svelte ஒரே பக்க ஆப்பில், சர்வரிடம் சில உண்மையான கோப்புகளே உள்ளன: index.html மற்றும் சில JavaScript, CSS. /dashboard அல்லது /projects/42 போன்ற routes உலாவியில் உள்ள router-ஆல் கையாளப்படுகின்றன.

• இணைப்பைக் கிளிக் செய்வது வேலை செய்கிறது: router URL-ஐ மாற்றி, சர்வரிடம் கேட்காமல் புதிய பக்கத்தை வரைகிறது.
• refresh செய்வது அல்லது இணைப்பை நேரடியாகத் திறப்பது தோல்வியடைகிறது: உலாவி /dashboard-ஐ சர்வரிடம் கேட்கிறது, அப்படி ஒரு கோப்பு இல்லாததால் 404 வருகிறது.

தீர்வு ஒரு விதி: கோரிக்கை உண்மையான கோப்புடன் பொருந்தவில்லையென்றால், 200 நிலையுடன் index.html-ஐ வழங்கி, router பொறுப்பேற்கட்டும். அதை எப்படிச் சேர்ப்பது என்பது ஹோஸ்டைப் பொறுத்தது (விவரங்கள் மாறுவதால் உங்கள் ஹோஸ்டின் தற்போதைய ஆவணங்களைச் சரிபாருங்கள்):

விதி உண்மையான கோப்புகளை விழுங்காமல் பார்த்துக்கொள்ளுங்கள்: /assets/app.js கோரிக்கைகள் இன்னும் JavaScript கோப்பையே திருப்பித் தர வேண்டும். அதற்குப் பதிலாக index.html வந்தால், "Failed to load module script" பிழையுடன் வெற்றுப் பக்கம் கிடைக்கும். வெற்று வெள்ளைப் பக்கத்தைச் சரிசெய்வது பாருங்கள்.

எந்தப் பக்கத்துடனும் பொருந்தாத URL-கள் ஒன்றும் காட்டாமல், நட்பான "Page not found" காட்டும் வகையில் router-க்கு ஒரு catch-all route கொடுக்கவும்.

சர்வர் அமைப்புகளை மாற்ற முடியாவிட்டால், hash routing (/#/dashboard போன்ற URL-கள்) பிரச்சனையைத் தவிர்க்கும், ஏனெனில் #-க்குப் பின் உள்ள பகுதி ஒருபோதும் சர்வருக்கு அனுப்பப்படுவதில்லை. அது முதல் தேர்வு அல்ல, ஒரு தீர்வு மட்டுமே: URL-கள் அழகற்றவை, தேடுபொறிகளுக்கும் குறைந்த நட்பானவை.

சர்வரில் பக்கங்களை வழங்கும் அல்லது build நேரத்தில் உருவாக்கும் framework-கள் (Next.js, Astro போன்றவை) பொதுவாக ஒவ்வொரு பக்கத்துக்கும் உண்மையான கோப்புகள் அல்லது சர்வர் routes கொண்டிருக்கும், எனவே அங்கு இந்தச் சிக்கல் குறைவு. அவற்றின் சமமானது: build நேரத்தில் உருவாக்கப்படாத ஒரு பக்கம்.

படி 3: உண்மையில் என்ன deploy ஆனது என்று சரிபாருங்கள்

எல்லாமே 404 என்றால், சர்வர் உங்கள் build செய்யப்பட்ட ஆப்பை வழங்கவில்லை.

• சரியான கோப்புறை. ஹோஸ்ட் build output-ஐ (Vite-க்கு பொதுவாக dist, Create React App-க்கு build, நிலையான Next.js export-க்கு out) வெளியிட வேண்டும், திட்ட root-ஐ அல்ல.
• Build இயங்கியது. Deploy log-ஐப் படியுங்கள். Build தோல்வியடைந்திருந்தால், ஹோஸ்ட் எதையும் deploy செய்திருக்காமல் இருக்கலாம், அல்லது பழைய பதிப்பை deploy செய்திருக்கலாம்.
• index.html மேல்நிலையில் வெளியிடப்பட்ட கோப்புறையில் இருக்கிறது, ஒரு துணைக் கோப்புறையில் அல்ல.
• Base path பொருந்துகிறது. ஆப் example.com/app/-இல் வழங்கப்பட்டால், அந்த base-உடன் build செய்யப்பட வேண்டும் (Vite-இன் base, React Router-இன் basename), இல்லையென்றால் ஒவ்வொரு route-உம் asset-உம் தவறும்.

படி 4: விடுபட்ட கோப்புகளையும் தவறான பாதைகளையும் சரிசெய்யுங்கள்

பக்கங்கள் ஏற்றப்பட்டு assets 404 தந்தால்:

• எழுத்து வடிவ உணர்திறன். macOS மற்றும் Windows பொதுவாக Logo.png மற்றும் logo.png-ஐ ஒரே கோப்பாகக் கருதும். பெரும்பாலான Linux சர்வர்கள் அப்படிச் செய்வதில்லை. ஒவ்வொரு குறிப்பும் உண்மையான கோப்புப் பெயருடன் சரியாகப் பொருந்த வேண்டும்.
• Build-க்கு வெளியே உள்ள கோப்புகள். Vite-இல், public/-இல் உள்ள கோப்புகள் அப்படியே நகலெடுக்கப்பட்டு root-இலிருந்து குறிப்பிடப்படுகின்றன (/logo.png). குறியீட்டில் import செய்யப்படும் கோப்புகள் bundle ஆகின்றன. திட்டத்தில் வேறெங்காவது உள்ள கோப்பு deploy செய்யப்படாமல் இருக்கலாம்.
• உறவுப் பாதைகள் (Relative paths). images/photo.jpg தற்போதைய URL-உடன் தொடர்புடையதாகத் தீர்க்கப்படுவதால் /blog/post-1-இல் உடைகிறது. /images/photo.jpg பயன்படுத்தவும்.
• உள்ளூர் வட்டுக்கு சேமிக்கப்பட்ட பதிவேற்றங்கள். பயனர்களின் பதிவேற்றங்கள் சர்வரின் சொந்தக் கோப்புறையில் எழுதப்பட்டிருந்தால், புதிய பதிப்பு deploy ஆகும்போது அவை மறைந்துவிடும். சரியான கோப்பு சேமிப்பகத்தைப் பயன்படுத்தவும்.

படி 5: trailing slash-ஐ சீராகக் கையாளுங்கள்

/about மற்றும் /about/ வெவ்வேறு URL-கள். ஹோஸ்ட்கள் slash-ஐச் சேர்க்கிறதா அல்லது நீக்குகிறதா என்பதில் வேறுபடுகின்றன, உங்கள் இணைப்புகளுக்கும் router-க்கும் பொருந்தாமை 404 அல்லது redirect loop-களை உருவாக்கலாம். ஒரு பாணியைத் தேர்ந்தெடுத்து, உங்கள் இணைப்புகள் அதைப் பயன்படுத்துமாறு செய்து, மற்ற வடிவத்தை இதற்குத் திருப்பிவிடுமாறு ஹோஸ்டை அமையுங்கள். சீரான தன்மை தேடுபொறிகளுக்கும் உதவும், இல்லையென்றால் ஒவ்வொரு பக்கத்தின் இரண்டு நகல்களை அவை காணலாம்.

படி 6: 404 தரும் API routes-ஐ சரிசெய்யுங்கள்

பக்கம் ஏற்றப்பட்டு ஆனால் Network tab /api/... கோரிக்கைகளுக்கு 404 காட்டினால்:

• Backend deploy செய்யப்படவில்லை. நிலையான ஹோஸ்ட் கோப்புகளை மட்டுமே வழங்கும்; backend எங்காவது இயங்க வேண்டும்.
• Production-இல் பாதை வேறுவிதமாக route செய்யப்படுகிறது. Development-இல், ஒரு proxy /api-ஐ தனி சர்வருக்கு அனுப்பியிருக்கலாம். Production-இல், ஹோஸ்டுக்கு சமமான rewrite தேவை, அல்லது frontend API-யின் உண்மையான முகவரியை அழைக்க வேண்டும்.
• SPA fallback அதைப் பிடித்தது. 200 நிலையுடன் index.html-ஐ திருப்பும் API கோரிக்கை என்றால், fallback விதி மிகவும் பரந்தது. அதிலிருந்து /api/*-ஐ விலக்குங்கள்.

வெளியிடப்பட்ட ஆப்பின் /api/orders கோரிக்கைகள் 404 தருகின்றன, ஆனால் preview-வில் வேலை செய்கின்றன. Preview மற்றும் வெளியிடப்பட்ட ஆப்பில் /api எப்படி route செய்யப்படுகிறது என்று சரிபார்த்து, வெளியிடப்பட்ட frontend backend-ஐ அதே வழியில் அடையச் செய்யுங்கள்.

படி 7: பழைய URL-களை திருப்பிவிடுங்கள்

வேறு தளத்திலிருந்து நகர்ந்திருந்தாலோ கட்டமைப்பை மாற்றியிருந்தாலோ, மக்களும் தேடுபொறிகளும் இன்னும் பயன்படுத்தும் பழைய URL-கள் 404 ஆகும். ஒவ்வொரு பழைய URL-இலிருந்தும் அதன் புதிய இருப்பிடத்துக்கு 301 (நிரந்தர) redirect சேர்க்கவும். ஒரு பட்டியலை வைத்திருந்து, வெளியீட்டுக்குப் பின் ஒரு மாதிரியைச் சோதிக்கவும். அந்தப் பட்டியலைக் கட்டுவது பற்றி எங்கள் WordPress தளத்தை மாற்றுவது வழிகாட்டி விளக்குகிறது.

படி 8: domain-ஐச் சரிபாருங்கள்

ஆப் ஹோஸ்டின் முகவரியில் வேலை செய்து, உங்கள் தனிப்பயன் domain-இல் 404 தந்தால், domain தவறான திட்டத்தைச் சுட்டிக்கொண்டிருக்கலாம், அல்லது ஹோஸ்ட் இன்னும் domain-ஐ உங்கள் தளத்துடன் இணைக்கவில்லை. DNS பதிவுகளையும் ஹோஸ்டின் domain அமைப்புகளையும் சரிபாருங்கள். தனிப்பயன் domain-ஐ எப்படி இணைப்பது பாருங்கள்.

உங்கள் உண்மையான 404 பக்கத்தை பயனுள்ளதாக்குங்கள்

சில 404-கள் சரியானவை: யாரோ URL-ஐ தவறாகத் தட்டச்சு செய்துள்ளனர். அந்தப் பக்கத்தை உதவிகரமாக்குங்கள்:

• ஒரு குறுகிய செய்தியும் முகப்புப் பக்கத்துக்கும் முக்கியப் பகுதிகளுக்கும் இணைப்பும்
• தளத்தில் தேடல் இருந்தால் ஒரு தேடல் பெட்டி
• மற்ற தளத்தின் அதே header மற்றும் navigation

உங்கள் அமைப்பு அனுமதிக்கும் இடத்தில், இல்லாத பக்கங்களுக்கு ஒரு உண்மையான 404 நிலையை திருப்பித் தாருங்கள். 200 நிலையுடன் திருப்பி அனுப்பப்படும் "not found" செய்தியை தேடுபொறிகள் soft 404 என்கின்றன; அது அவற்றின் crawl நேரத்தை வீணாக்கி index செய்வதைக் குழப்பும்.

பொதுவான தவறுகள்

• கிளிக் செய்வதன் மூலம் மட்டும் சோதிப்பது. எப்போதும் ஆழமான URL-களை புதிய tab-இல் ஒட்டி refresh செய்து சோதியுங்கள்.
• எல்லாவற்றையும் பிடிக்கும் fallback. Assets மற்றும் API routes index.html-ஐத் திருப்புகின்றன, இது வெற்றுப் பக்கங்களையும் குழப்பும் API பிழைகளையும் உருவாக்குகிறது.
• சர்வரில் மட்டும் உடையும் பொருந்தாத எழுத்து வடிவம்.
• Build output-க்குப் பதிலாக source கோப்புறையை deploy செய்வது.
• Redirects இல்லாமல் URL-களை மறுகட்டமைப்பது. ஒவ்வொரு பழைய இணைப்பும் 404 ஆகிறது.

Mythex-இல் 404-கள்

Mythex-இல் நீங்கள் workspace-இலிருந்து வெளியிடுகிறீர்கள், நிலையான front end-கள் நிலையான தளங்களாக deploy ஆகின்றன. வெளியிடப்பட்ட பக்கம் 404 தந்தால், சரியான URL-ஐயும், refresh-இல் நடக்கிறதா அல்லது கிளிக்கில் நடக்கிறதா என்பதையும், Network tab என்ன காட்டுகிறது என்பதையும் agent-க்குக் கொடுத்து routing-ஐச் சரிபார்க்கச் சொல்லுங்கள். நீங்கள் மீண்டும் வெளியிடும் வரை நேரடி ஆப் ஒரு நகல் மட்டுமே என்பதால், சரிசெய்தலுக்குப் பிறகு மீண்டும் வெளியிடுங்கள். சமீபத்தில் திட்டத்தை மாற்றி, நேரடித் தளம் பழையதாகத் தெரிந்தால், மீண்டும் வெளியிட்டு hard-refresh செய்யுங்கள். Build தோல்வியடைந்தால் வெளியீட்டு உரையாடலில் Fix with AI பயன்படுத்துங்கள். ஆவணங்களில் How to publish மற்றும் Publish troubleshooting பாருங்கள், மேலும் எங்கள் AI-உருவாக்கிய ஆப்பை debug செய்வது வழிகாட்டியையும் பாருங்கள்.

404 சரிபார்ப்புப் பட்டியல்

• எந்த URL-கள் 404 தருகின்றன என்றும் கிளிக், refresh அல்லது இரண்டிலும் நடக்கிறதா என்றும் குறித்தாயிற்று
• SPA fallback ஆப் routes-க்கு 200 நிலையுடன் index.html-ஐ வழங்குகிறது
• Fallback உண்மையான கோப்புகளையும் /api/*-ஐயும் விலக்குகிறது
• Router-க்கு catch-all "not found" route உள்ளது
• Build output கோப்புறையே வெளியிடப்படுகிறது, build வெற்றிகரமாக முடிந்தது
• Base path ஆப் வழங்கப்படும் இடத்துடன் பொருந்துகிறது
• கோப்புப் பெயர் எழுத்து வடிவம் ஒவ்வொரு குறிப்புடனும் பொருந்துகிறது
• Asset பாதைகள் / உடன் தொடங்குகின்றன
• Trailing-slash பாணி சீராக உள்ளது
• API routes production-இல் deploy செய்யப்பட்டு route செய்யப்பட்டுள்ளன
• பழைய URL-களுக்கு 301 redirects
• ஆழமான இணைப்புகள் புதிய tab-இல் ஒட்டி சோதிக்கப்பட்டன

கேள்விகள்