Vaihdoit 301-uudelleenohjauksen, mutta selain lähettää kävijät itsepintaisesti vanhaan osoitteeseen? Tuttu päänvaiva kaikille, jotka ovat tehneet sivustomuuttoja tai muokanneet linkkirakennetta.

Ongelma ei ole palvelimessa eikä WordPressissä. Selain muistaa pysyvän uudelleenohjauksen pysyvästi eikä kysy palvelimelta uudelleen; näin HTTP-määrittely toimii. Kunnes välimuisti vanhenee tai käyttäjä tyhjentää sen manuaalisesti, vanha sääntö pysyy voimassa.

Alla on selkeä strategia: miten testata uudelleenohjauksia ilman seurauksia, miksi 302 säästää hermojasi virheenkorjauksessa ja mitä tehdä, jos välimuisti on jo jumissa oikeilla kävijöillä.

💡 Nopea yleiskatsaus:

• Aloita aina 302:lla (väliaikainen), testaa ja vaihda vasta sitten 301:een (pysyvä)
• Tyhjennä selaimen välimuisti aina, kun muutat uudelleenohjaussääntöjä
• Chromessa: DevTools → Network → Disable cache tai Application-välilehti → Clear site data
• Jos 301 on jo käyttäjien välimuistissa, voit vain odottaa tai vaihtaa kohdeosoitetta

Miten selain tallentaa 301-uudelleenohjauksen välimuistiin

Kun palvelin vastaa 301 Moved Permanently -tilakoodilla, selain tulkitsee sen kirjaimellisesti: "tämä osoite on siirtynyt pysyvästi". Se tallentaa parin "vanha URL → uusi URL" omaan uudelleenohjausvälimuistiinsa, joka on erillinen sivu- ja kuvavälimuistista.

Kun käyttäjä (tai sinä, kehittäjä) avaa saman osoitteen seuraavan kerran, selain ei lähetä pyyntöä palvelimelle lainkaan. Se korvaa osoitteen heti tallennetulla kohde-URL:lla välimuistista. Palvelin ei näe pyyntöä, etkä sinä näe nykyistä toimintaa.

HTTP-määrittely ei aseta tiukkaa säilytysaikaa tällaiselle välimuistille. Käytännössä Chrome, Firefox ja Safari pitävät 301:n välimuistissa, kunnes se tyhjennetään erikseen. Selain saattaa jättää palvelimen Cache-Control-otsakkeen huomiotta nimenomaan 301:n kohdalla, koska "pysyvästi" tarkoittaa pysyvästi.

Tämä toiminta on ominaisuus, ei bugi. Se säästää edestakaisen pyynnön oikeutetuissa pysyvissä siirroissa (esimerkiksi verkkotunnuksen vaihto). Kehitysvaiheessa siitä tulee kuitenkin ansa.

Miksi tämä aiheuttaa ongelmia määritysvaiheessa

Kuvittele tilanne. Määrität uudelleenohjausta vanhasta osoitteesta /old-page osoitteeseen /new-page. Asetat 301:n, testaat selaimessa ja se toimii. Tuntia myöhemmin huomaat tehneesi virheen: oikea osoite onkin /new-page/v2.

Muutat säännön palvelimella ja painat selaimessa "päivitä". Päädyt osoitteeseen /new-page. Taas. Koska selain muisti jo ensimmäisen parin eikä anna palvelimelle mahdollisuutta näyttää uutta sääntöä.

Luulet, ettei uudelleenohjaus toimi. Todellisuudessa se toimii, mutta ei se, jonka juuri määritit.

Testisivustolla käytimme kerran puoli tuntia .htaccess-sääntöjen kiertelyyn, ennen kuin tajusimme selaimen näyttävän välimuistia. Tyhjensimme välimuistin, ja kaikki toimi heti tarkoitetulla tavalla.

Tilanne on pahempi kävijöiden kohdalla. Jos aktivoit virheellisen 301:n tuotantosivustolla, jokainen niiden minuuttien aikana vieraillut sai väärän säännön selaimeensa. Korjasit virheen palvelimella 10 minuutissa, mutta heidän selaimensa ohjaavat vanhaan osoitteeseen päiviä tai viikkoja, kunnes välimuisti tyhjennetään.

