വിപുലമായ റീഡയറക്ട് പരിശോധകനും സാങ്കേതിക SEO വിശകലനിയും

സെർവർ-സൈഡ് അഭ്യർത്ഥനയിൽ നിന്ന് HTTP റീഡയറക്ട് ശൃംഖലകൾ പിന്തുടരുക. തിരഞ്ഞെടുത്ത User-Agent, Client Hints അഭ്യർത്ഥന ഹെഡറുകൾ താരതമ്യം ചെയ്യുക; അഞ്ച് റീഡയറക്ടുകൾ വരെ സ്റ്റാറ്റസും അളന്ന പ്രതികരണസമയവും പരിശോധിക്കുക; HTTPS-ൽ നിന്ന് HTTP-യിലേക്കുള്ള മാറ്റങ്ങൾ കണ്ടെത്തുക. ചെക്കർ ലക്ഷ്യസ്ഥാന JavaScript പ്രവർത്തിപ്പിക്കുകയോ പേജ് HTML പരിശോധിക്കുകയോ ചെയ്യുന്നില്ല.

🌐

തിരഞ്ഞെടുത്ത User-Agent, Client Hints എന്നിവ അഭ്യർത്ഥന-ഹെഡർ പരിശോധനാ പ്രൊഫൈലുകളാണ്; യഥാർത്ഥ ബ്രൗസറിനെയോ ക്രാളറിനെയോ അവ സ്ഥിരീകരിക്കുന്നില്ല.

ഓഡിറ്റ് ഫലങ്ങളും ദൃശ്യ പ്രവാഹവും

⚠️ സുരക്ഷാ മുന്നറിയിപ്പ്: മിക്സഡ് കണ്ടന്റ് കണ്ടെത്തി. ശൃംഖലയിൽ കണക്ഷൻ എൻക്രിപ്റ്റ് ചെയ്യാത്ത HTTP-യിലേക്ക് മാറി.

സമഗ്ര ഉപയോക്തൃ മാർഗ്ഗനിർദ്ദേശവും പ്രായോഗിക പ്രയോഗങ്ങളും

RedirectChecker.Site ഒരു സാധാരണ HTTP ഹെഡർ റീഡർ മാത്രമല്ല; SEO പ്രൊഫഷണലുകൾക്കും സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർക്കും വെബ് ഡെവലപ്പർമാർക്കുമായി നിർമ്മിച്ച പുരോഗമിച്ച നെറ്റ്വർക്ക് ഡയഗ്നോസ്റ്റിക് ഉപകരണമാണ്. ഇതിന്റെ സവിശേഷതകൾ ശരിയായി ഉപയോഗിക്കുന്നത് സെർച്ച് എഞ്ചിൻ റാങ്കിംഗിനെയും ഉപയോക്തൃ അനുഭവത്തെയും ഗുരുതരമായി ബാധിക്കുന്ന സങ്കീർണ്ണ റൂട്ടിംഗ് പ്രശ്നങ്ങൾ കണ്ടെത്താൻ സഹായിക്കും.

1. പരിശോധകൻ ഉപയോഗിക്കുന്ന വിധം: ഘട്ടംഘട്ടമായ നിർദ്ദേശങ്ങൾ

