വെബ്സൈറ്റോ ആപ്പോ deploy ചെയ്ത ശേഷമുള്ള 404 പിശകുകൾ എങ്ങനെ പരിഹരിക്കാം
നിങ്ങളുടെ ആപ്പ് ലോക്കലായി പ്രവർത്തിക്കുകയും deploy ചെയ്ത ശേഷം പേജുകൾ 404 നൽകുകയും ചെയ്യുന്നെങ്കിൽ, ഏറ്റവും സാധാരണ കാരണം single-page app (SPA) റൂട്ടിംഗ് കാണാനില്ലാത്തതാണ്: /dashboard എന്ന ഫയൽ സെർവർ തിരയുന്നു, പക്ഷേ ആ റൂട്ട് JavaScript-ൽ മാത്രമേ ഉള്ളൂ. പരിഹാരം ആപ്പ് റൂട്ടുകൾക്ക് index.html നൽകുന്ന ഒരു fallback നിയമമാണ്. മറ്റു കാരണങ്ങൾ: ബിൽഡ് ഔട്ട്പുട്ടിൽ നഷ്ടമായ ഫയലുകൾ, കേസ്-സെൻസിറ്റീവ് പാതകൾ, trailing-slash വ്യത്യാസങ്ങൾ, തെറ്റായ base path, ഒരിക്കലും deploy ചെയ്യാത്ത API റൂട്ടുകൾ.
ഏത് URL ആണ് 404 ആകുന്നതെന്നും നിങ്ങൾ അവിടെ എങ്ങനെ എത്തി എന്നും ആദ്യം കുറിച്ചുവെക്കുക. പാറ്റേൺ നേരിട്ട് കാരണത്തിലേക്ക് വിരൽ ചൂണ്ടും.
ഘട്ടം 1: പാറ്റേൺ കണ്ടെത്തുക
| നിങ്ങൾ കാണുന്നത് | ഏറ്റവും സാധ്യതയുള്ള കാരണം | പോകേണ്ടത് |
|---|---|---|
| ഹോം പേജ് പ്രവർത്തിക്കുന്നു; ലിങ്കുകൾ ക്ലിക്ക് ചെയ്യുന്നത് പ്രവർത്തിക്കുന്നു; പക്ഷേ refresh ചെയ്യുമ്പോഴോ നേരിട്ടുള്ള ലിങ്ക് തുറക്കുമ്പോഴോ 404 | SPA fallback ഇല്ല | ഘട്ടം 2 |
| എല്ലാ പേജുകളും 404, ഹോം പേജും ഉൾപ്പെടെ | തെറ്റായ ഫോൾഡർ publish ചെയ്തു, അല്ലെങ്കിൽ ബിൽഡ് deploy ആയില്ല | ഘട്ടം 3 |
| പേജുകൾ ലോഡ് ആകുന്നു, പക്ഷേ ചിത്രങ്ങൾ, ഫോണ്ടുകൾ അല്ലെങ്കിൽ സ്ക്രിപ്റ്റുകൾ 404 | ബിൽഡിൽ ഫയലുകൾ നഷ്ടമായി, അല്ലെങ്കിൽ തെറ്റായ പാതകൾ | ഘട്ടം 4 |
/about/-ൽ പ്രവർത്തിക്കുന്നു, /about-ൽ പരാജയപ്പെടുന്നു (അല്ലെങ്കിൽ തിരിച്ച്) | Trailing-slash കൈകാര്യം ചെയ്യൽ | ഘട്ടം 5 |
/About പരാജയപ്പെടുന്നു, /about പ്രവർത്തിക്കുന്നു | കേസ്-സെൻസിറ്റീവ് സെർവർ | ഘട്ടം 4 |
പേജ് ലോഡ് ആകുന്നു, പക്ഷേ /api/... ഡാറ്റാ കോളുകൾ 404 | API deploy ചെയ്തിട്ടില്ല അല്ലെങ്കിൽ റൂട്ട് ചെയ്തിട്ടില്ല | ഘട്ടം 6 |
| മുൻ സൈറ്റിൽ നിന്നുള്ള പഴയ URL-കൾ 404 | റീഡയറക്ടുകൾ നഷ്ടമായി | ഘട്ടം 7 |
| കസ്റ്റം ഡൊമെയ്നിൽ മാത്രം | DNS അല്ലെങ്കിൽ ഡൊമെയ്ൻ സെറ്റപ്പ് | ഘട്ടം 8 |
യഥാർത്ഥ സ്റ്റാറ്റസ് കോഡ് കാണാൻ, ഡെവലപ്പർ ടൂളുകൾ തുറക്കുക (വലത് ക്ലിക്ക് → Inspect), Network ടാബിൽ പോകുക, reload ചെയ്യുക, ആദ്യ റിക്വസ്റ്റിന്റെ സ്റ്റാറ്റസ് നോക്കുക.
ഘട്ടം 2: SPA fallback ചേർക്കുക
ഇതാണ് ക്ലാസിക് കാരണം. React, Vue അല്ലെങ്കിൽ Svelte സിംഗിൾ-പേജ് ആപ്പിൽ സെർവറിന് കുറച്ച് യഥാർത്ഥ ഫയലുകളേ ഉള്ളൂ: index.html, കുറച്ച് JavaScript, CSS. /dashboard അല്ലെങ്കിൽ /projects/42 പോലുള്ള റൂട്ടുകൾ ബ്രൗസറിലെ ഒരു റൂട്ടർ കൈകാര്യം ചെയ്യുന്നു.
- ലിങ്കിൽ ക്ലിക്ക് ചെയ്യുന്നത് പ്രവർത്തിക്കുന്നു: റൂട്ടർ URL മാറ്റി സെർവറോട് ചോദിക്കാതെ പുതിയ പേജ് വരയ്ക്കുന്നു.
- Refresh ചെയ്യുന്നതോ ലിങ്ക് നേരിട്ട് തുറക്കുന്നതോ പരാജയപ്പെടുന്നു: ബ്രൗസർ സെർവറിനോട്
/dashboardആവശ്യപ്പെടുന്നു, സെർവറിന് അങ്ങനെയൊരു ഫയലില്ല, അത് 404 നൽകുന്നു.
പരിഹാരം ഇങ്ങനെയൊരു നിയമമാണ്: അഭ്യർത്ഥന ഒരു യഥാർത്ഥ ഫയലുമായി ചേരുന്നില്ലെങ്കിൽ, 200 സ്റ്റാറ്റസോടെ index.html നൽകുക, റൂട്ടർ ബാക്കി ഏറ്റെടുക്കട്ടെ. ഇത് എങ്ങനെ ചേർക്കും എന്നത് ഹോസ്റ്റിനെ ആശ്രയിച്ചിരിക്കുന്നു (വിശദാംശങ്ങൾ മാറുന്നതിനാൽ ഹോസ്റ്റിന്റെ നിലവിലെ ഡോക്സ് പരിശോധിക്കുക):
| ഹോസ്റ്റ് | സാധാരണ fallback നിയമം |
|---|---|
| Netlify | publish ചെയ്യുന്ന ഫോൾഡറിൽ /* /index.html 200 എന്ന വരിയുള്ള _redirects ഫയൽ |
| Vercel | എല്ലാ പാതകളും index.html-ലേക്ക് അയക്കുന്ന vercel.json-ലെ rewrite (framework presets പലപ്പോഴും ഇത് കൈകാര്യം ചെയ്യും) |
| Cloudflare Pages | ടോപ്-ലെവൽ 404.html ഇല്ലെങ്കിൽ, സ്ഥിരസ്ഥിതിയായി SPA-ശൈലിയിലുള്ള fallback നൽകുന്നു |
| Nginx | location / ബ്ലോക്കിൽ try_files $uri $uri/ /index.html; |
| Apache | ഫയൽ അല്ലാത്ത അഭ്യർത്ഥനകളെ index.html-ലേക്ക് അയക്കുന്ന .htaccess-ലെ rewrite നിയമം |
| GitHub Pages | സെർവർ-സൈഡ് rewrite-കൾ ഇല്ല; സാധാരണ workaround-കൾ hash റൂട്ടിംഗ് അല്ലെങ്കിൽ റീഡയറക്ട് ചെയ്യുന്ന 404.html |
ഈ നിയമം യഥാർത്ഥ ഫയലുകളെ വിഴുങ്ങുന്നില്ല എന്ന് ഉറപ്പാക്കുക: /assets/app.js-ന്റെ അഭ്യർത്ഥന JavaScript ഫയൽ തന്നെ തിരിച്ചു നൽകണം. പകരം index.html കിട്ടുന്നെങ്കിൽ, "Failed to load module script" പിശകോടെ ശൂന്യമായ പേജ് ലഭിക്കും. വെളുത്ത ശൂന്യ പേജ് എങ്ങനെ പരിഹരിക്കാം കാണുക.
കൂടാതെ, ഏതെങ്കിലും പേജുമായി ചേരാത്ത URL-കൾ ഒന്നും കാണിക്കാതെ പകരം സൗഹൃദപരമായ "Page not found" കാണിക്കാൻ റൂട്ടറിന് ഒരു catch-all റൂട്ട് നൽകുക.
സെർവർ സെറ്റിംഗ്സ് മാറ്റാനായില്ലെങ്കിൽ, hash റൂട്ടിംഗ് (/#/dashboard പോലുള്ള URL-കൾ) പ്രശ്നം ഒഴിവാക്കുന്നു, കാരണം #-ന് ശേഷമുള്ള ഭാഗം ഒരിക്കലും സെർവറിലേക്ക് അയക്കില്ല. അത് ഒരു workaround മാത്രമാണ്, ആദ്യ ചോയ്സ് അല്ല: URL-കൾ അത്ര ഭംഗിയുള്ളതല്ല, സെർച്ച് എഞ്ചിനുകൾക്കും അത്ര സൗഹൃദമല്ല.
സെർവറിൽ പേജുകൾ റെൻഡർ ചെയ്യുന്നതോ ബിൽഡ് സമയത്ത് സൃഷ്ടിക്കുന്നതോ ആയ ഫ്രെയിംവർക്കുകളിൽ (Next.js, Astro, സമാനമായവ) ഓരോ പേജിനും സാധാരണയായി യഥാർത്ഥ ഫയലുകളോ സെർവർ റൂട്ടുകളോ ഉണ്ടാകും, അതിനാൽ ഈ പ്രശ്നം അവിടെ അപൂർവമാണ്. അവയ്ക്ക് തുല്യമായ പ്രശ്നം ബിൽഡ് സമയത്ത് ജനറേറ്റ് ചെയ്യാത്ത പേജാണ്.
ഘട്ടം 3: യഥാർത്ഥത്തിൽ എന്ത് deploy ചെയ്തു എന്ന് പരിശോധിക്കുക
എല്ലാം 404 ആകുന്നെങ്കിൽ, സെർവർ നിങ്ങളുടെ ബിൽറ്റ് ആപ്പ് നൽകുന്നില്ലായിരിക്കാം.
- ശരിയായ ഫോൾഡർ. ഹോസ്റ്റ് ബിൽഡ് ഔട്ട്പുട്ട് (സാധാരണയായി Vite-ന്
dist, Create React App-ന്build, Next.js static export-ന്out) publish ചെയ്യണം, പ്രോജക്റ്റിന്റെ റൂട്ട് അല്ല. - ബിൽഡ് പ്രവർത്തിച്ചു. deploy log വായിക്കുക. ബിൽഡ് പരാജയപ്പെട്ടാൽ ഹോസ്റ്റ് ഒന്നും deploy ചെയ്തിരിക്കില്ല, അല്ലെങ്കിൽ പഴയ പതിപ്പ് ആയിരിക്കും.
index.htmlpublish ചെയ്ത ഫോൾഡറിന്റെ മുകളിലെ തട്ടിൽ ആയിരിക്കണം, ഒരു ഉപഫോൾഡറിനുള്ളിൽ അല്ല.- Base path ഒത്തുപോകുന്നു. ആപ്പ്
example.com/app/-ൽ സേവനം ചെയ്യുന്നെങ്കിൽ, ആ base-ൽ തന്നെ ബിൽഡ് ചെയ്യണം (Vite-ന്റെbase, React Router-ന്റെbasename), അല്ലെങ്കിൽ എല്ലാ റൂട്ടുകളും അസറ്റുകളും കാണാതാകും.
ഘട്ടം 4: നഷ്ടമായ ഫയലുകളും തെറ്റായ പാതകളും പരിഹരിക്കുക
പേജുകൾ ലോഡ് ആകുന്നെങ്കിലും അസറ്റുകൾ 404 ആകുമ്പോൾ:
- വലിയക്ഷരം-ചെറിയക്ഷരം. macOS, Windows എന്നിവ സാധാരണയായി
Logo.png-ഉംlogo.png-ഉം ഒരേ ഫയലായി കാണുന്നു. മിക്ക Linux സെർവറുകളും അങ്ങനെയല്ല. ഓരോ റഫറൻസും യഥാർത്ഥ ഫയൽ പേരുമായി കൃത്യമായി ചേർക്കുക. - ബിൽഡിന് പുറത്തുള്ള ഫയലുകൾ. Vite-ൽ
public/-ലെ ഫയലുകൾ മാറ്റമില്ലാതെ പകർത്തി റൂട്ടിൽ നിന്ന് (/logo.png) റഫർ ചെയ്യുന്നു. കോഡിൽ import ചെയ്യുന്ന ഫയലുകൾ ബണ്ടിൽ ചെയ്യപ്പെടുന്നു. പ്രോജക്റ്റിൽ മറ്റെവിടെയെങ്കിലുമുള്ള ഒരു ഫയൽ ഒട്ടും deploy ചെയ്യപ്പെടാത്തതാകാം. - Relative പാതകൾ.
images/photo.jpgനിലവിലെ URL-ന്റെ അടിസ്ഥാനത്തിൽ resolve ചെയ്യപ്പെടുന്നതിനാൽ/blog/post-1-ൽ അത് തകരുന്നു./images/photo.jpgഉപയോഗിക്കുക. - ലോക്കൽ ഡിസ്കിൽ സേവ് ചെയ്ത അപ്ലോഡുകൾ. ഉപയോക്താക്കളുടെ അപ്ലോഡുകൾ സെർവറിന്റെ സ്വന്തം ഫോൾഡറിൽ എഴുതിയിരുന്നെങ്കിൽ, പുതിയ പതിപ്പ് deploy ചെയ്യുമ്പോൾ അവ ഇല്ലാതാകും. ശരിയായ ഫയൽ സ്റ്റോറേജ് ഉപയോഗിക്കുക.
ഘട്ടം 5: trailing slash സ്ഥിരമായി കൈകാര്യം ചെയ്യുക
/about, /about/ എന്നിവ വ്യത്യസ്ത URL-കളാണ്. ഹോസ്റ്റുകൾ slash ചേർക്കണോ നീക്കണോ എന്നതിൽ വ്യത്യസ്തരാണ്, നിങ്ങളുടെ ലിങ്കുകളുമായോ റൂട്ടറുമായോ പൊരുത്തക്കേട് 404 അല്ലെങ്കിൽ redirect loop ഉണ്ടാക്കാം. ഒരു ശൈലി തിരഞ്ഞെടുക്കുക, ലിങ്കുകൾ അതേ ശൈലി ഉപയോഗിക്കട്ടെ, മറ്റേ രൂപം ഇതിലേക്ക് redirect ചെയ്യാൻ ഹോസ്റ്റ് കോൺഫിഗർ ചെയ്യുക. സ്ഥിരത സെർച്ച് എഞ്ചിനുകളെയും സഹായിക്കുന്നു, അല്ലെങ്കിൽ അവർ ഓരോ പേജിന്റെയും രണ്ട് കോപ്പികൾ കാണും.
ഘട്ടം 6: 404 ആകുന്ന API റൂട്ടുകൾ പരിഹരിക്കുക
പേജ് ലോഡ് ആകുന്നെങ്കിലും Network ടാബിൽ /api/... അഭ്യർത്ഥനകൾ 404 നൽകുന്നെങ്കിൽ:
- ബാക്ക് എൻഡ് deploy ചെയ്തിട്ടില്ല. സ്റ്റാറ്റിക് ഹോസ്റ്റ് ഫയലുകൾ മാത്രമേ നൽകൂ; ബാക്ക് എൻഡ് എവിടെയെങ്കിലും പ്രവർത്തിക്കണം.
- ഉൽപ്പാദനത്തിൽ പാത വ്യത്യസ്തമായി റൂട്ട് ചെയ്യപ്പെടുന്നു. ഡെവലപ്മെന്റിൽ ഒരു proxy
/apiമറ്റൊരു സെർവറിലേക്ക് അയച്ചിരിക്കാം. ഉൽപ്പാദനത്തിൽ ഹോസ്റ്റിന് തുല്യമായ rewrite വേണം, അല്ലെങ്കിൽ ഫ്രണ്ട് എൻഡ് API-യുടെ യഥാർത്ഥ വിലാസം വിളിക്കണം. - SPA fallback അത് പിടിച്ചെടുത്തു. ഒരു API അഭ്യർത്ഥന 200 സ്റ്റാറ്റസോടെ
index.htmlനൽകുന്നെങ്കിൽ, fallback നിയമം വളരെ വിശാലമാണ്. അതിൽ നിന്ന്/api/*ഒഴിവാക്കുക.
പ്രസിദ്ധീകരിച്ച ആപ്പിന്റെ /api/orders അഭ്യർത്ഥനകൾ 404 നൽകുന്നു, പക്ഷേ പ്രിവ്യൂവിൽ പ്രവർത്തിക്കുന്നു. പ്രിവ്യൂവിലും പ്രസിദ്ധീകരിച്ച ആപ്പിലും /api എങ്ങനെ റൂട്ട് ചെയ്യുന്നു എന്ന് പരിശോധിച്ച്, പ്രസിദ്ധീകരിച്ച ഫ്രണ്ട് എൻഡ് ബാക്ക് എൻഡിൽ അതേ രീതിയിൽ എത്തുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക.
ഘട്ടം 7: പഴയ URL-കൾ റീഡയറക്ട് ചെയ്യുക
മറ്റൊരു സൈറ്റിൽ നിന്ന് മാറുകയോ ഘടന മാറ്റുകയോ ചെയ്തെങ്കിൽ, ആളുകളും സെർച്ച് എഞ്ചിനുകളും ഇപ്പോഴും ഉപയോഗിക്കുന്ന പഴയ URL-കൾ 404 ആകും. ഓരോ പഴയ URL-ൽ നിന്നും അതിന്റെ പുതിയ സ്ഥാനത്തേക്ക് 301 (സ്ഥിരമായ) റീഡയറക്ട് ചേർക്കുക. ഒരു പട്ടിക സൂക്ഷിച്ച് ലോഞ്ചിന് ശേഷം ഒരു സാമ്പിൾ പരിശോധിക്കുക. WordPress സൈറ്റ് മാറ്റുന്നത് സംബന്ധിച്ച ഞങ്ങളുടെ ഗൈഡ് ആ പട്ടിക തയ്യാറാക്കുന്നത് വിശദീകരിക്കുന്നു.
ഘട്ടം 8: ഡൊമെയ്ൻ പരിശോധിക്കുക
ഹോസ്റ്റിന്റെ വിലാസത്തിൽ ആപ്പ് പ്രവർത്തിക്കുന്നെങ്കിലും നിങ്ങളുടെ കസ്റ്റം ഡൊമെയ്നിൽ 404 ആണെങ്കിൽ, ഡൊമെയ്ൻ തെറ്റായ പ്രോജക്റ്റിലേക്ക് ചൂണ്ടുന്നുണ്ടാകാം, അല്ലെങ്കിൽ ഹോസ്റ്റിൽ ഡൊമെയ്ൻ നിങ്ങളുടെ സൈറ്റിനോട് ഇതുവരെ ബന്ധിപ്പിച്ചിട്ടില്ലാകാം. DNS റെക്കോർഡുകളും ഹോസ്റ്റിന്റെ ഡൊമെയ്ൻ സെറ്റിംഗ്സും പരിശോധിക്കുക. ഒരു കസ്റ്റം ഡൊമെയ്ൻ എങ്ങനെ ബന്ധിപ്പിക്കാം കാണുക.
നിങ്ങളുടെ യഥാർത്ഥ 404 പേജ് ഉപയോഗപ്രദമാക്കുക
ചില 404-കൾ ശരിയാണ്: ആരെങ്കിലും URL തെറ്റായി ടൈപ്പ് ചെയ്തതാണ്. ആ പേജ് സഹായകരമാക്കുക:
- ഒരു ചെറിയ സന്ദേശവും ഹോം പേജിലേക്കും പ്രധാന വിഭാഗങ്ങളിലേക്കും ഉള്ള ലിങ്കുകളും
- സൈറ്റിന് സെർച്ച് ഉണ്ടെങ്കിൽ ഒരു സെർച്ച് ബോക്സ്
- സൈറ്റിലെ മറ്റു ഭാഗങ്ങളുടേതിന് സമാനമായ ഹെഡറും നാവിഗേഷനും
നിങ്ങളുടെ സെറ്റപ്പ് അനുവദിക്കുന്നിടത്ത്, ഇല്ലാത്ത പേജുകൾക്ക് യഥാർത്ഥ 404 സ്റ്റാറ്റസ് തിരിച്ചു നൽകുക. 200 സ്റ്റാറ്റസോടെ വരുന്ന "not found" സന്ദേശത്തെ സെർച്ച് എഞ്ചിനുകൾ soft 404 എന്ന് വിളിക്കുന്നു; അത് അവരുടെ crawl സമയം പാഴാക്കുകയും indexing-നെ ആശയക്കുഴപ്പത്തിലാക്കുകയും ചെയ്യും.
സാധാരണ തെറ്റുകൾ
- ക്ലിക്ക് ചെയ്ത് മാത്രം പരീക്ഷിക്കുന്നത്. എപ്പോഴും ആഴമുള്ള URL-കൾ പുതിയ ടാബിൽ ഒട്ടിച്ച് refresh ചെയ്ത് പരീക്ഷിക്കുക.
- എല്ലാം പിടിക്കുന്ന fallback. അസറ്റുകളും API റൂട്ടുകളും
index.htmlനൽകുന്നു, ഇത് ശൂന്യ പേജുകൾക്കും ആശയക്കുഴപ്പമുള്ള API പിശകുകൾക്കും കാരണമാകുന്നു. - സെർവറിൽ മാത്രം പൊട്ടുന്ന വലിയക്ഷരം-ചെറിയക്ഷരം പൊരുത്തക്കേട്.
- സോഴ്സ് ഫോൾഡർ deploy ചെയ്യുന്നത്, ബിൽഡ് ഔട്ട്പുട്ടിന് പകരം.
- റീഡയറക്ടുകളില്ലാതെ URL-കൾ പുനഃക്രമീകരിക്കുന്നത്. ഓരോ പഴയ ലിങ്കും 404 ആകും.
Mythex-ൽ 404-കൾ
Mythex-ൽ നിങ്ങൾ workspace-ൽ നിന്ന് publish ചെയ്യുന്നു, സ്റ്റാറ്റിക് ഫ്രണ്ട് എൻഡുകൾ സ്റ്റാറ്റിക് സൈറ്റുകളായി deploy ചെയ്യപ്പെടുന്നു. ഒരു പ്രസിദ്ധീകരിച്ച പേജ് 404 ആകുന്നെങ്കിൽ, കൃത്യമായ URL, അത് refresh-ലാണോ ക്ലിക്കിലാണോ സംഭവിക്കുന്നത്, Network ടാബ് എന്ത് കാണിക്കുന്നു എന്നിവ ഏജന്റിന് നൽകി റൂട്ടിംഗ് പരിശോധിക്കാൻ ആവശ്യപ്പെടുക. പരിഹാരത്തിന് ശേഷം വീണ്ടും publish ചെയ്യുക, കാരണം നിങ്ങൾ വീണ്ടും publish ചെയ്യുന്നതുവരെ തത്സമയ ആപ്പ് ഒരു സ്നാപ്ഷോട്ട് മാത്രമാണ്. പ്രോജക്റ്റ് അടുത്തിടെ മാറ്റിയിട്ടും തത്സമയ സൈറ്റ് പഴയതായി തോന്നുന്നെങ്കിൽ, വീണ്ടും publish ചെയ്ത് hard-refresh ചെയ്യുക. ബിൽഡ് പരാജയപ്പെട്ടാൽ publish ഡയലോഗിലെ Fix with AI ഉപയോഗിക്കുക. How to publish, ഡോക്സിലെ Publish troubleshooting എന്നിവ കാണുക, കൂടാതെ AI നിർമ്മിച്ച ആപ്പ് ഡീബഗ് ചെയ്യുന്നത് സംബന്ധിച്ച ഞങ്ങളുടെ ഗൈഡും.
404 ചെക്ക്ലിസ്റ്റ്
- ഏത് URL-കൾ 404 ആകുന്നു, അത് ക്ലിക്കിലോ refresh-ലോ രണ്ടിലുമോ എന്ന് കുറിച്ചു
- SPA fallback ആപ്പ് റൂട്ടുകൾക്ക് 200 സ്റ്റാറ്റസോടെ
index.htmlനൽകുന്നു - Fallback യഥാർത്ഥ ഫയലുകളും
/api/*-ഉം ഒഴിവാക്കുന്നു - റൂട്ടറിന് catch-all "not found" റൂട്ടുണ്ട്
- Publish ചെയ്യുന്നത് ബിൽഡ് ഔട്ട്പുട്ട് ഫോൾഡറാണ്, ബിൽഡ് വിജയിച്ചു
- Base path ആപ്പ് സേവനം ചെയ്യുന്ന സ്ഥലവുമായി ഒത്തുപോകുന്നു
- ഫയൽ പേരിന്റെ വലിയക്ഷരം-ചെറിയക്ഷരം ഓരോ റഫറൻസുമായും ചേരുന്നു
- അസറ്റ് പാതകൾ
/ൽ തുടങ്ങുന്നു - Trailing-slash ശൈലി സ്ഥിരം
- API റൂട്ടുകൾ deploy ചെയ്ത് ഉൽപ്പാദനത്തിൽ റൂട്ട് ചെയ്തിരിക്കുന്നു
- പഴയ URL-കൾക്ക് 301 റീഡയറക്ടുകൾ
- Deep links പുതിയ ടാബിൽ ഒട്ടിച്ച് പരീക്ഷിച്ചു
ചോദ്യങ്ങൾ
എന്റെ React ആപ്പിൽ പേജ് refresh ചെയ്യുമ്പോൾ എന്തുകൊണ്ട് 404 വരുന്നു?
സിംഗിൾ-പേജ് ആപ്പിൽ /dashboard പോലുള്ള റൂട്ടുകൾ JavaScript-ൽ മാത്രമേ നിലനിൽക്കൂ. ലിങ്കിൽ ക്ലിക്ക് ചെയ്യുമ്പോൾ റൂട്ടർ ബ്രൗസറിൽ തന്നെ കൈകാര്യം ചെയ്യുന്നതിനാൽ പ്രവർത്തിക്കും, പക്ഷേ refresh ചെയ്യുമ്പോൾ സെർവറിനോട് നിലവിലില്ലാത്ത /dashboard ഫയൽ ആവശ്യപ്പെടുന്നു. ആപ്പ് റൂട്ടുകൾക്ക് index.html നൽകുന്ന ഒരു fallback നിയമമാണ് പരിഹാരം.
Netlify, Vercel അല്ലെങ്കിൽ Nginx-ൽ SPA fallback എങ്ങനെ ചേർക്കാം?
Netlify-ൽ, `/* /index.html 200` എന്ന വരിയുള്ള ഒരു _redirects ഫയൽ ചേർക്കുക. Vercel-ൽ, എല്ലാ പാതകളും /index.html-ലേക്ക് അയക്കുന്ന rewrite `vercel.json`-ൽ ചേർക്കുക. Nginx-ൽ, location ബ്ലോക്കിൽ try_files $uri $uri/ /index.html; ഉപയോഗിക്കുക. നിയമങ്ങൾ മാറുന്നതിനാൽ നിങ്ങളുടെ ഹോസ്റ്റിന്റെ ഡോക്യുമെന്റേഷൻ പരിശോധിക്കുക.
deploy ചെയ്ത ശേഷം എന്റെ ചിത്രങ്ങളോ ഫയലുകളോ എന്തുകൊണ്ട് 404 ആകുന്നു?
സാധാരണയായി ഫയൽ ബിൽഡ് ഔട്ട്പുട്ടിൽ ഇല്ല, അല്ലെങ്കിൽ പാതയുടെ വലിയക്ഷരം-ചെറിയക്ഷരം ചേരുന്നില്ല (നിങ്ങളുടെ ലാപ്ടോപ്പ് വ്യത്യാസം കാണിക്കാത്തിടത്ത് സെർവറുകൾ പലപ്പോഴും കേസ്-സെൻസിറ്റീവ് ആണ്), അല്ലെങ്കിൽ സ്ലാഷിൽ തുടങ്ങേണ്ടിടത്ത് പാത relative ആണ്.
ഇല്ലാത്ത പേജിന് യഥാർത്ഥ 404 സ്റ്റാറ്റസ് നൽകണോ?
അതെ. സഹായകരമായ ഒരു not-found പേജ് നൽകുക, എന്നാൽ നിങ്ങളുടെ സെറ്റപ്പ് അനുവദിക്കുന്നിടത്ത് 404 സ്റ്റാറ്റസോടെ. "Not found" സന്ദേശം 200 സ്റ്റാറ്റസോടെ വന്നാൽ സെർച്ച് എഞ്ചിനുകൾ അതിനെ soft 404 ആയി കാണുന്നു; അത് crawl സമയം പാഴാക്കുകയും indexing-നെ ആശയക്കുഴപ്പത്തിലാക്കുകയും ചെയ്യും.