Huomio: et voi tyhjentää uudelleenohjausvälimuistia käyttäjän puolelta. Mikään palvelinkikka ei yllä toisen selaimelle.

302 → 301 -Strategia: testaa ilman seurauksia

Sääntö, joka säästää tunteja virheenkorjausta ja suojaa virheiltä live-sivustolla:

Aloita aina 302 (väliaikainen) -uudelleenohjauksella. Vaihda 301:een vasta, kun olet varma, että sääntö on oikein.

Selain ei tallenna 302:ta aggressiivisesti välimuistiin; se kysyy palvelimelta uudelleen jokaisella pyynnöllä. Muuta sääntö palvelimella, ja selain poimii uuden toiminnan heti. Välimuistin tyhjennystä ei tarvita.

Vaiheittainen lähestymistapa mille tahansa URL-muutokselle:

• Määritä 302-uudelleenohjaus .htaccess-tiedostossa, Nginx-asetuksissa tai WordPress-lisäosan kautta (esimerkiksi Redirection).
• Avaa vanha URL incognito-tilassa tai DevToolsissa "Disable cache" -valinta päällä.
• Varmista, että päädyt oikealle kohdesivulle.
• Tarkista 2-3 lisäosoitetta samasta ryhmästä.
• Vasta kun kaikki on testattu, korvaa 302 301:llä säännöissä.
• Tee lopputarkistus normaalissa selaintilassa.

Käytännössä tämä lähestymistapa vie tasan kaksi ylimääräistä minuuttia uudelleenohjausryhmää kohden ja poistaa täysin "välimuistivirheen" riskin kävijöille.

Jos käytät Redirection-lisäosaa WordPressille, se luo oletuksena 301:n. Vaihda manuaalisesti 302:een pudotusvalikosta sääntöä luodessasi, äläkä unohda vaihtaa takaisin 301:een testauksen jälkeen.

Miten tyhjentää uudelleenohjausvälimuisti paikallisesti

Kun selain on jo muistanut virheellisen 301:n etkä näe nykyistä toimintaa, tässä on apukeinot:

Chrome. Avaa DevTools (F12), siirry Network-välilehdelle ja valitse Disable cache. Tai tee täysi nollaus: Application → Clear storage → Clear site data. Luotettavin tapa tietylle sivustolle on chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Täydellinen tyhjennys: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (Develop-valikko otetaan käyttöön Settings → Advanced -kohdassa).

Incognito-tila on nopea tapa tarkistaa tuore toiminta tyhjentämättä päävälimuistia. Selain käyttää puhdasta istuntoa, jossa ei ole tallennettuja uudelleenohjauksia.

Tärkeä vivahde: selaimen sulkeminen EI tyhjennä 301-uudelleenohjausvälimuistia. Toisin kuin istuntotallennus, uudelleenohjausvälimuisti säilyy selaimen uudelleenkäynnistyksissä. Vain erillinen tyhjennys tai incognito-tila toimii.

Mitä tehdä, jos välimuisti on jumissa käyttäjillä

Tämä on epämiellyttävin skenaario: virheellinen 301 oli aktiivisena tuotantosivustolla jonkin aikaa, ja osa yleisöstäsi kantaa sitä nyt selaimensa välimuistissa. Korjasit palvelimen säännön, mutta nämä käyttäjät päätyvät yhä väärään paikkaan.

Tässä on mitä voit tehdä:

• Vaihda kohde-URL uuteen. Jos vanha location osoitti /page-v1:een ja tarvitset /page-v2:n, vaihda osoite samassa säännössä. Selaimet, joissa on vanha kohde-URL välimuistissa, jatkavat sinne menemistä (ongelma). Uudet kävijät menevät kuitenkin oikeaan paikkaan. Tämä ei ratkaise ongelmaa jo "tartunnan saaneille", mutta pysäyttää leviämisen.

• Käytä eri uudelleenohjausmenetelmää. Jos 301 on välimuistissa, selain ei kysy palvelimelta, mutta palvelinlogiikka toimii yhä uusille kävijöille. Lisää JavaScript-uudelleenohjaus kohdesivulle lisäkerroksena HTTP-uudelleenohjauksen päälle niille, jotka yhä päätyvät vanhalle sivulle.

