Tagasuri ng pag-redirect ng URL

Ang Tagasuri ng pag-redirect ng URL ay isang libreng tool na tumutukoy sa mga 301 at 302 redirect ng isang partikular na URL at sinusundan ang redirect chain nang hanggang 10 hakbang.

Ano ang URL redirect?

Ang URL redirect ay isang HTTP response na nag-uutos sa browser, crawler ng search engine, o ibang client na humiling ng ibang address. Karaniwan itong may 3xx status code at field na Location. URI reference ang value ng field na ito at maaari itong maging relative.

Ang 301 status code ay nangangahulugang permanenteng inilipat ang resource. Madalas itong gamitin kapag binago ang address ng isang page, lumipat mula HTTP patungong HTTPS, o pinagsama ang mga duplicate na URL. Ang 302 status code naman ay nangangahulugang natagpuan ang resource sa ibang lokasyon, ngunit karaniwang itinuturing na pansamantala ang paglipat.

May iba pang redirect code na tinutukoy ang HTTP, kabilang ang 303, 307, at 308. Maaaring makaapekto ang pagkakaiba ng mga ito sa paraan ng pag-ulit ng mga client sa mga request, lalo na sa mga method gaya ng POST. Para sa karaniwang pag-redirect ng web page, madalas pa ring gamitin ang 301 at 302, at ang mga code na ito ang nilalayong tukuyin ng tagasuri.

Paano tingnan ang redirect ng isang URL?

Ang field na Status code ay tumatanggap ng HTTP status code, gaya ng 301 o 302. Gumagana ang tagasuri sa server at sumusuri ng hanggang 10 hakbang ng pag-redirect.

Ipinapadala ang input sa server sa pamamagitan ng HTTPS at hindi ito iniimbak.

Anong mga redirect ang natutukoy ng tagasuri?

Natutukoy ng tagasuri ang mga 301 at 302 redirect. Ang 301 ay permanenteng redirect, samantalang ang 302 ay pansamantalang redirect.

Ang sunod-sunod na paglipat na salit-salitan sa dalawang address ay tinatawag na redirect loop. Ang mahabang serye ng mga pagbabago sa pagitan ng HTTP, HTTPS, www, non-www, at mga variant na may trailing slash ay redirect chain. Hihinto ang tool na ito pagdating sa 10 hakbang, kaya hindi nito matitiyak ang huling destinasyon ng mas mahabang chain.

Paglutas sa mga karaniwang problema sa redirect

Kapaki-pakinabang ang pagsusuri ng redirect kapag natatabunan ng huling address sa browser ang mga naunang response. Makakatulong itong matukoy kung ang problema ay nasa configuration ng HTTP o sa DNS, application, o caching.

• Nagbubukas pa rin sa lumang address ang isang page na inilipat. Direktang suriin ang lumang URL. Dapat tumuro ang 301 sa nilalayong kapalit, hindi sa isang pangkalahatang home page o sa isa pang lumang address.
• Paulit-ulit na nagpapalitan ang HTTP at HTTPS. Subukan ang parehong bersyon. Maaaring ibalik ng magkakasalungat na panuntunan sa web server, content delivery network, o application ang HTTPS sa HTTP, habang agad naman itong binabaligtad ng ibang layer.
• Hindi napupunta sa inaasahang landing page ang link sa email. Suriin ang buong URL na kinopya mula sa mensahe, kasama ang query string nito. Madalas magdagdag ang mga tracking service ng isa o higit pang redirect bago ang huling page, at maaaring maputol ang chain kapag sira ang isang intermediate na destinasyon.

Kapag naglilipat ng domain, subukan ang mga karaniwang path ng page sa halip na home page lamang ang suriin. Hindi sapat ang tamang redirect ng home page upang patunayang may katumbas ding mga panuntunan sa destinasyon ang mga product page, artikulo, at na-upload na file.

