Kun sivustolle tulee riittävästi ikää ja aikojen saatossa kokeilee erilaisia ratkaisuja ja rakenteita, niin uudelleenohjauksia kertyy. Jossain vaiheessa saa taatusti aikaiseksi päättymättömiä luuppeja tai muutoin vääriä ohjauksia. Ne kuitenkin useimmiten löytää kohtuullisen helposti. Kun tarpeeksi säätää, niin saa aikaiseksi omituisempia tapauksia. Silloin rikkinäisen redirectionin löytäminen WordPressin uumenista saattaakin olla haastavampaa.

Itselläni on tullut vastaan kaksi omituisuutta. Ensimmäisessä tapauksessa minulla oli kategoria site, jossa jokainen sen sisältävä url antoi error 404 – tosin kertomatrta sitä WordPressille, koska virhe tuli ennen kuin WordPressin sisältö tuli mukaan kuvioihin. Siihen syy löytyi Apachen virtual hostin asetuksesta +Multiviews, joka arpoi mielestään lähelle sopivamman osoitteen piittaamatta siitä, että sivustolta olisi löytynyt aitokin.

Toinen meinasi aiheuttaa urakalla harmaita hiuksia. Minulla on samassa virtuaalipalvelimessa useampi sivusto ja kaikkia koskeva uudelleenohjaus toimi parissa ja parissa ei.

Varnish ja ehdollinen redirect

Virtuaaliserverillä on vaikea tehdä ehdollisia uudelleenohjauksia ja webhotelleissa moinen on täysin mahdotonta palvelimen tasolla. Ehdollinen 301/410 redirect on ajatus, että jos url antaa error 404, niin silloin tehdään uudelleenohjaus, mutta jos samankaltainen url antaakin normaalin vastauksen 200, niin sivu näytetään.

Tiedän, kyseessä on eräällä tavalla hienostelevaa nipotusta pikkuasioilla. Minulla on osassa sivustoja arkiston alasivut osoitteella /page/ – esimerkiksi /page/4. Jos, ja kun, siinä kategoriassa, tagissa tai muussa taksonomiassa artikkelien määrä vähenee, niin osa alasivuista antaa error 404. Jos alasivu löytyy, niin vastaus on 200. Siksi on mahdotonta tehdä kaiken kattavaa ohjausta /page/ osoitteille. Edes esimerkiksi tällä hetkellä 404 antava /page/3/ saattaa kuitenkin olla relevantti url, kun juttujen määrä ajan myötä taas Google yrittää niitä arvioilta puoli vuotta, MSN sellaiset pari vuotta ja Bing yrittää yli 10 vuotta vanhoja osumia. Siksi 404:set kannattaa ohjata, koska täysin turhat ikivanhat ja jo kuolleet osoitteet vaikeuttavat aitojen ja ajankohtaisten löytämistä.

Hyödynsin Varnishia kertomaan uudelleenohjauksen, jos /page/ antaa 404 virheen ja jatkamaan normaalisti, jos sivu löytyy. Käytin tällaista karvalakkiviritystä:

sub vcl_backend_response {
...
if (beresp.status == 404 &&  (
      bereq.url ~ "/wp-content/cache/" # vanhat WP Rocket cachetiedostot, joita Bing ei osaa käsitellä
   || bereq.url ~ "\?cat\=" # tyhjä kategoria
   || bereq.url ~ "/page/" # tyhjät arkistojen alasivut
   || bereq.url ~ "/feed/" # vanhat RSS-syötteet
)) {
   set beresp.ttl = 86400s;
   set beresp.status = 410;
   return(deliver);
}
...
}

Kun backend, Apache minulla, kertoo, että urlia ei löydy, niin kävijälle kerrotaan error 410 ja ohjaus laitetaan 24 tunniksi cacheen, niin seuraava saa nopeammin saman vastauksen. Jos Apache löytää urlin, niin kaikki jatkuu normaalisti.

Koska joudutaan odottamaan vastausta Apachelta, niin WordPressin redirectien seuranta, vaikka Rank Math SEO:n toimesta, näyttää error 404 – koska sehän oli saatu aikaiseksi. Etu on siinä, että urlin saa poistaa heti listoilta ilman kommervenkkeja, koska sitä kyselleelle – käytännössä aina hakukone – on jo kerrottu, että url on poistettu käytöstä.

Vastaavan saisi tehtyä 301 redirectillä:

if (beresp.status == 404 && bereq.url ~ "/page/") {
   set beresp.ttl = 86400s;
   set beresp.status = 301;
   set bereq.url = "/joku-osoite/";
   return(deliver);
}

Nyt jos Apache sanoo, että vaikkapa /page/3/ ei löydy, niin tehdään 301 uudelleenohjaus urliin https://www.example.tld/joku-osoite/. Jos /page/3/ löytyy, niin se näytetään kävijälle.

Voit tutustua käyttämääni Varnishin setuppiin Githubissa.

Toimii ja ei toimi

Olin tyytyväinen. Olin testannut ehdollisen ohjauksen toimivuutta yhdessä domainilla ja se oli toiminut. Kun pengoin myöhemmin logeja, niin törmäsin vahingossa merkintään, että taatusti poistunut /page/9/ antoi vastauksen 200 eli se oli löytynyt.

Testasin asiaa aivan mahdottomalla osoitteella /page/9999 ja sekin väitti, että löytyy. Selaimessa kokeiltaessa sain eteeni sivuston etusivun. Parilla sivustolla kääntö sen sijaan toimi. Olin siis tilanteessa, jossa pari sivustoa oli piittaamatta tehdystä uudelleenohjauksesta ja teki ikioman uudelleenohjauksen, jota ei edes kerrottu uudelleenohjaukseksi.

Kytkin Varnishin pois päältä, eikä tilanne korjaantunut. Ohitin keulalla olevan Nginxin, eikä tilanne korjaantunut. Otin taustalla olevan Apachen pois ja korvasin sen Nginxinlle, tilanne ei korjaantunut.

Kokeilujen aikana olin jo huomannut, että Varnish vaikutti headereihin. Kun se oli päällä, niin uudelleenohjaus ilmoitti 200 OK. Kun Varnish oli pois päältä, niin headereista löytyi 301 redirect sekä x-redirect-by: WordPress.

Olin jo ihmeissäni. Kaksi WordPress asennusta teki uudelleenohjauksen kuten kuului, mutta kaksi tarjosi kivenkovaa etusivua ilman virheitä ja uudelleenohjausilmoituksia. Koska syy ei ollut servereissä, x-redirect-by paljasti asialla olevan WordPress, niin syypää on sivustolla. Ongelma oli siinä, että asennukset olivat hyvin samanlaisia. Tein kuitenkin mitä kuului, eli poistin lisäosat ja vaihdoin teemaksi 2019. Tilanne pysyi entisellään.

WordPressin kanoninen uudelleenohjaus

Asia alkoi olla jo selvä. Syypää oli WordPress itsessään. En vain tiennyt mistä oli kyse. Koska olin saanut karsittua vaihtoehdot, niin googlettaminen oli helpompaa ja vastauskin löytyi kohtuullisen vaivatta.

WordPressissä on sisäänrakennettu ominaisuus ohjata uudestaan permalinkit. Sen takia osoiterakenteen saa muutettua ilman, että serverillä tai .htaccess-tiedostossa täytyy tehdä muutoksia. Koska page on ollut osa permalinkkejä, niin WordPressin (dokumentoimaton) ominaisuus on ohjata taksonomiaan liittyviä alasivuja etusivulle, kun sellainen puuttuu.

Se, että moinen ei toiminut kaikilla sivustoilla, johtunee saittien iästä ja mitä lisäosia on aikojen saatossa käytetty. Kaikilla sivustoilla alasivujen slug ei ollutkaan page.

Kanoninen uudelleenohjaus on mahdollista sammuttaa. Homma hoituu laittamalla tämä lapsiteeman functions.php tiedostoon tai Code Snippettiin:

remove_filter</span><span class="br0">(</span><span class="st1">'template_redirect'</span><span class="">, </span><span class="st1">'redirect_canonical'</span><span class="br0">)</span><span class="">;

WordPressin oman uudelleenohjauksen ottaminen pois päältä ei kuitenkaan ole välttämättä hyvä ajatus. Se rikkoo jonkun verran perustoiminnallisuuksia.

Lopputulos oli, että parilla sivustolla en saanut omaa uudelleenohjausta toimimaan. Kyseessä ei kuitenkaan ollut kuin yhden url-rakenteen poikkeus, ja kun siinäkään ei käyttäjää tai hakukonetta jätetä tyhjän päälle roikkumaan niin asian kanssa pystyy elämään.