• Tunnusta rehellisesti: suoraa parannuskeinoa ei ole. Et pääse käyttäjän selaimeen käsiksi. Jos välimuisti on jo ladattu, ainoa tapa nollata se on käyttäjän oma välimuistin tyhjennys tai vierailu incognito-linkin kautta. Onneksi uudelleenohjausvälimuisti ei elä ikuisesti: selaimen uudelleenasennus, laitevaihdokset ja käyttöjärjestelmäpäivitykset nollaavat sen lopulta.

Kokemuksemme mukaan virheellinen 301 muuttuu kriittiseksi vain kahdessa tapauksessa: massamuutto (satoja URL-osoitteita), jossa on virhe säännöissä, tai etusivun uudelleenohjaus. Molemmissa tapauksissa välimuistivirheen aiheuttama vahinko on suurempi kuin testauksen ohittamisella säästetty aika.

301, 302, 307, 308: Milloin mitäkin käytetään

Sekaannusten välttämiseksi pidä tämä nopea uudelleenohjauskooditaulukko käsillä:

WordPress-sivustolle riittää valtaosassa tapauksia 301:n ja 302:n eron tunteminen. Koodit 307 ja 308 ovat niche-työkaluja tilanteisiin, joissa HTTP-metodin säilyttäminen on kriittistä (esimerkiksi lomakkeen on pysyttävä POST-pyyntönä eikä muututtava GET:ksi uudelleenohjauksen aikana).

Lyhyesti: 302 on työkalusi kehitysvaiheessa. 301 on lopullinen "valmis"-leima.

Vielä yksi ansa: WordPress ja välimuistilisäosat

WordPressissä 301-välimuistiongelma kertautuu palvelin- ja lisäosavälimuistituksen päälle. Tyypillinen tilanne:

Muokkaat uudelleenohjausta Redirection-lisäosassa, klikkaat "tallenna", eikä se toimi. Tyhjennät selaimen välimuistin, ja vanha sivu tulee yhä näkyviin. Mitä tapahtuu? Välimuistilisäosa (WP Rocket, LiteSpeed Cache, W3 Total Cache) tarjoili välimuistissa olevan version sivusta; palvelin ei koskaan edes suorittanut uudelleenohjaussääntöä.

Vaiheet uudelleenohjausten virheenkorjaukseen WordPressissä:

• Tyhjennä välimuistilisäosan välimuisti (jokaisessa lisäosassa on oma "Purge All Cache" -painike).
• Poista välimuistitus käytöstä testauksen ajaksi (WP Rocketissa tämä on Development Mode).
• Tyhjennä selaimen välimuisti (kuten yllä on kuvattu).
• Testaa uudelleenohjaus vasta sitten.

Testisivustolla pidämme välimuistilisäosan pois päältä, kunnes kaikki uudelleenohjaukset ovat täysin valmiita, ja otamme sen käyttöön vasta lopullisen 302 → 301 -vaihdon jälkeen.

Tämä lyhyt englanninkielinen video havainnollistaa visuaalisesti 301:n ja 302:n eron käytännössä ja selittää, miksi uudelleenohjauskoodin valinta vaikuttaa SEO:hon:

⁉️🤔 Usein kysytyt kysymykset

Miksi selain tallentaa 301:n välimuistiin sen sijaan, että kysyisi palvelimelta joka kerta?

HTTP-määrittely määrittelee 301:n "resurssi on siirtynyt pysyvästi". Palvelimen kysyminen joka kerta URL:ää avattaessa olisi ristiriidassa "pysyvästi"-merkityksen kanssa ja loisi turhaa kuormaa. Uudelleenohjauksen välimuistitus säästää yhden HTTP-pyynnön kävijää kohden. Kymmenien tuhansien käyntien mittakaavassa tämä nopeuttaa navigointia huomattavasti. Selain tallentaa välimuistiin itse uudelleenohjaustiedon ("mistä → mihin" -parin), ei sivun sisältöä. Tämä on erillinen välimuistityyppi nimeltä redirect cache. Chrome tallentaa sen käyttäjäprofiiliin; Firefox tallentaa sen places.sqlite-tiedostoon yhdessä navigointihistorian kanssa. Siksi kuva- ja skriptivälimuistin tyhjennys ei aina nollaa uudelleenohjauksia; tarvitset täyden tyhjennyksen tai sivustotietojen tyhjennyksen.