Mahalaga rin ang mga bantas at espasyo. Hindi valid sa URL ang mga raw space at karaniwang kailangang i-percent-encode, gaya ng %20. Ang fragment na nagsisimula sa # ay pinoproseso ng browser at hindi ipinapadala sa HTTP request. Kaya, kung fragment lang ang babaguhin, hindi nito pipiliin ang ibang server-side redirect. Maaaring ilarawan ang mga internationalised domain name gamit ang ASCII Punycode form ng mga ito, samantalang ang mga non-ASCII na character sa path ay kino-convert sa bytes, karaniwan gamit ang UTF-8, at ang kaukulang bytes ay pine-percent-encode habang ipinapadala.

Bakit mukhang mali pa rin ang isang tamang redirect?

Maaaring magmukhang mali ang isang tamang redirect dahil posibleng gumagamit ng naka-cache na impormasyon ang mga browser, DNS resolver, proxy server, at content delivery network. Malaki ang posibilidad na manatiling nakikita sa browser cache ang mga permanenteng redirect kahit nabago na ang panuntunan sa server.

Hindi ginagamit ng server-side na tagasuri ang lokal na history ng mga redirect sa iyong browser. Gayunman, maaari pa ring magbalik ng naka-cache na response ang target na website o ang CDN nito.

May hiwalay na pagkaantala rin ang mga pagbabago sa DNS. Maaaring panatilihin ng mga recursive resolver ang dating IP address hanggang sa mag-expire ang time to live ng record. Sa panahong iyon, maaaring makarating sa magkakaibang server ang iba't ibang network at makatanggap ng magkakaibang panuntunan sa redirect. Ang terminong "DNS propagation" ay tumutukoy sa hindi sabay-sabay na pag-expire ng mga cache na ito, hindi sa iisang pandaigdigang update event.

Kung kamakailan lang inilipat ang domain, paghambingin ang DNS record, configuration ng CDN, at mga panuntunan ng origin server. Maaaring magbigay ang Tagasuri ng cache ng Google ng konteksto tungkol sa mas lumang na-index o naka-cache na page. Makakatulong naman ang Tagasuri ng pagho-host ng website na tukuyin kung saan kasalukuyang naka-host ang domain. Hindi pamalit sa pagsusuri ng HTTP redirect ang alinman sa mga ito.

Mga madalas itanong

Maaari ko bang baguhin ang 301 redirect sa ibang pagkakataon?

Oo, maaaring baguhin ang configuration ng server, pero posibleng patuloy na gumamit ang mga client ng naka-cache na 301 response sa loob ng ilang panahon. Subukan ito sa bagong browser profile at i-clear ang kaugnay na mga CDN cache kung kontrolado mo ang mga iyon. Iwasang gumamit ng 301 sa mga unang pagsubok kung malamang na magbago pa ang destinasyon.

Naipapasa ba ng redirect ang URL query string sa destinasyon?

Oo, pero kung papanatilihin lamang ito ng panuntunan sa redirect at ng nabuong value ng Location. Awtomatikong kinokopya ng ilang system ang orihinal na query string, habang pinapalitan o inaalis naman ito ng iba. Suriin ang isang makatotohanang URL na may mga ligtas na test parameter sa halip na ipagpalagay na pare-pareho ang kilos ng lahat ng variant.

Paano pinoproseso ang input ko?

Sa server ginagawa ang proseso. Ipinapadala ang input sa server sa pamamagitan ng HTTPS at hindi ito iniimbak.

Sinusuri ba nito ang mga JavaScript o meta refresh redirect?

Tinutukoy ng tagasuri ang mga 301 at 302 HTTP redirect at sumusuri ito ng hanggang 10 redirect.

Maaari ko bang suriin ang mga redirect gamit ang command line?

Oo. Maaaring ipakita ng command na curl ang mga response header, at maaaring hilingin ng opsyon nitong sumusunod sa mga redirect ang mga susunod na lokasyon. Kapaki-pakinabang ito kung kailangan mong ulitin ang parehong pagsusuri mula sa isang partikular na computer o network, lalo na pagkatapos baguhin ang mga panuntunan sa DNS o firewall.