Edistynyt uudelleenohjausten tarkistin ja tekninen SEO-analysoija

Seuraa HTTP-uudelleenohjausketjuja palvelinpuolisen pyynnön avulla. Vertaile valittuja User-Agent- ja Client Hints -pyyntöotsakkeita, tarkista enintään viiden uudelleenohjauksen tila ja mitattu vasteaika sekä tunnista siirtymät HTTPS:stä HTTP:hen. Tarkistin ei suorita kohteen JavaScriptiä eikä tarkastele sivun HTML-koodia.

🌐

Valitut User-Agent- ja Client Hints -asetukset ovat pyyntöotsakkeiden testiprofiileja; ne eivät todista, että kyseessä olisi oikea selain tai indeksointirobotti.

Tarkistuksen tulokset ja visuaalinen kulku

⚠️ Tietoturvavaroitus: havaittiin sekasisältöä. Yhteys siirtyi ketjun aikana salaamattomaan HTTP:hen.

Kattava käyttöopas ja käytännön sovellukset

RedirectChecker.Site ei ole pelkkä HTTP-otsakkeiden lukija, vaan edistynyt verkkodiagnostiikkatyökalu SEO-ammattilaisille, järjestelmänvalvojille ja verkkokehittäjille. Ominaisuuksien asianmukainen käyttö auttaa selvittämään monimutkaisia reititysongelmia, jotka vaikuttavat merkittävästi hakutuloksiin ja käyttökokemukseen.

1. Tarkistimen käyttö: vaiheittaiset ohjeet