Voiko selainta estää tallentamasta 301:tä välimuistiin palvelimen puolelta?

Muodollisesti ei. Selaimet saattavat jättää Cache-Control: no-store -otsakkeen huomiotta pysyvien uudelleenohjausten kohdalla. Määrittely ei vaadi selaimia noudattamaan Cache-Control-otsaketta 301/308-koodeille, koska pysyvä uudelleenohjaus tarkoittaa, ettei sääntö muutu. Jotkin Chrome- ja Firefox-versiot kunnioittavat Cache-Control-otsaketta 301:n kohdalla, mutta tähän ei voi luottaa tuotannossa; toiminta ei ole taattu ja vaihtelee versioittain. Ainoa luotettava tapa "perua" 301:n selainvälimuistitus on käyttää aluksi 302:ta testauksen aikana. Jos 301 on jo käyttäjän välimuistissa, palvelin on voimaton.

Miten 302 eroaa 307:stä käytännössä?

Molemmat ovat väliaikaisia uudelleenohjauksia, eikä kumpaakaan tallenneta selaimen välimuistiin. Ero on HTTP-metodin käsittelyssä. 302:n kohdalla selain saattaa muuttaa POST-pyynnön GET:ksi uudelleenohjauksen aikana (näin tapahtui historiallisesti, ja monet selaimet tekevät niin yhä). 307:n kohdalla metodi säilyy taatusti: POST pysyy POSTina, PUT pysyy PUTina. WordPressille ja käytännössä mille tahansa sivustolle ero on merkityksetön, koska uudelleenohjaukset koskevat lähes aina GET-pyyntöjä (sivun avaaminen). 307:ää tarvitaan vain, jos lomakkeet, rajapinnat tai tiedostojen lähetykset kulkevat väliaikaisesti uudelleenohjattavan URL:n kautta.

Miten voin tarkistaa, mikä uudelleenohjaus on selaimeni välimuistissa?

Avaa DevTools (F12) → Network-välilehti ja valitse "Disable cache" (tämä on PAKOLLISTA, muuten selain ei tee pyyntöä palvelimelle etkä näe nykyistä vastausta). Avaa sitten vanha URL. Status-sarakkeessa näet todellisen vastauskoodin palvelimelta (301, 302 jne.) ja Location-otsakkeen kohde-URL:n kanssa. Ilman "Disable cache" -valintaa DevTools näyttää 200-tilan tai (disk cache), mikä tarkoittaa selaimen tarjoilleen välimuistista eikä palvelimelta kysytty.

Tarvitseeko 301-uudelleenohjaus säilyttää ikuisesti?

Google suosittelee pitämään pysyvät uudelleenohjaukset vähintään vuoden ajan siirron jälkeen. Käytännössä, jos vanhaa URL:ää ei enää mainosteta, sillä ei ole ulkoisia linkkejä eikä se ole hakukoneiden indeksissä, uudelleenohjauksen voi poistaa 6-12 kuukauden kuluttua. Jos kuitenkin muut sivustot linkittivät vanhaan URL:ään tai se on hakukoneiden indekseissä, uudelleenohjaus kannattaa pitää pysyvästi. 301:n poistaminen, kun käyttäjillä on sääntö välimuistissa, ei ratkaise ongelmaa; heidän selaimensa jatkavat välimuistissa olevan parin käyttöä, kunnes he tyhjentävät välimuistin.

Pitäisikö 301-uudelleenohjauksia pelätä?

Ei, jos noudatat "302 ensin" -sääntöä. Pysyvä uudelleenohjaus on luotettava työkalu sisällön siirtämiseen, verkkotunnusten vaihtamiseen ja duplikaattien siivoamiseen. Ongelmia syntyy vain, kun 301 asetetaan ilman testausta.

Muista avainkohta: 301 on lupaus selaimelle, että "en muuta mieltäni". Älä tee tätä lupausta, ennen kuin olet varma. Kymmenen minuuttia 302-uudelleenohjauksen testausta incognito-tilassa säästää päiviä välimuistivirheiden siivoamiselta live-yleisöltäsi.