Muutsid 301 ümbersuunamist, aga brauser saadab külastajaid ikka visalt vanale URL-ile? Tuttav peavalu kõigile, kes on seadistanud saidi migratsioone või ümber struktureerinud linke.

Küsimus pole ei serveris ega WordPressis. Brauser jätab püsiva ümbersuunamise jäädavalt meelde ega päri seda serverilt uuesti; HTTP spetsifikatsioon töötabki nii. Kuni vahemälu aegub või kasutaja selle käsitsi tühjendab, jääb vana reegel kehtima.

Allpool on selge strateegia: kuidas testida ümbersuunamisi tagajärgedeta, miks 302 säästab silumise ajal närve ja mida teha, kui vahemälu on päris külastajate jaoks juba kinni kiilunud.

💡 Kiirülevaade:

• Alusta alati 302-ga (ajutine), testi ja alles siis vaheta 301 vastu (püsiv)
• Tühjenda brauseri vahemälu iga kord, kui muudad ümbersuunamisreegleid
• Chrome'is: DevTools → Network → Disable cache või Application tab → Clear site data
• Kui 301 on kasutajate poolt juba vahemällu salvestatud, saad ainult oodata või siht-URL-i muuta

Kuidas brauser 301 ümbersuunamist vahemällu salvestab

Kui server vastab staatusega 301 Moved Permanently, tõlgendab brauser seda sõna-sõnalt: „see URL on alatiseks kolinud". Ta salvestab paari „vana URL → uus URL" oma ümbersuunamiste vahemällu, mis on lehe- ja pildivahemälust eraldi.

Järgmisel korral, kui kasutaja (või sina kui arendaja) avab sama aadressi, ei saada brauser serverile üldse päringut. Ta asendab selle kohe vahemälust salvestatud siht-URL-iga. Server ei näe ühtegi päringut ja sina ei näe tegelikku käitumist.

HTTP spetsifikatsioon ei määra sellisele vahemälule ranget säilitusaega. Praktikas hoiavad Chrome, Firefox ja Safari 301 vahemälus kuni selle selgesõnalise tühjendamiseni. Serveri Cache-Control päist võib brauser just 301 puhul ignoreerida, sest „alatiseks" tähendabki alatiseks.

Selline käitumine on omadus, mitte viga. See säästab ühe päringu õiguspäraste püsivate kolimiste puhul (näiteks domeenivahetus). Arenduse ajal muutub see aga lõksuks.

Miks see seadistamise ajal probleeme tekitab

Kujuta ette stsenaariumi. Seadistad ümbersuunamist vanalt URL-ilt /old-page uuele /new-page. Seadistad 301, testid brauseris ja see töötab. Tund aega hiljem taipad, et tegid vea: õige URL on /new-page/v2.

Muudad reeglit serveris ja vajutad brauseris „värskenda". Maandud jälle lehel /new-page. Sest brauser jättis esimese paari juba meelde ega anna serverile võimalust uut reeglit näidata.

Arvad, et ümbersuunamine ei tööta. Tegelikult see töötab, lihtsalt mitte see, mille just seadistasid.

Testsaidil veetsime kunagi pool tundi .htaccess reegleid ringi ajades, enne kui taipasime, et brauser näitab vahemälu. Tühjendasime vahemälu ja kõik töötas kohe nii, nagu ette nähtud.

Külastajatega on olukord hullem. Kui aktiveerisid tootesaidil vale 301, said kõik neil minutitel külastanud inimesed oma brauseri vahemällu vale reegli. Parandasid vea serveris 10 minutiga, aga nende brauserid saadavad neid päevi või nädalaid vanale URL-ile edasi, kuni vahemälu tühjendatakse.

Märkus: kasutaja poolel ei saa ümbersuunamiste vahemälu tühjendada. Ükski serverinipp ei ulatu kellegi teise brauserisse.

302 → 301 Strateegia: testi tagajärgedeta

Reegel, mis säästab tunde silumist ja kaitseb vigade eest elaval saidil:

Alusta alati 302 (ajutise) ümbersuunamisega. Vaheta 301 vastu alles siis, kui oled kindel, et reegel on õige.

Brauser ei salvesta 302 agressiivselt vahemällu; ta küsib iga päringuga serverilt uuesti. Muuda reeglit serveris ja brauser võtab uue käitumise kohe üle. Vahemälu tühjendamist pole vaja.

Samm-sammuline lähenemine igale URL-i muudatusele:

• Seadista 302 ümbersuunamine failis .htaccess, Nginxi konfiguratsioonis või WordPressi pluginaga (näiteks Redirection).
• Ava vana URL inkognito režiimis või kui DevToolsis on valik „Disable cache" sees.
• Veendu, et maandud õigel sihtlehel.
• Kontrolli veel 2-3 sama grupi URL-i.
• Alles siis, kui kõik on testitud, asenda reeglites 302 → 301-ga.
• Tee viimane kontroll tavalises brauserirežiimis.

Praktikas võtab see lähenemine iga ümbersuunamiste grupi kohta täpselt kaks lisaminutit ja välistab täielikult „vahemällu salvestunud vea" riski külastajate jaoks.