Anna täydellinen julkinen URL-osoite protokollineen (esimerkiksi https://example.com/old-page). Valitse esimerkki User-Agent ja tarvittaessa Client Hints -otsakkeet -otsakeprofiili. Tarkistin lähettää palvelinpuolisen pyynnön valituilla otsakkeilla; se ei jäljittele koko selainta, evästeitä, JavaScriptiä tai indeksointirobotin verkkoyhteyttä.

2. Tulosten ja visuaalisen kulun esimerkkien tulkinta

Napsauta Seuraa URL-osoitetta nähdäksesi jokaisen uudelleenohjausketjun HTTP-vastauksen, tilakoodin, mitatun pyyntöajan sekä seuraavan Location-URL-osoitteen, jos sellainen on. Yhdellä tarkistuksella seurataan enintään viittä uudelleenohjausta; jos ketju jatkuu, seuraavan URL-osoitteen vastaus ei sisälly kyseiseen tarkistukseen.

3. Käytännön tapaustutkimus: SSL-suojauksen heikkenemisen havaitseminen

Uudelleenohjaus voi vaihtaa URL-osoitteen HTTPS:stä HTTP:hen. Tarkistin ilmoittaa muutoksesta, kun se havaitsee HTTPS-osoitteen vastauksen osoittavan HTTP Location -osoitteeseen. Tarkista kohde ja määritä tarkoitettu HTTPS-reitti ennen kuin luotat tulokseen.

Tekninen perusta: HTTP-tilakoodit ja verkkotekniikka

HTTP-tilakoodit kuvaavat pyynnön tulosta, kun taas 3xx-vastaukset ohjaavat asiakkaan toiseen URL-osoitteeseen. Pysyvät uudelleenohjaukset voivat auttaa hakukoneita yhdistämään URL-osoitteita, mutta ne eivät takaa tiettyä sijoitusta tai indeksointitulosta. Käytä aiottua pysyvyyttä vastaavaa tilakoodia ja tarkista koko ketju sekä lopullinen vastaus.

301-, 302-, 307- ja 308-koodien erot

  • 301 – siirretty pysyvästi: Käytä, kun resurssi on siirretty pysyvästi. Hakukoneet pitävät pysyvää uudelleenohjausta vahvana kohdetta tukevana signaalina, mutta mikään uudelleenohjaus ei takaa tiettyä sijoitusta tai indeksointitulosta.
  • 302 – löytyi (tilapäinen): Ilmoittaa asiakkaalle tilapäisesti toisesta URL-osoitteesta ja antaa ymmärtää, että alkuperäinen URL palaa käyttöön. Hakukoneet eivät yleensä siirrä pysyviä linkkiarvoja 302-vastauksen kautta.
  • 307 – tilapäinen uudelleenohjaus: Tämä on 302-koodin nykyaikainen HTTP/1.1-vastine. Tärkeää: 307 takaa, ettei HTTP-menetelmää (GET tai POST) muuteta uudelleenohjausta seurattaessa.
  • 308 – pysyvä uudelleenohjaus: Tämä on 307-koodin pysyvä versio. SEO:n kannalta se toimii kuten 301, mutta kieltää selainta muuttamasta POST-pyyntöä GET-pyynnöksi.

HTTP-vastauksen tilakoodien selainyhteensopivuus

HTTP-tilakoodit ovat selaimen verkkopinon käsittelemiä protokollasignaaleja, eivät erillisiä selainominaisuuksia. Nykyaikaiset Chrome, Edge, Firefox, Safari, Opera, Android WebView ja iPhone WebView käsittelevät standarditilaluokkia; virheen näyttötapa voi vaihdella selaimen ja välissä olevan proxyn mukaan.

HTTP-vastauksen luokkaChrome / EdgeFirefoxSafariOperaAndroid / iPhone WebViewYhteensopivuuden käytännön huomio
1xx – tiedoksiTuettuTuettuTuettuTuettuVerkkokerroksen tukema100 ja 101 ovat vakiintuneita. 102 on erikoistapaus ja vanhentunut; 103 Early Hints -toiminta voi vaihdella version, palvelimen ja välittäjän mukaan.
2xx – onnistuminenTuettuTuettuTuettuTuettuTuettuProtokollan merkitys on yhteinen; myös sisällön säännöt pätevät, esimerkiksi 204/205-vastauksissa ei ole sisältöä.
3xx – uudelleenohjausTuettuTuettuTuettuTuettuTuettuAsiakkaat seuraavat Location-otsaketta menetelmä-, välimuisti-, tietoturva- ja navigointisääntöjen mukaisesti. 307/308 säilyttävät menetelmän; 301/302 voivat muuttaa POST-pyynnön GET-pyynnöksi.
4xx – asiakkaan virheTuettuTuettuTuettuTuettuTuettuVastausluokka tunnistetaan, mutta palvelimen virhesisällön näyttö voi erota selaimen omasta virhenäkymästä.
5xx – palvelinvirheTuettuTuettuTuettuTuettuTuettuProxyjen virhesivut, uudelleenyrityskäytös ja diagnostiikan esitystapa voivat erota, vaikka tilakoodi on sama.
Tunnistamaton koodi tunnetussa luokassaLuokkakohtainen käsittelyLuokkakohtainen käsittelyLuokkakohtainen käsittelyLuokkakohtainen käsittelyLuokkakohtainen käsittelyAsiakkaat voivat päätellä yleisen luokan ensimmäisestä numerosta. Mukautettu koodi ei saa yleispätevää merkitystä tämän varakäsittelyn perusteella.

Taulukko kuvaa protokollatason yhteensopivuutta, ei samanlaista esitystapaa eikä takaa, että jokainen selainversio näyttää välivastaukset samalla tavalla.

Cloaking ja dynaamisen renderöinnin rikkomukset

Cloaking tarkoittaa, että hakukoneille ja ihmisille näytetään olennaisesti erilaista sisältöä tai eri kohteita. Voit verrata valittujen User-Agent- ja Client Hints -otsakkeiden vastauksia infrastruktuurissa, jota sinulla on lupa testata. Nämä otsakeprofiilit eivät varmista indeksointirobotin henkilöllisyyttä eivätkä ratkaise, noudattaako sivusto Googlen käytäntöjä.

Usein kysytyt kysymykset (tekniset)

Mikä uudelleenohjausketju tarkalleen on ja miksi se haittaa teknistä SEO:ta?

Uudelleenohjausketjussa yksi URL kulkee useiden väliosoitteiden kautta ennen lopullista sivua (esimerkiksi A → B → C → D). Jokainen vaihe vaatii uuden pyynnön, lisää viivettä ja tekee indeksoinnista tehottomampaa. Pidä reitit mahdollisimman suorina; seuraava kysymys käsittelee suositeltuja ketjun pituuksia.

RFC 9110: HTTP-semanttiikka, uudelleenohjaus · Google Search Central: sivuston siirrot ja uudelleenohjaukset

Miten voin tarkistaa canonical-tunnisteet uudelleenohjauksen jälkeen?

Tämä tarkistin seuraa HTTP-tilakoodeja ja Location-otsakkeita; se ei lataa tai jäsennä kohdesivun HTML-koodia eikä siksi voi tarkistaa rel=canonical-tunnistetta. Avaa lopullinen URL ja varmista, että sen canonical-linkki osoittaa ensisijaiseen indeksoitavaan sivuun. Search Consolen URL-tarkastuksella voit tarkistaa, minkä canonical-osoitteen Google valitsi.

Google Search Central: canonicalisointi · Google Search Central: määritä canonical-URL

Tunnistaako tämä työkalu JavaScript-pohjaiset uudelleenohjaukset?

Ei. Työkalu seuraa HTTP 3xx -vastauksia, joissa on Location-otsake. Se ei suorita JavaScriptiä eikä tarkasta vastauksen sisältöä meta refresh -tunnisteiden varalta; tähän tarvitaan selaimella tehtävä tarkistus.

Google Search Central: uudelleenohjaukset ja Google-haku

Mikä uudelleenohjaussilmukka on ja miten korjaan sen?

Uudelleenohjaussilmukka on loputon kierto, jossa URL A osoittaa URL-osoitteeseen B ja B takaisin A:han, jolloin selain näyttää ERR_TOO_MANY_REDIRECTS-virheen. Korjaus edellyttää palvelimen .htaccess-tiedoston, Nginx-määritysten tai sisällönhallintajärjestelmän reitityssääntöjen muuttamista.

RFC 9110: HTTP-semanttiikka, uudelleenohjaus · MDN: HTTP-vastauksen tilakoodit

Mitä Client Hints -tiedot ovat ja miten tarkistin käyttää niitä?

Client Hints ovat HTTP-pyyntöotsakkeita, kuten Sec-CH-UA-Mobile ja Sec-CH-UA-Platform. Valittu profiili lisää valitut otsakkeet tarkistimen palvelinpuoliseen pyyntöön, jotta voit vertailla palvelimen vastauksia. Tämä on otsaketesti, ei täydellinen selainjäljitelmä tai todiste siitä, että pyyntö tuli tietystä selaimesta tai indeksointirobotista.

MDN: HTTP Client Hints

Kuinka monta 301-uudelleenohjausta ketjussa voi olla?

Googlen dokumentaation mukaan Googlebot voi seurata enintään kymmentä uudelleenohjausvaihetta, mutta suora reitti on suositeltava aina kun mahdollista. Jos ketjua ei voi poistaa, pidä se lyhyenä — mieluiten enintään kolmessa vaiheessa ja alle viidessä. Jokainen vaihe lisää pyynnön, ja muiden asiakkaiden rajat voivat olla tiukempia. Valitse pysyvä (301/308) tai tilapäinen (302/307) koodi aiotun muutoksen mukaan. Google Search Centralin ohjeet.

RFC 9110: HTTP-semanttiikka, uudelleenohjaus

Mitkä HTTP-tilakoodit ilmaisevat pysyvän tai tilapäisen siirron?

301 ja 308 ilmaisevat resurssin pysyvän siirron; 302 ja 307 tilapäisen uudelleenohjauksen. Valitse koodi sen mukaan, odotetaanko alkuperäisen URL-osoitteen palaavan, ja pidä kohde alkuperäiseen pyyntöön liittyvänä.

RFC 9110: HTTP-semanttiikka, uudelleenohjaus

Milloin pitäisi käyttää 307- tai 308-koodia 301- tai 302-koodin sijasta?

307 ja 308 säilyttävät pyyntömenetelmän uudelleenohjauksessa. Jotkin asiakkaat voivat muuttaa POST-pyynnön GET-pyynnöksi 301- ja 302-vastauksissa. Käytä 307-koodia tilapäiseen tai 308-koodia pysyvään siirtoon, kun menetelmän ja pyynnön sisällön säilyttäminen on tärkeää; varmista toiminta palvelusi tukemilla asiakkailla.

RFC 9110: HTTP-semanttiikka, 307 ja 308

Takaako 301-uudelleenohjaus paremman sijoituksen tai indeksoinnin?

Ei. Pysyvä uudelleenohjaus on vahva signaali siitä, että kohteen pitäisi korvata lähde-URL, ja Googlen mukaan pysyvät uudelleenohjaukset eivät menetä PageRankia. Hakukoneet päättävät silti kaikkien signaalien ja kohdesisällön perusteella, mitä ne indeksoivat ja miten ne sijoittuvat.

Google Search Central: uudelleenohjaukset ja Google-haku · Google Search Central: canonicalisointi

Mitä lopullinen 2xx-vastaus vahvistaa?

Se vahvistaa, että jäljen viimeinen HTTP-pyyntö sai onnistuneen luokan vastauksen. Se ei todista, että sisältö on hyödyllistä, kaikkien kävijöiden saavutettavissa, indeksoitavaa, oikein canonicalisoitua tai sijoituskelpoista.

RFC 9110: HTTP-semanttiikka, onnistuneet vastaukset · MDN: HTTP-vastauksen tilakoodit

Miksi tarkistin voi saada 403- tai 429-vastauksen, vaikka sivu avautuu selaimessani?

Tarkistin lähettää palvelinpuolisen pyynnön, joka voi erota selaimestasi verkkosijainnin, evästeiden, todennuksen ja otsakkeiden osalta. Palomuuri, CDN, pyyntörajoitus tai bottisääntö voi estää tai rajoittaa sen. Vertaa palvelimen lokeja ja käyttöoikeussääntöjä; yhden testin 403- tai 429-vastaus ei todista, että kaikki kävijät estetään.

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

Ovatko Googlebot- ja hakurobottiprofiilit vahvistettuja indeksointirobotteja?

Eivät. Profiili muuttaa vain User-Agent-otsakkeen tekstiä. Pyyntö ei tule Googlelta tai muulta indeksointirobotin verkolta eikä todista pyynnön lähettäjän aitoutta. Varmista robotin henkilöllisyys palveluntarjoajan julkaisemalla IP- tai DNS-tarkistusmenetelmällä.

Google Search Central: Googlebotin ja muiden Google-robottien vahvistaminen

Miksi eri User-Agent-profiilit voivat tuottaa erilaisia uudelleenohjausketjuja?

Palvelimet, CDN:t ja sovellussäännöt voivat valita eri kohteita tai tilakoodeja pyyntöotsakkeiden, laitesignaalien, maantieteellisen sijainnin, todennuksen tai istunnon perusteella. Vertaa jälkiä diagnostisina esimerkkeinä; ne eivät välttämättä vastaa kaikkien todellisten käyttäjien tai robottien pyyntöjä.

RFC 9110: Vary-otsake ja neuvotellut vastaukset

Säilyvätkö kyselyparametrit URL-osoitteen uudelleenohjauksessa?

Uudelleenohjausvastauksen Location-otsake määrittää seuraavan URL-osoitteen. Palvelin voi säilyttää, poistaa tai muuttaa kyselyparametreja. Tämä tarkistin seuraa saamaansa Location-arvoa, joten vertaa näytettyjä URL-osoitteita nähdäksesi palvelimen todellisen vastauksen.

RFC 9110: Location-vastausotsake

Mitä HTTPS:stä HTTP:hen siirtymisestä varoittava ilmoitus tarkoittaa?

Jälki havaitsi uudelleenohjauksen HTTPS-URL-osoitteesta HTTP:tä käyttävään Location-osoitteeseen. Muutos heikentää seuraavan pyynnön siirtosuojausta. Tarkista, onko muutos tarkoituksellinen, ja päivitä kohde HTTPS-osoitteeseen, jos suojattu vastine on olemassa.

RFC 9110: URI-skeema ja uudelleenohjauksen semantiikka · Google Search Central: HTTPS ja verkkosivustosi

Kuinka monta uudelleenohjausta tämä tarkistin seuraa yhdellä suorituksella?

Nykyinen tarkistin seuraa enintään viittä uudelleenohjausta. Jos viidennen vaiheen vastaus osoittaa uuteen URL-osoitteeseen, suoritus voi näyttää osoitteen hakematta sitä. Tarkista osoite uutena kohteena tai lyhennä ketjua nähdäksesi lopullisen vastauksen.

Miten Client Hints -valitsin vaikuttaa tarkistukseen?

Se lisää valitut Sec-CH-* -pyyntöotsakkeet, kuten mobiililipun tai käyttöjärjestelmäarvon, valitun User-Agent-merkkijonon rinnalle. Nämä ovat määritettäviä otsake-esimerkkejä; ne eivät jäljittele selaimen koko verkkokäyttäytymistä, ja palvelin voi sivuuttaa ne.

MDN: HTTP Client Hints

Milloin poistetulle URL-osoitteelle kannattaa palauttaa 404- tai 410-tila uudelleenohjauksen sijaan?

Jos poistetulle sivulle ei ole aidosti vastaavaa korvaavaa sivua, palauta 404 (Not Found) tai 410 (Gone). Tee uudelleenohjaus vain, kun asiaankuuluva sivu korvaa vanhan. Epäolennaisten URL-osoitteiden ohjaaminen etusivulle voi johtaa kävijöitä harhaan, ja hakukoneet voivat tulkita sen pehmeäksi 404-virheeksi.

RFC 9110: 404 Not Found · RFC 9110: 410 Gone · Google Search Central: Indeksointivirheiden vianmääritys

Kuinka kauan URL-osoitteen siirtämisen jälkeen uudelleenohjaus kannattaa säilyttää?

Säilytä uudelleenohjaus mahdollisimman pitkään. Google suosittelee pitämään uudelleenohjauksen käytössä vähintään vuoden sivuston siirron jälkeen, jotta hakukoneet ehtivät käsitellä muutoksen. Kävijät voivat käyttää vanhoja kirjanmerkkejä ja linkkejä tätäkin pidempään.

Google Search Central: sivuston siirrot ja uudelleenohjaukset

Mitä muuta uudelleenohjauksen lisäksi pitäisi päivittää URL-osoitteen siirron jälkeen?

Päivitä sisäiset linkit, kohdesivun canonical-URL, käytössä olevat hreflang-merkinnät sekä XML-sivukartta osoittamaan uuteen URL-osoitteeseen. Varmista, että korvaava sivu on aiheeltaan sopiva ja että uudelleenohjaus johtaa suoraan ja yhdenmukaisesti oikeaan kohteeseen.

Google Search Central: sivuston siirrot ja uudelleenohjaukset