പൂർണ്ണമായ പൊതു URL അതിന്റെ പ്രോട്ടോക്കോൾ ഉൾപ്പെടെ നൽകുക (ഉദാഹരണത്തിന്, https://example.com/old-page). ഒരു സാമ്പിൾ User-Agent തിരഞ്ഞെടുക്കുക; ആവശ്യമെങ്കിൽ, Client Hints ഹെഡർ പ്രൊഫൈലും തിരഞ്ഞെടുക്കുക. തിരഞ്ഞെടുത്ത ഹെഡറുകൾ ഉപയോഗിച്ച് പരിശോധകൻ സെർവർ-സൈഡ് അഭ്യർത്ഥന അയയ്ക്കുന്നു; പൂർണ്ണ ബ്രൗസറിനെയോ കുക്കികളെയോ JavaScript-നെയോ ക്രാളറിന്റെ നെറ്റ്വർക്ക് തിരിച്ചറിയലിനെയോ അനുകരിക്കുന്നില്ല.

2. ഫലങ്ങളും ദൃശ്യ പ്രവാഹ ഉദാഹരണങ്ങളും മനസ്സിലാക്കുക

ക്ലിക്ക് ചെയ്യുക URL പിന്തുടരുക റീഡയറക്ട് ശൃംഖലയിലെ ഓരോ HTTP പ്രതികരണവും, അതിന്റെ സ്റ്റാറ്റസ് കോഡും, അളന്ന അഭ്യർത്ഥന സമയവും, ലഭ്യമെങ്കിൽ അടുത്ത Location URL-വും കാണാൻ. ഒരു പരിശോധന അഞ്ച് റീഡയറക്ടുകൾ വരെ പിന്തുടരും; ശൃംഖല തുടരുകയാണെങ്കിൽ അടുത്ത URL-ലെ പ്രതികരണം ആ പരിശോധനയിൽ ഉൾപ്പെടില്ല.

3. പ്രായോഗിക ഉദാഹരണം: SSL തരംതാഴ്ത്തൽ കണ്ടെത്തൽ

ഒരു റീഡയറക്ട് URL-നെ HTTPS-ൽ നിന്ന് HTTP-യിലേക്ക് തരംതാഴ്ത്താം. HTTPS URL-ന്റെ പ്രതികരണം HTTP Location-ലേക്ക് ചൂണ്ടുന്നതായി കണ്ടെത്തുമ്പോൾ പരിശോധകൻ ഈ മാറ്റം മുന്നറിയിപ്പായി കാണിക്കും. ഫലത്തെ ആശ്രയിക്കുന്നതിന് മുമ്പ് ലക്ഷ്യസ്ഥാനം പരിശോധിക്കുകയും ഉദ്ദേശിച്ച HTTPS പാത ക്രമീകരിക്കുകയും ചെയ്യുക.

സാങ്കേതിക അടിത്തറ: HTTP സ്റ്റാറ്റസ് കോഡുകളും നെറ്റ്വർക്ക് എഞ്ചിനീയറിംഗും

HTTP സ്റ്റാറ്റസ് കോഡുകൾ അഭ്യർത്ഥനയുടെ ഫലം വിവരിക്കുന്നു; 3xx പ്രതികരണങ്ങൾ ക്ലയന്റുകളെ മറ്റൊരു URL-ലേക്ക് നയിക്കുന്നു. സ്ഥിരമായ റീഡയറക്ടുകൾ URL-കൾ ഏകീകരിക്കാൻ സെർച്ച് എഞ്ചിനുകളെ സഹായിക്കാം, എന്നാൽ പ്രത്യേക റാങ്കിംഗോ ഇൻഡെക്സിംഗ് ഫലമോ ഉറപ്പുനൽകുന്നില്ല. ഉദ്ദേശിച്ച സ്ഥിരതയ്ക്ക് അനുയോജ്യമായ സ്റ്റാറ്റസ് കോഡ് ഉപയോഗിച്ച് മുഴുവൻ ശൃംഖലയും അന്തിമ പ്രതികരണവും പരിശോധിക്കുക.

301, 302, 307, 308 എന്നിവ തമ്മിലുള്ള വ്യത്യാസം

  • 301 സ്ഥിരമായി മാറ്റി: വിഭവം സ്ഥിരമായി മാറിയപ്പോൾ ഉപയോഗിക്കുക. സെർച്ച് എഞ്ചിനുകൾ സ്ഥിരമായ റീഡയറക്ടിനെ ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള ശക്തമായ സൂചനയായി കണക്കാക്കുന്നു; എന്നിരുന്നാലും, ഒരു റീഡയറക്ടും നിർദ്ദിഷ്ട റാങ്കിംഗോ ഇൻഡെക്സിംഗ് ഫലമോ ഉറപ്പാക്കുന്നില്ല.
  • 302 കണ്ടെത്തി (താൽക്കാലികം): യഥാർത്ഥ URL വീണ്ടും ലഭ്യമാകുമെന്ന സൂചനയോടെ, മറ്റൊരു URL താൽക്കാലികമായി നോക്കാൻ ക്ലയന്റിനോട് പറയുന്നു. 302 വഴി സ്ഥിരമായ ലിങ്ക് മൂല്യം സെർച്ച് എഞ്ചിനുകൾ സാധാരണയായി കൈമാറുന്നില്ല.
  • 307 താൽക്കാലിക റീഡയറക്ട്: 302-ന്റെ ആധുനിക HTTP/1.1 സമാനമാണ്. പ്രധാനമായി, റീഡയറക്ട് പിന്തുടരുമ്പോൾ HTTP രീതി (GET അല്ലെങ്കിൽ POST) മാറില്ലെന്ന് 307 ഉറപ്പാക്കുന്നു.
  • 308 സ്ഥിരമായ റീഡയറക്ട്: 307-ന്റെ സ്ഥിരമായ പതിപ്പാണ്. SEO ആവശ്യങ്ങൾക്ക് 301 പോലെ പ്രവർത്തിക്കുന്നു; എന്നാൽ POST അഭ്യർത്ഥന GET ആക്കി മാറ്റുന്നത് ബ്രൗസറിനെ കർശനമായി വിലക്കുന്നു.

HTTP പ്രതികരണ സ്റ്റാറ്റസ് കോഡുകൾക്കുള്ള ബ്രൗസർ അനുയോജ്യത

HTTP സ്റ്റാറ്റസ് കോഡുകൾ ബ്രൗസറിന്റെ നെറ്റ്വർക്ക് സ്റ്റാക്ക് കൈകാര്യം ചെയ്യുന്ന പ്രോട്ടോക്കോൾ സൂചനകളാണ്; പ്രത്യേക ബ്രൗസർ സവിശേഷതകളല്ല. ആധുനിക Chrome, Edge, Firefox, Safari, Opera, Android WebView, iPhone WebView എന്നിവ സ്റ്റാൻഡേർഡ് സ്റ്റാറ്റസ് വിഭാഗങ്ങൾ കൈകാര്യം ചെയ്യുന്നു; പിശകിൽ ഉപയോക്താക്കൾക്ക് കാണുന്ന ദൃശ്യം ബ്രൗസറും ഇടനില പ്രോക്സിയും അനുസരിച്ച് മാറാം.

HTTP പ്രതികരണ വിഭാഗംChrome / EdgeFirefoxSafariOperaAndroid / iPhone WebViewപ്രായോഗിക അനുയോജ്യതാ വിശദാംശം
1xx വിവരപ്രദംപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുഅടിസ്ഥാന നെറ്റ്വർക്ക് ലെയർ പിന്തുണയ്ക്കുന്നു100, 101 എന്നിവ സ്ഥിരമായി ഉപയോഗിക്കുന്നു. 102 പ്രത്യേക/കാലഹരണപ്പെട്ടതാണ്; 103 Early Hints-ന്റെ പെരുമാറ്റം പതിപ്പ്, സെർവർ, ഇടനില സംവിധാനം എന്നിവ അനുസരിച്ച് മാറാം.
2xx വിജയംപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപ്രോട്ടോക്കോളിന്റെ അടിസ്ഥാന സെമാന്റിക്സ് ഒരുപോലെയാണ്; 204/205-ൽ പ്രതികരണ ബോഡി ഇല്ലാത്തത് പോലുള്ള ബോഡി നിയമങ്ങൾ തുടർന്നും ബാധകമാണ്.
3xx റീഡയറക്ഷൻപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുരീതി, കാഷെ, സുരക്ഷ, നാവിഗേഷൻ നിയമങ്ങൾ എന്നിവയ്ക്ക് വിധേയമായി ക്ലയന്റുകൾ Location പിന്തുടരുന്നു. 307/308 രീതി നിലനിർത്തുന്നു; 301/302-ൽ POST GET ആയി മാറാം.
4xx ക്ലയന്റ് പിശകുകൾപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപ്രതികരണ വിഭാഗം മനസ്സിലാക്കപ്പെടുന്നുണ്ടെങ്കിലും, സെർവർ ബോഡി കാണിക്കുന്നതും ബ്രൗസർ പിശക് ദൃശ്യം കാണിക്കുന്നതും വ്യത്യാസപ്പെട്ടേക്കാം.
5xx സെർവർ പിശകുകൾപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപിന്തുണയ്ക്കുന്നുപ്രോക്സി പേജുകൾ, വീണ്ടും ശ്രമിക്കുന്ന രീതി, ഡയഗ്നോസ്റ്റിക് അവതരണം എന്നിവ സ്റ്റാറ്റസ് ഒരുപോലെയാണെങ്കിലും വ്യത്യാസപ്പെട്ടേക്കാം.
അറിയപ്പെടുന്ന വിഭാഗത്തിലെ തിരിച്ചറിയാത്ത കോഡ്വിഭാഗതല കൈകാര്യം ചെയ്യൽവിഭാഗതല കൈകാര്യം ചെയ്യൽവിഭാഗതല കൈകാര്യം ചെയ്യൽവിഭാഗതല കൈകാര്യം ചെയ്യൽവിഭാഗതല കൈകാര്യം ചെയ്യൽപൊതുവായ വിഭാഗം മനസ്സിലാക്കാൻ ക്ലയന്റുകൾക്ക് ആദ്യ അക്കത്തെ ആശ്രയിക്കാം. ഈ പകരം കൈകാര്യം ചെയ്യൽ ഒരു കസ്റ്റം കോഡിന് സർവസാധാരണ അർത്ഥം നൽകുന്നില്ല.

ഈ പട്ടിക പ്രോട്ടോക്കോൾ അനുയോജ്യതയാണ് വിവരിക്കുന്നത്; എല്ലാ ബ്രൗസർ പതിപ്പുകളും ഇടക്കാല പ്രതികരണങ്ങൾ ഒരേപോലെ കാണിക്കുമെന്നോ ഒരേ ദൃശ്യമുണ്ടെന്നോ ഉറപ്പുനൽകുന്നില്ല.

ക്ലോക്കിംഗും ഡൈനാമിക് റെൻഡറിംഗും സംബന്ധിച്ച ലംഘനങ്ങൾ

സെർച്ച് എഞ്ചിനുകൾക്കും ആളുകൾക്കും ഗണ്യമായി വ്യത്യസ്ത ഉള്ളടക്കമോ ലക്ഷ്യസ്ഥാനങ്ങളോ കാണിക്കുന്ന രീതിയാണ് ക്ലോക്കിംഗ്. പരിശോധിക്കാൻ നിങ്ങൾക്ക് അധികാരമുള്ള അടിസ്ഥാനസൗകര്യത്തിൽ തിരഞ്ഞെടുത്ത User-Agent, Client Hints ഹെഡറുകളോടുള്ള പ്രതികരണങ്ങൾ താരതമ്യം ചെയ്യാം. ഈ ഹെഡർ പ്രൊഫൈലുകൾ ക്രാളറിന്റെ തിരിച്ചറിയൽ സ്ഥിരീകരിക്കുകയോ സൈറ്റ് Google നയങ്ങൾ പാലിക്കുന്നുണ്ടോ എന്ന് നിർണ്ണയിക്കുകയോ ചെയ്യുന്നില്ല.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ (സാങ്കേതിക FAQ)

“റീഡയറക്ട് ശൃംഖല” എന്താണ്, അത് സാങ്കേതിക SEO-യെ ദോഷകരമായി ബാധിക്കുന്നത് എന്തുകൊണ്ട്?

അവസാന പേജിലെത്തുന്നതിന് മുമ്പ് ഒരു URL പല ഇടനില വിലാസങ്ങളിലൂടെ കടന്നുപോകുന്നതാണ് റീഡയറക്ട് ശൃംഖല (ഉദാഹരണത്തിന്, A → B → C → D). ഓരോ ഘട്ടത്തിനും മറ്റൊരു അഭ്യർത്ഥന ആവശ്യമായതിനാൽ താമസം കൂടുകയും ക്രാളിംഗ് കാര്യക്ഷമത കുറയുകയും ചെയ്യും. പാതകൾ കഴിയുന്നത്ര നേരിട്ടുള്ളതാക്കുക; ശുപാർശ ചെയ്യുന്ന ശൃംഖല നീളം അടുത്ത FAQ വിശദീകരിക്കുന്നു.

RFC 9110: HTTP സെമാന്റിക്സ്, റീഡയറക്ഷൻ · Google Search Central: സൈറ്റ് മാറ്റങ്ങളും റീഡയറക്ടുകളും

റീഡയറക്ടിനു ശേഷം കാനോണിക്കൽ ടാഗുകൾ എങ്ങനെ പരിശോധിക്കാം?

ഈ ചെക്കർ HTTP സ്റ്റാറ്റസ് കോഡുകളും Location ഹെഡറുകളും പിന്തുടരുന്നു; ലക്ഷ്യസ്ഥാന പേജിന്റെ HTML ഡൗൺലോഡ് ചെയ്യുകയോ പാഴ്സ് ചെയ്യുകയോ ചെയ്യുന്നില്ല, അതിനാൽ rel=canonical സ്ഥിരീകരിക്കാനാവില്ല. അന്തിമ URL തുറന്ന് അതിന്റെ കാനോണിക്കൽ ലിങ്ക് തിരഞ്ഞെടുക്കപ്പെട്ട ഇൻഡെക്സ് ചെയ്യാവുന്ന പേജിലേക്കാണെന്ന് ഉറപ്പാക്കുക. Google തിരഞ്ഞെടുത്ത കാനോണിക്കൽ വിലയിരുത്താൻ Search Console-ലെ URL Inspection ഉപയോഗിക്കാം.

Google Search Central: കാനോണിക്കലൈസേഷൻ · Google Search Central: കാനോണിക്കൽ URL വ്യക്തമാക്കുക

ഈ ഉപകരണത്തിന് JavaScript അടിസ്ഥാനമാക്കിയുള്ള റീഡയറക്ടുകൾ കണ്ടെത്താനാകുമോ?

ഇല്ല. Location ഹെഡറുള്ള HTTP 3xx പ്രതികരണങ്ങളാണ് ഈ ഉപകരണം പിന്തുടരുന്നത്. JavaScript പ്രവർത്തിപ്പിക്കുകയോ meta-refresh ടാഗുകൾക്കായി പ്രതികരണ ബോഡി പരിശോധിക്കുകയോ ചെയ്യുന്നില്ല; അവ ബ്രൗസർ പരിശോധനയിലൂടെ കാണണം.

Google Search Central: റീഡയറക്ടുകളും Google Search-ഉം

റീഡയറക്ട് ലൂപ്പ് എന്താണ്, അത് എങ്ങനെ പരിഹരിക്കാം?

URL A URL B-യിലേക്ക് പോയി URL B വീണ്ടും URL A-യിലേക്ക് മടങ്ങുന്ന അനന്തചക്രമാണ് റീഡയറക്ട് ലൂപ്പ്; ഇത് ERR_TOO_MANY_REDIRECTS എന്ന ബ്രൗസർ പിശകുണ്ടാക്കും. പരിഹരിക്കാൻ സെർവറിലെ .htaccess ഫയൽ, Nginx ക്രമീകരണം അല്ലെങ്കിൽ CMS റൂട്ടിംഗ് നിയമങ്ങൾ തിരുത്തണം.

RFC 9110: HTTP സെമാന്റിക്സ്, റീഡയറക്ഷൻ · MDN: HTTP പ്രതികരണ സ്റ്റാറ്റസ് കോഡുകൾ

Client Hints എന്താണ്, ഈ പരിശോധകൻ അത് എങ്ങനെ ഉപയോഗിക്കുന്നു?

Sec-CH-UA-Mobile, Sec-CH-UA-Platform പോലുള്ള HTTP അഭ്യർത്ഥന ഹെഡറുകളാണ് Client Hints. സെർവർ എങ്ങനെ പ്രതികരിക്കുന്നു എന്ന് താരതമ്യം ചെയ്യാൻ തിരഞ്ഞെടുത്ത പ്രൊഫൈൽ പരിശോധകന്റെ സെർവർ-സൈഡ് അഭ്യർത്ഥനയിൽ ആ ഹെഡറുകൾ ചേർക്കുന്നു. ഇത് ഹെഡർ പരിശോധന മാത്രമാണ്; പൂർണ്ണ ബ്രൗസർ അനുകരണമോ അഭ്യർത്ഥന ഒരു പ്രത്യേക ബ്രൗസറിൽ നിന്നോ ക്രാളറിൽ നിന്നോ വന്നതിന്റെ തെളിവോ അല്ല.

MDN: HTTP Client Hints

ഒരു ശൃംഖലയിൽ എത്ര 301 റീഡയറക്ടുകൾ ഉപയോഗിക്കാം?

Google രേഖകൾ പ്രകാരം Googlebot-ന് 10 റീഡയറക്ട് ഘട്ടങ്ങൾ വരെ പിന്തുടരാനാകും; സാധ്യമെങ്കിൽ നേരിട്ടുള്ള പാതയാണ് ശുപാർശ. ശൃംഖല നീക്കാനാകില്ലെങ്കിൽ അത് ചെറുതാക്കുക—മികച്ചത് മൂന്ന് ഘട്ടത്തിൽ കൂടാതെയും അഞ്ചിൽ താഴെയും. ഓരോ ഘട്ടവും ഒരു അഭ്യർത്ഥന കൂടി ചേർക്കുന്നു; മറ്റ് ക്ലയന്റുകൾക്ക് അതിലും താഴ്ന്ന പരിധികളുണ്ടാകാം. ഉദ്ദേശിച്ച മാറ്റത്തിന് അനുയോജ്യമായ സ്ഥിരം (301/308) അല്ലെങ്കിൽ താൽക്കാലിക (302/307) കോഡുകൾ തിരഞ്ഞെടുക്കുക. Google Search Central മാർഗ്ഗനിർദ്ദേശം.

RFC 9110: HTTP സെമാന്റിക്സ്, റീഡയറക്ഷൻ

ഏത് HTTP സ്റ്റാറ്റസ് കോഡുകളാണ് സ്ഥിരമോ താൽക്കാലികമോ ആയ മാറ്റം സൂചിപ്പിക്കുന്നത്?

301, 308 എന്നിവ വിഭവം സ്ഥിരമായി മാറിയെന്ന് സൂചിപ്പിക്കുന്നു; 302, 307 എന്നിവ താൽക്കാലിക റീഡയറക്ട് സൂചിപ്പിക്കുന്നു. യഥാർത്ഥ URL മടങ്ങിവരുമെന്ന് പ്രതീക്ഷിക്കുന്നുണ്ടോ എന്നതിനെ പ്രതിഫലിപ്പിക്കുന്ന സ്റ്റാറ്റസ് തിരഞ്ഞെടുക്കുകയും ലക്ഷ്യസ്ഥാനം യഥാർത്ഥ അഭ്യർത്ഥനയുമായി പ്രസക്തമാക്കുകയും ചെയ്യുക.

RFC 9110: HTTP സെമാന്റിക്സ്, റീഡയറക്ഷൻ

301 അല്ലെങ്കിൽ 302-നു പകരം 307 അല്ലെങ്കിൽ 308 എപ്പോൾ ഉപയോഗിക്കണം?

റീഡയറക്ട് ചെയ്യുമ്പോൾ 307, 308 അഭ്യർത്ഥന രീതി നിലനിർത്തുന്നു. 301, 302-ൽ ചില ക്ലയന്റുകൾ POST അഭ്യർത്ഥന GET ആക്കി മാറ്റാം. രീതി, അഭ്യർത്ഥന ബോഡി എന്നിവ നിലനിർത്തേണ്ടിടത്ത് താൽക്കാലിക മാറ്റത്തിന് 307-യും സ്ഥിരമായ മാറ്റത്തിന് 308-യും ഉപയോഗിക്കുക; നിങ്ങളുടെ സേവനം പിന്തുണയ്ക്കുന്ന ക്ലയന്റുകളിൽ പെരുമാറ്റം പരിശോധിക്കുക.

RFC 9110: HTTP സെമാന്റിക്സ്, 307, 308

301 റീഡയറക്ട് റാങ്കിംഗോ ഇൻഡെക്സിംഗോ ഉറപ്പാക്കുമോ?

ഇല്ല. ലക്ഷ്യസ്ഥാനം ഉറവിട URL-നെ മാറ്റിസ്ഥാപിക്കണമെന്ന ശക്തമായ സൂചനയാണ് സ്ഥിരമായ റീഡയറക്ട്; സ്ഥിരമായ റീഡയറക്ടിൽ PageRank നഷ്ടമാകില്ലെന്ന് Google പറയുന്നു. എന്താണ് ക്രാൾ ചെയ്യേണ്ടത്, ഇൻഡെക്സ് ചെയ്യേണ്ടത്, റാങ്ക് ചെയ്യേണ്ടത് എന്ന് സെർച്ച് എഞ്ചിനുകൾ ആകെ സൂചനകളും ലക്ഷ്യസ്ഥാന ഉള്ളടക്കവും അടിസ്ഥാനമാക്കി തീരുമാനിക്കുന്നു.

Google Search Central: റീഡയറക്ടുകളും Google Search-ഉം · Google Search Central: കാനോണിക്കലൈസേഷൻ

അന്തിമ 2xx പ്രതികരണം എന്താണ് സ്ഥിരീകരിക്കുന്നത്?

ട്രേസിലെ അവസാന HTTP അഭ്യർത്ഥനയ്ക്ക് വിജയ വിഭാഗത്തിലുള്ള പ്രതികരണം ലഭിച്ചതായി ഇത് സ്ഥിരീകരിക്കുന്നു. ഉള്ളടക്കം പ്രയോജനകരമോ എല്ലാ സന്ദർശകർക്കും ലഭ്യമോ ഇൻഡെക്സ് ചെയ്യാവുന്നതോ കാനോണിക്കൽ ശരിയായി ക്രമീകരിച്ചതോ റാങ്ക് ചെയ്യാൻ അർഹമോ ആണെന്ന് ഇത് തെളിയിക്കുന്നില്ല.

RFC 9110: HTTP സെമാന്റിക്സ്, വിജയകരമായ പ്രതികരണങ്ങൾ · MDN: HTTP പ്രതികരണ സ്റ്റാറ്റസ് കോഡുകൾ

എന്റെ ബ്രൗസറിൽ പേജ് തുറക്കുമ്പോഴും ചെക്കറിന് 403 അല്ലെങ്കിൽ 429 ലഭിക്കുന്നത് എന്തുകൊണ്ട്?

ചെക്കർ സെർവർ-സൈഡ് അഭ്യർത്ഥന അയയ്ക്കുന്നു; നെറ്റ്വർക്ക് സ്ഥലം, കുക്കികൾ, ഓതന്റിക്കേഷൻ, ഹെഡറുകൾ എന്നിവയിൽ അത് നിങ്ങളുടെ ബ്രൗസറിൽ നിന്നുള്ള അഭ്യർത്ഥനയിൽ നിന്ന് വ്യത്യസ്തമായേക്കാം. ഫയർവാൾ, CDN, നിരക്ക് പരിധി അല്ലെങ്കിൽ ബോട്ട് നിയമം അത് തടയുകയോ വേഗം കുറയ്ക്കുകയോ ചെയ്യാം. സെർവർ ലോഗുകളും പ്രവേശന നിയമങ്ങളും താരതമ്യം ചെയ്യുക; ഒരു പരിശോധനയിൽ 403/429 ലഭിച്ചതുകൊണ്ട് എല്ലാ സന്ദർശകരെയും തടയുന്നു എന്ന് കരുതരുത്.

RFC 9110: 403 Forbidden · RFC 6585: 429 Too Many Requests

Googlebot, സെർച്ച് ക്രാളർ പ്രീസെറ്റുകൾ സ്ഥിരീകരിച്ച ക്രാളറുകളാണോ?

അല്ല. ഒരു പ്രീസെറ്റ് User-Agent ഹെഡർ സ്ട്രിങ്ങ് മാത്രമാണ് മാറ്റുന്നത്. അഭ്യർത്ഥന Google-ൽ നിന്നോ മറ്റൊരു ക്രാളർ നെറ്റ്വർക്കിൽ നിന്നോ വരുന്നതല്ല; അഭ്യർത്ഥിച്ചയാൾ യഥാർത്ഥ ക്രാളറാണെന്ന് ഇതിലൂടെ തെളിയിക്കാനാവില്ല. സേവനദാതാവ് പ്രസിദ്ധീകരിച്ച IP അല്ലെങ്കിൽ DNS പരിശോധനാ നടപടിക്രമം ഉപയോഗിച്ച് ക്രാളറിന്റെ തിരിച്ചറിയൽ ഉറപ്പാക്കുക.

Google Search Central: Googlebot-ഉം മറ്റ് Google ക്രാളറുകളും സ്ഥിരീകരിക്കുക

വ്യത്യസ്ത User-Agent പ്രൊഫൈലുകൾ വ്യത്യസ്ത റീഡയറക്ട് ശൃംഖലകൾ സൃഷ്ടിക്കാൻ ഇടയുള്ളത് എന്തുകൊണ്ട്?

അഭ്യർത്ഥന ഹെഡറുകൾ, ഉപകരണ സൂചനകൾ, ഭൂമിശാസ്ത്രം, ഓതന്റിക്കേഷൻ, സെഷൻ നില എന്നിവയെ ആശ്രയിച്ച് സെർവറുകൾ, CDN-കൾ, ആപ്ലിക്കേഷൻ നിയമങ്ങൾ വ്യത്യസ്ത ലക്ഷ്യസ്ഥാനങ്ങളോ സ്റ്റാറ്റസ് കോഡുകളോ തിരഞ്ഞെടുക്കാം. ട്രേസുകൾ ഡയഗ്നോസ്റ്റിക് സാമ്പിളുകളായി താരതമ്യം ചെയ്യുക; എല്ലാ ഉപയോക്താക്കളുടെയും ക്രാളറുകളുടെയും അഭ്യർത്ഥനകൾക്ക് ഫലം ഒരുപോലെയാകണമെന്നില്ല.

RFC 9110: Vary ഹെഡറും സംവദിച്ച് നിർണ്ണയിക്കുന്ന പ്രതികരണങ്ങളും

URL റീഡയറക്ട് ചെയ്യുമ്പോൾ ക്വറി പാരാമീറ്ററുകൾ നിലനിർത്തുമോ?

റീഡയറക്ട് പ്രതികരണത്തിലെ Location ഹെഡറാണ് അടുത്ത URL നിർണ്ണയിക്കുന്നത്. സെർവർ ക്വറി പാരാമീറ്ററുകൾ നിലനിർത്തുകയോ നീക്കുകയോ പുനരെഴുതുകയോ ചെയ്യാം. ലഭിച്ച Location മൂല്യമാണ് ഈ ചെക്കർ പിന്തുടരുന്നത്; സെർവർ യഥാർത്ഥത്തിൽ നൽകിയതെന്തെന്ന് കാണാൻ പ്രദർശിപ്പിച്ച URL-കൾ താരതമ്യം ചെയ്യുക.

RFC 9110: Location പ്രതികരണ ഹെഡർ

HTTPS-ൽ നിന്ന് HTTP-യിലേക്കുള്ള തരംതാഴ്ത്തൽ മുന്നറിയിപ്പ് എന്താണ് സൂചിപ്പിക്കുന്നത്?

HTTPS URL-ൽ നിന്ന് HTTP ഉപയോഗിക്കുന്ന Location-ലേക്ക് റീഡയറക്ട് നടന്നതായി ട്രേസ് കണ്ടെത്തി എന്നതാണ് അർത്ഥം. ആ മാറ്റം അടുത്ത അഭ്യർത്ഥനയുടെ ട്രാൻസ്പോർട്ട് സംരക്ഷണം കുറയ്ക്കുന്നു. ഇത് ഉദ്ദേശിച്ചതാണോ എന്ന് പരിശോധിക്കുക; സുരക്ഷിതമായ സമാന ലക്ഷ്യസ്ഥാനം ഉണ്ടെങ്കിൽ റീഡയറക്ട് HTTPS-ലേക്ക് പുതുക്കുക.

RFC 9110: URI സ്കീമും റീഡയറക്ഷൻ സെമാന്റിക്സും · Google Search Central: HTTPS-ഉം നിങ്ങളുടെ വെബ്സൈറ്റും

ഒരു പരിശോധനയിൽ ഈ ചെക്കർ എത്ര റീഡയറക്ടുകൾ പിന്തുടരും?

നിലവിലെ ചെക്കർ അഞ്ച് റീഡയറക്ടുകൾ വരെ പിന്തുടരും. അഞ്ചാം ഘട്ടത്തിനു ശേഷമുള്ള പ്രതികരണം മറ്റൊരു URL-ലേക്ക് ചൂണ്ടിയാൽ, അത് എടുത്തുനോക്കാതെ അടുത്ത വിലാസം മാത്രം പരിശോധന കാണിച്ചേക്കാം. ആ വിലാസം പുതിയ പരിശോധനയായി തുറക്കുകയോ അന്തിമ പ്രതികരണം പരിശോധിക്കാൻ ശൃംഖല ചുരുക്കുകയോ ചെയ്യുക.

Client Hints തിരഞ്ഞെടുക്കൽ പരിശോധനയെ എങ്ങനെ ബാധിക്കുന്നു?

തിരഞ്ഞെടുത്ത User-Agent സ്ട്രിങ്ങിനൊപ്പം, മൊബൈൽ ഫ്ലാഗോ പ്ലാറ്റ്ഫോം മൂല്യമോ പോലുള്ള തിരഞ്ഞെടുത്ത Sec-CH-* അഭ്യർത്ഥന ഹെഡറുകൾ ചേർക്കുന്നു. ഇവ ക്രമീകരിക്കാവുന്ന ഹെഡർ സാമ്പിളുകളാണ്; ബ്രൗസറിന്റെ പൂർണ്ണ നെറ്റ്വർക്ക് പെരുമാറ്റം പുനരാവിഷ്കരിക്കുന്നില്ല, സെർവർ അവ അവഗണിച്ചേക്കാം.

MDN: HTTP Client Hints

നീക്കം ചെയ്ത URL-ന് പകരം 404 അല്ലെങ്കിൽ 410 എപ്പോൾ നൽകണം?

നീക്കം ചെയ്ത പേജിന് യഥാർത്ഥത്തിൽ സമാനമായ പകരം പേജ് ഇല്ലെങ്കിൽ 404 (Not Found) അല്ലെങ്കിൽ 410 (Gone) നൽകുക. പ്രസക്തമായ പേജ് അതിനെ മാറ്റിസ്ഥാപിക്കുമ്പോൾ മാത്രം റീഡയറക്ട് ചെയ്യുക; ബന്ധമില്ലാത്ത URL-കൾ ഹോം പേജിലേക്ക് അയയ്ക്കുന്നത് സന്ദർശകരെ തെറ്റിദ്ധരിപ്പിക്കാം, സെർച്ച് എഞ്ചിനുകൾ soft 404 ആയി കണക്കാക്കാനും ഇടയുണ്ട്.

RFC 9110: 404 Not Found · RFC 9110: 410 Gone · Google Search Central: ക്രാളിംഗ് പിശകുകൾ പരിഹരിക്കുക

URL മാറ്റിയശേഷം റീഡയറക്ട് എത്രകാലം നിലനിർത്തണം?

റീഡയറക്ട് കഴിയുന്നത്ര കാലം നിലനിർത്തുക. സൈറ്റ് മാറ്റത്തിനു ശേഷം സെർച്ച് എഞ്ചിനുകൾക്ക് മാറ്റം പ്രോസസ്സ് ചെയ്യാൻ കുറഞ്ഞത് ഒരു വർഷത്തേക്കെങ്കിലും റീഡയറക്ടുകൾ നിലനിർത്തണമെന്ന് Google ശുപാർശ ചെയ്യുന്നു; അതിനുശേഷവും സന്ദർശകർ പഴയ ബുക്ക്മാർക്കുകളും ലിങ്കുകളും ഉപയോഗിച്ചേക്കാം.

Google Search Central: സൈറ്റ് മാറ്റങ്ങളും റീഡയറക്ടുകളും

URL മാറ്റിയശേഷം റീഡയറക്ടിനു പുറമെ എന്താണ് പുതുക്കേണ്ടത്?

പുതിയ URL-ലേക്ക് ചൂണ്ടുന്നവിധം ആന്തരിക ലിങ്കുകൾ, ലക്ഷ്യസ്ഥാന പേജിന്റെ കാനോണിക്കൽ URL, ഉപയോഗിക്കുന്നിടത്തെ hreflang കുറിപ്പുകൾ, XML സൈറ്റ്മാപ്പ് എന്നിവ പുതുക്കുക. പകരം പേജ് പ്രസക്തമാണെന്ന് ഉറപ്പാക്കി, റീഡയറക്ട് നേരിട്ടും സ്ഥിരമായും പരിഹരിക്കപ്പെടുന്നുണ്ടോ പരിശോധിക്കുക.

Google Search Central: സൈറ്റ് മാറ്റങ്ങളും റീഡയറക്ടുകളും