Kui kasutad WordPressi Redirection pluginat, loob see vaikimisi 301. Reegli loomisel vaheta rippmenüüst käsitsi 302 peale ja ära unusta pärast testimist 301 peale tagasi vahetada.

Kuidas ümbersuunamiste vahemälu kohalikult tühjendada

Kui brauser on vale 301 juba meelde jätnud ja sa ei näe tegelikku käitumist, siis siin on, mis aitab:

Chrome. Ava DevTools (F12), mine Network vahelehele ja märgi linnuke Disable cache. Või tee täielik lähtestamine: Application → Clear storage → Clear site data. Konkreetse saidi jaoks on kõige usaldusväärsem meetod chrome://settings/clearBrowserData → Cached images and files.

Firefox. Web Developer Tools → Network → Disable Cache. Täielikuks tühjendamiseks: History → Clear Recent History → Cache.

Safari. Develop → Disable Caches (menüü Develop lubatakse Settings → Advanced all).

Inkognito režiim on kiire viis värske käitumise kontrollimiseks ilma põhivahemälu tühjendamata. Brauser kasutab puhast sessiooni ilma salvestatud ümbersuunamisteta.

Oluline nüanss: brauseri sulgemine EI tühjenda 301 ümbersuunamiste vahemälu. Erinevalt sessiooni salvestusruumist säilib ümbersuunamiste vahemälu ka brauseri taaskäivitamisel. Toimib ainult selgesõnaline tühjendamine või inkognito režiim.

Mida teha, kui vahemälu on kasutajatel kinni

See on kõige ebameeldivam stsenaarium: vale 301 oli tootesaidil mõnda aega aktiivne ja osa sinu vaatajaskonnast kannab seda nüüd oma brauseri vahemälus. Parandasid serveri reegli ära, aga need kasutajad maanduvad ikka vales kohas.

Siin on, mida saad teha:

• Muuda siht-URL uue vastu. Kui vana location osutas aadressile /page-v1 ja sul on vaja /page-v2, siis lihtsalt asenda aadress samas reeglis. Brauserid, kus on vana siht-URL vahemälus, lähevad sinna edasi (probleem). Uued külastajad aga lähevad õigesse kohta. See ei lahenda probleemi juba „nakatunute" jaoks, kuid peatab leviku.

• Kasuta teistsugust ümbersuunamise meetodit. Kui 301 on vahemälus, ei küsi brauser serverilt, kuid serveripoolne loogika töötab uute külastajate jaoks endiselt. Lisa sihtlehele JavaScripti ümbersuunamine täiendava kihina HTTP ümbersuunamise peale neile, kes ikka vanale lehele maanduvad.

• Tunnista ausalt: otsest ravimit pole. Sa ei pääse kasutaja brauserisse ligi. Kui vahemälu on juba laetud, on ainus viis see lähtestada, kui kasutaja tühjendab vahemälu või külastab inkognito lingi kaudu. Õnneks ei ela ümbersuunamiste vahemälu igavesti: brauseri uuesti installimine, seadmevahetused ja OS-i uuendused lähtestavad selle lõpuks.

Meie kogemuse kohaselt muutub vale 301 kriitiliseks ainult kahel juhul: massmigratsioon (sadu URL-e) veaga reeglites või avalehe ümbersuunamine. Mõlemal juhul kaalub vahemällu salvestunud vea kahju üles igasuguse testimise vahelejätmisega säästetud aja.

301, 302, 307, 308: Millal mida kasutada

Segaduse vältimiseks hoia see kiire ümbersuunamiskoodide tabel käepärast:

WordPressi saidi jaoks piisab valdavas enamuses juhtudest 301 ja 302 erinevuse teadmisest. Koodid 307 ja 308 on nišitööriistad olukordadeks, kus HTTP meetodi säilitamine on kriitiline (näiteks vorm peab jääma POST-päringuks ega tohi ümbersuunamise ajal GET-iks muutuda).

Lühidalt: 302 on sinu tööriist arenduse ajal. 301 on lõplik „valmis" tempel.

Veel üks lõks: WordPress ja vahemällu salvestamise pluginad

WordPressis kuhjub 301 vahemällu salvestamise probleem serveri ja pluginapõhise vahemällu salvestamise otsa. Tüüpiline olukord:

Muudad Redirection pluginas ümbersuunamist, vajutad „salvesta" ja see ei tööta. Tühjendad brauseri vahemälu ja ikka ilmub vana leht. Mis toimub? Vahemäluplugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) serveeris lehe vahemällu salvestatud versiooni; server ei käivitanud ümbersuunamisreeglit üldse.

Ümbersuunamiste silumise sammud WordPressis:

• Tühjenda vahemäluplugina vahemälu (igal pluginil on oma „Purge All Cache" nupp).
• Keela testimise ajaks vahemällu salvestamine (WP Rocketis on selleks Development Mode).
• Tühjenda brauseri vahemälu (nagu eespool kirjeldatud).
• Alles siis testi ümbersuunamist.

Testsaidil hoiame vahemäluplugina keelatuna, kuni kõik ümbersuunamised on täiesti valmis, ja lubame selle alles pärast lõplikku üleminekut 302-lt 301-le.

See lühike ingliskeelne video demonstreerib visuaalselt 301 ja 302 erinevust praktikas ning selgitab, miks ümbersuunamiskoodi valik mõjutab SEO-d:

⁉️🤔 Korduma kippuvad küsimused

Miks brauser salvestab 301 vahemällu, selle asemel et iga kord serverilt küsida?

HTTP spetsifikatsioon määratleb 301 kui „ressurss on alatiseks kolinud". Serveri küsimine iga kord, kui URL avatakse, oleks vastuolus sõna „alatiseks" tähendusega ja tekitaks tarbetut koormust. Ümbersuunamise vahemällu salvestamine säästab ühe HTTP päringu külastaja kohta. Kümnete tuhandete külastuste skaalal kiirendab see navigeerimist märgatavalt. Brauser salvestab vahemällu ümbersuunamise fakti enda (paari „kust → kuhu"), mitte lehe sisu. See on eraldiseisev vahemälu tüüp, mida nimetatakse ümbersuunamiste vahemäluks. Chrome salvestab selle kasutajaprofiili; Firefox salvestab selle faili places.sqlite koos navigeerimisajalooga. Seetõttu ei lähtesta piltide ja skriptide vahemälu tühjendamine alati ümbersuunamisi; vaja on täielikku tühjendamist või saidi andmete kustutamist.

Kas serveri poolel saab takistada brauseril 301 vahemällu salvestamast?

Formaalselt mitte. Brauserid võivad püsivate ümbersuunamiste puhul Cache-Control: no-store päist ignoreerida. Spetsifikatsioon ei nõua brauseritelt Cache-Control austamist 301/308 puhul, kuna püsiv ümbersuunamine eeldab, et reegel ei muutu. Mõned Chrome'i ja Firefoxi versioonid austavad Cache-Control päist 301 puhul, kuid toodangus ei saa sellele loota; käitumine ei ole garanteeritud ja varieerub versiooniti. Ainus usaldusväärne viis brauseri 301 vahemällu salvestamist „tagasi võtta" on algselt kasutada testimise ajal 302. Kui 301 on kasutaja poolt juba vahemällu salvestatud, on server jõuetu.

Mille poolest erineb 302 praktikas 307-st?

Mõlemad on ajutised ümbersuunamised ja kumbagi ei salvesta brauser vahemällu. Erinevus seisneb HTTP meetodi käsitlemises. 302 puhul võib brauser ümbersuunamise ajal POST-päringu GET-iks muuta (see juhtus ajalooliselt ja paljud brauserid teevad seda siiani). 307 puhul on meetodi säilimine garanteeritud: POST jääb POST-iks, PUT jääb PUT-iks. WordPressi ja praktiliselt iga saidi jaoks on erinevus tühine, kuna ümbersuunamised hõlmavad peaaegu alati GET-päringuid (lehe avamine). 307 on vajalik ainult siis, kui vormid, API-d või failide üleslaadimised läbivad URL-i, mida sa ajutiselt ümber suunad.

Kuidas kontrollida, milline ümbersuunamine on minu brauseris vahemällu salvestatud?

Ava DevTools (F12) → Network vaheleht ja märgi linnuke „Disable cache" (see on KOHUSTUSLIK, vastasel juhul ei tee brauser serverile päringut ja sa ei näe tegelikku vastust). Seejärel ava vana URL. Veerus Status näed tegelikku vastusekoodi serverilt (301, 302 jne) ja Location päist koos siht-URL-iga. Ilma „Disable cache" valikuta näitab DevTools staatust 200 või (disk cache), mis tähendab, et brauser serveeris vahemälust ja serverilt ei küsitud.

Kas 301 ümbersuunamist peab igavesti alles hoidma?

Google soovitab hoida püsivaid ümbersuunamisi pärast kolimist vähemalt aasta. Praktikas, kui vana URL-i enam ei reklaamita, sellel pole välislinke ja see pole indekseeritud, võib ümbersuunamise 6-12 kuu pärast eemaldada. Kui aga teised saidid linkisid vanale URL-ile või see on otsingumootorite indeksites, peaksid ümbersuunamist alaliselt hoidma. 301 eemaldamine reegliga, mille kasutajad on vahemällu salvestanud, ei lahenda probleemi; nende brauserid kasutavad vahemällu salvestatud paari edasi, kuni nad vahemälu tühjendavad.

Kas 301 ümbersuunamisi peaks kartma?

Ei, kui järgid reeglit „kõigepealt 302". Püsiv ümbersuunamine on usaldusväärne tööriist sisu teisaldamiseks, domeenide vahetamiseks ja duplikaatide koristamiseks. Probleemid tekivad ainult siis, kui 301 seadistatakse ilma testimata.

Pea meeles võtmepunkti: 301 on brauserile antud lubadus, et „ma ei muuda meelt". Ära anna seda lubadust enne, kui oled kindel. Kümme minutit 302 ümbersuunamise testimist inkognito režiimis säästab päevi, mis kuluks elava vaatajaskonna jaoks vahemällu salvestunud vigade koristamisele.