Uudelleenohjaukset ovat varmasti tuttuja monelle web-sivujensa kanssa painivalle. Jos ei ole, niin syytä olisi olla. Tuokin oli hieman jyrkästi sanottu, koska aidosti kyse ei ole niin isosta asiasta. Sivusto pyörii ja toimii ihan ilman ensimmäistäkään redirectiä mihinkään suuntaan. Asiaan kannattaisi kuitenkin hieman kiinnittää huomiota, koska sillä saattaa olla merkitystä hakukonesijoituksille ja taatusti käyttäjämukavuudella. Ohjaus kannattaa asettaa aina, kun sivun osoite muuttuu tai se poistetaan. Yleensä 301-ohjausta, jolla neuvotaan uusi osoite, pidetään tärkeimpänä. Itse pidän kuitenkin jollain tavalla 41o redirectiä jopa oleellisempana. Sillä kerrotaan, että sisältö on kokonaan poistettu, eikäkävijä saa sitä enää koskaan.

Aidosti en haluaisi laittaa vastakkain 301 Redirect ja 410 Gone ohjauksia. Ne ovat eri asioita, vaikka niitä käytännössä käytetäänkin päällekkäin. Laiskan ratkaisu on tehdä kaikkiin poistetuohin aina 301 Redirect esimerkiksi etusivulle. Ei sille ole olemassa mitään muuta ideaa kuin laiskuus. Monet SEO-laskuttajat väittävät kirkkain silmin, että saadaan pidettyä SEO-juice sivustolla ja parannettua hakukonenäkyvyyttä, mutta se on aivan puuta heinää.

Poistetuilla sivuilla ei ole SEO-arvoa. Myöskään niillä tuhottomalla määrällä ns. turhia sivuja, jotka näkyvät sitemapissä, mutta joihin ei ole edes jakoja, ei ole mitään SEO-arvoa. Ja vaikka hakusanojen kautta olisikin, niin se hajoaa välittömästi etusivulle (tai minne tahansa) uudelleenohjauksessa, koska vanhat keywordit katoavat ja tilalle tulevat uudet- ja ne uudet saataisiin muutenkin käyttöön, kun

• sitemap on kunnossa,
• sivustolla on asiallisia sisäisiä linkkejä,
• hakemistorakenne on looginen
• Googlebot kutsutaan kylään, kun sisältö päivittyy tai luodaan uutta.

Se, että sivustolla on tolkuton määrä ohjauksia etusivulle, ei auta ketään eikä mitään.

Joka sääntöön on olemassa poikkeuksensa ja poistettavan osoitteen kohdalla poikkeus on tilanne, että linkkiä on joskus jaettu muualle. Vaikka sisältö olisikin muuttunut vähemmän relevantiksi, niin moista ei kannata poistaa ilman uudelleenohjausta. Ainakaan Googlen suhteen ei kannattaisi, sillä uudelleenohjauksella saadaan ulkoisen linkityksen arvo siirrettyä jollekin muulle postaukselle.

Tuossakin saa käyttää järkeä. Jos mietinnässä on linkki sinänsä arvottomalta sivustolta, kuten vaikka toisesta WordPressistä, jonka webmaster on wordpressimäiseen bloggauksen arvoa vähentävään tapaan antanut ulkoiselle linkille olla nofollow-tag päällä, niin on ihan se ja sama mitä teet uudelleenohjaukselle Googlen suhteen. Sama juttu jostain muutoin vähäarvoisesta lähteestä.

Uudelleenohjauksen ja 410 Gone ilmoituksen arvo tuleekin miettiä aidon kohteen mukaan: ihmiskävijät. SEO-konsultit hämärtävät tätä perusajatusta koko ajan ja siksi yleensä heidän omat sivustonsa ovat jotain hyödyttömän ja käyttökelvottoman välillä. Sivustoja ei tehdä Googlelle, ne tehdään ihmisille. Kun saat kävijöitä, niin SEO-arvosi nousee paljon reippaammin kuin kikkailuilla uudelleenohjausten kanssa.

Jos alkuperäinen linkki osui juttuun miten teknistä gizmoa nimeltä Foo käytetään ja uudelleenohjaatkin sen sivulle, jossa myydään elämäntapakurssia ajatuksen Bar käyttöstä, niin voit olla aivan varma, että kävijä ei koskaan enää tule sivustollesi aivan riippumatta siitä mikä osuman sijainti oli hakutuloksissa. Parempi vaihtoehto olisi esittää edes 404-sivu. Tai jopa 410-sivu.

Reagoidako error 404 osumaan

Periaatteessa poistetulle sisällölle ei tarvitse tehdä mitään. Kun botit saavat käynnistään vastaukseksi error 404 niin niiden pitäisi ajan X jälkeen merkitä osoite poistuneeksi. Todellisuus ei vaan ole aivan näin ruusuinen.

Jos minulta poistuu osoite ilman uudelleenohjausta, niin Google kokeilee linkkiä muutaman kerran parin päivän ajan, ennenkuin luovuttaa. Jos en tee mitään, niin Google tekee uuden yrityksen jonkun viikon kuluttua. Minulle tulee edelleen satunnaisesti Googlelta osumia vanhaan sivustopohjaan, jota ei ole ollut enää käytössä yli vuoteen.

Bing ja kumppanit ovat vielä herkeämättömämpiä. Ne eivät koskaan korjaa listojaan. Minulta tulee Bingin kautta yrityksiä urleihin, joita ei ole ollut olemassa yli 10 vuoteen.

Sen sijaan error 410 Gone ilmoituksella olen saanut kunnolliset hakukoneet järjestykseen – botteihin ja SEO-crawlereihinhan ei tehoa yhtään mikään muu kuin ikuinen porttikielto. Mielenkiintoista on ollut se, että 301 Redirect ei ole toiminut läheskään yhtä hyvin, ei edes Googlebotin suhteen. Yhteen aikaan luulin, että se johtui WordPressissä lisäosalla tehdyistä ohjauksista. Oletin, että redirect-tieto ei menisi boteille, koska se tehdäään vasta sivustolla. Mutta kyse ei ole siitä, sillä 301-ohjaus virtual hostissa ei myöskään muuttanut bottien, mukaanlukien Googlen, toimintaa. Jos poistan virtual hostissa olevat puoli vuotta tai vanhemmat uudelleenohjaukset, niin Google, Bing, Slurp jne. kunnialliset hakukonebotit yrittävät taas vanhaa osoitetta.

Minulla on joka paikkaan ilmoitettu https-osoite. Virtual host kääntää välittömästi porttiin 80 tulevan pyynnän https:ksi porttiin 443 antaen siitä ilmoituksen 301 Redirect. Silti kerta toisensa jälkeen yritetään portin 80 kautta. Kun botit eivät kunnioita tuota pysyvää uudelleenohjausta, niin ei ole yllättävää, että ne eivät kunnioita muitakaan.

Tuo kaikki tarkoittaisi hakukoneiden suhteen muutamaa asiaa:

• error 404 häviää jossain vaiheessa
• ohjaus ilmoituksella 410 Gone lopettaa nopeasti yritykset vanhaan osoitteeseen
• 301 Redirect toimii, mutta ei poista vanhaa osoitetta, ainakaan nopealla aikataululla

Sinälläänhän error 404 ei merkitse mitään hakukonesijoitukselle, eivätkä ne suutu ja rankaise niistä. Ainakaan virallisen totuuden mukaan.

Poistettuhin osumiin kannattaa reagoida ihmiskäyttäjien takia. Kyse on siitä kuuluisasta käyttäjäkokemuksesta. Kyse on lähinnä siitä, että tehdäkö

• uudelleenohjaus, jolloin kävijä saa jotain muuta kuin mitä odotti
• erillinen 404-sivu ja antaa kävijälle mahdollisuuden arvata onko vain rakenne muuttunut, tai etsiä korvaavaa sisältöä
• erillinen 410-sivu, jossa kerrotaan kävijälle, että sisältö on poistunut ja nyt kannattaisi etsiä jotain muuta

Oikeaa ja väärää vastausta ei ole. Se riippuu.

Käyttäjä ensin

Itse inhoan sitä, että kun luulen saavani asian X, niin joku muu on päättänyt minun puolestani, että asia Y on oleellisempaa – koska Googlen SEO ja muutama muu kuviteltu asia. Siksi noudatan muutamaa sääntöä:

• tekniset muutokset, kuten muuttunut slug, ohjataan automaattisesti uuteen osoitteeseen, mutta tavoitesivu ei sinällään muutu kävijän näkökannasta
• artikkeleiden yhdstämisessä ohjataan sivulle, joka pitää sisällään yhdistetyt asiat
• artikkelin poistuessa ohjataan jollekin vastaavaa asiaa käsittelevään juttuun
• 404 osumissa kerrotaan, että nyt on jokin rikki ja koska osumia seurataan, niin asia korjataan (ja se pitää myös korjata, ei vain luvata; samaa periaatetta kuin kommentoinnin kanssa). Error 404 antaa oman sivunsa, kuten vaikka tämä esimerkki.
• aidosti poistettu antaa 410-sivun, jossa kerrotaan, että aihe on poistettu. Kuten tässä.

Jokainen kohta perustuu siihen, että kävijää ei yllätetä. Kun linkkiä klikataan, niin tuloksen täytyy olla joko odotettu tai selitys miksi ei tullut mitä odotettiin. Siksi error 404 sivuja tehdään. Ei Google ja muut botit niitä kaipaa, niille kelpaa http-tila. Samasta syystä kävijälle täytyy kertoa, että sisältöä ei ole enää.

Error 404-sivu on rajoittunut siksi, että käyttäjä ei tiedä onko kyseessä

• oma virhe
• linkin virhe
• sivuston virhe
• poistunut sisältö

Siksi poistuneessa sisällössä kannattaa tehdä error 410 sivu ja kertoa suoraan, että sisältöä ei enää ole eikä sitä kannata tulevaisuudessakaan kokeilla. Yksi syy siihen miksi kaikenkattavat uudelleenohjaukset error 404/410 tapauksissa johonkin täysin epärelevanttiin sisältöön on niin huono käytäntö.

Toistan itseäni: sivustoja tehdään ihmisille, ei Googlelle. Ja kaikki mikä huomioi ihmiset, on Googlen mielestä hyvää politiikkaa.

Uuudelleenohjaus 410-sivulle

Kun ihminen saapuu sivulle, joka antaa error 404, niin tieto menee heti Googlelle ja se tekee sillä sitten joskus mitä tekee. Kävijälle sen sijaan on tarjottava tieto, että sisältöä ei löytynyt, ja mahdollisuus etsiä korvaavaa asiaa. Tämä mahdollisuus menetetään totaalisesti, kun tehdään ei löydy 404 tilanteissa kääntö etusivulle kuvitellun SEO-hyödyn takia.

Ainoa mitä saavutetaan, on täysin turha Googlen kääntö etusivulle (jonka Google tietää entuudestaan) tai jollekin muulle sivulle (jonka Google tietää entuudestaan sitemapin kautta) sekä ajan myötä hakutuloksen poistumisen Googlen tuloksista. Kävijä ei tiedä mitä tapahtui ja juoksee karkuun koskaan palaamatta, koska ei saanut sitä mitä odotti.

Error 404 sivu käyttäytyy aivan samoin Googlen suhteen, mutta on informatiivisempi kävijälle. Hän tietää mitä tapahtui ja halutessaan, kun selviää hetken kuluttua harmistuksestaan, voi yrittää etsiä korvaavaa sisältöä.

Sen sijaan poistetun sisällön suhteen Google saa samoin tiedon, että sisältö on poistettu, mutta kävijä käännetään joko 404-sivulle tai johonkin erilaiseen sisältöön redirect 301 kautta. Kävijälle näkyvä 404-tieto tulee tekniikasta, jonka mukaan error 410 on ”vain” error 404 tapahtuman poikkeus, erityistapaus.

• 404 tarkoittaa, että sisältöä ei löytynyt
• 410 tarkoittaa, että sisältöä ei löytynyt, koska se on poistettu

Google saa tietoonsa tuon eron, mutta käyttäjä ei. Silti tieto olisi oleellinen. 404-tapauksessa sivusto ei tiedä miksi virhe on aidosti tullut, mutta 410-virheessä tiedetään syy tarkkaan.

WordPressissä useimmat teemat, varsinkin laajemmat (ja maksulliset…) tarjoavat mahdollisuuden tehdä erillisen 404-sivun, johon error 404 tila käännetään. Suurin osa sisältöjärjestelmistä tarjoaa vastaavan. Sen sijaan en ole törmännyt yhteenkään, jos tarjoaisi mahdollisuuden erilliseen sivuun error 410 tilanteessa. Se täytyy siis tehdä itse.

Oma custom-virhesivu

Teknisesti 410-sivun tekeminen ei eroa mitenkään 404-sivun tekemisestä. Ylipäätään kaikki omat virhesivut tehdään aivan samalla tavalla.

Teet sivun haluamallasi tavalla ja sitten kerrot urlin virtual hostin asetuksissa tai .htaccess-tiedostossa. Ainakin periaatteessa, sillä Googlen antaa melkoisestikin kysymyksiä aiheesta custom error page doesn’t work.

Apache2

Lisää virtual hostiin lohkon <Directory /var/www/example.tld/public_html/> alle tämä:

ErrorDocument 410 "https://www.example.tld/error-410-gone-sisalto-on-poistettu/"

Periaatteessa koko polkua ei tarvitse antaa, vaan esimerkiksi /error-410-gone... pitäisi toimia samalla tavalla, kun polku annetaan suhteessa public_html hakemistoon eli webtietojen juureen. Paitsi, että WordPressillä en saanut sitä koskaan toimimaan, varsinkaan kun sivu oli tehty WordPressissä – johtunee WordPressin omista uudelleenohjauksista. Sen sijaan url toimi.

Webhotelleissa sama rivi laitetaan juurihakemiston .htaccess-tiedostoon – mutta tuon toimivuutta en ole kokeillut. Huomattavan paljon sen toimimattomuudesta on kuitenkin kyselty.

Nginx

Olen kertaalleen yrittänyt asettaa Nginxille omaa virhesivua, enkä onnistunut. Tosin se saattoi johtua serverin toteutuksesta. Mutta Googlen osumien mukaan se tehtäisiin näin virtual hostin conf-tiedoston server lohkossa:

error_page 410 @gone;

if ($gone_var) {
   return 410;
}

location @gone {
   rewrite https://www.example.tld/error-410-gone-sisalto-on-poistettu/ break;
}

Reverse proxyt ja Varnish

Jos sinulla on käytössä Varnish tai jokin muu reverse proxy, niin saat muutettua http-statuksen sekä tehtyä uudelleenohjauksen pyydetyn urlin mukaan. Tai en minä muista tiedä, mutta Varnishissa ainakin pystyy. Ongelmanpoikasta on pienessä kosmeettisessa ongelmassa, joka tekee ylläpidosta vaikeampaa.

Jokainen poistettu url pitäisi viedä erikseen if-lausekkeeseen per virtual host. Tuossa on aivan liikaa työtä, ainakin WordPresseissä, Niissä käytetään jotain SEO-palikkaa, kuten Rank Math SEO, vahtimaan urlien muuttumisia sekä 404-osumia. Niissä sitten asetetaan haluttu uudelleenohjaus tai merkitään 410 Gone ja jossain vaiheessa siirretään kertyneet ohjaukset virtual hostille pois lisäosasta paisuttamasta tietokantaa.

Varnishissa kannattaa tehdä ainoastaan globaalit, kaikki virtual hosteja koskevat käännökset. Yksi tapa on kutsua erillistä vcl-rutiinia:

sub global-redirect {
#
## Normally we do 404/410 redirects per every vhost.conf, but sometimes it is easier to tune up globally for all vhosts
##

# redirect 301

if (req.url ~ "^/sitemap.xml") {
   return(synth(720, "https://" + req.http.host + "/sitemap_index.xml"));
}

# error 410
if (
      req.url ~ "^/app-ads.txt"
   || req.url ~ "\?author=[1-9]"
   || req.url ~ "^/.well-known/assetlinks.json"
   ) {
      return(synth(410, "Error 410 Gone"));
    }

# more or less just an example; if not depending of UA this should do at vhost, but it is easier this way. Maybe.
If (req.http.User-Agent ~ "Googlebot" && req.http.url ~ "/mailster/form?id=3") {
   if (req.http.url ~ "cdn.katiska.info" || req.http.url ~ "%3Famp") {
      return(synth(410, "Gone"));
   }
}
# end of sub
}

Koska tämä on tehty boteille, niin en ole murehtinut uudelleenohjausta erillisille 410-sivulle. Tavallisen käyttäjän ei pitäisi eksyä näihin osoitteisiin edes vahingossa, joten jos joku tarkoituksella koputtaa, niin periaatteessa on aivan se ja sama saako erillisen infosivun vai ei.

• Löydät kaikki käytössäni olevat Varnish-asetukset Githubista.

Ylipäätään ohjaus tehdään aina backendiin. Periaatteessa marginaalisen tehosäästön kannalta uudelleenohjaukset tehtäisiin frontendissä, mutta silloin aletaan punnitsemaan työmäärää tai oman työnkulun jouhevuutta. WordPressin suhteen hankaluuksia tulee ylipäätään osoitteiden käytössä, koska WordPress haluaa päättävän kauttaviivan / mutta käyttäjät (ja usein ulkoiset linkit) eivät sitä laita. Silloin frontendissä on pakko antaa aina tarkka seurattava url kauttaviivalla ja ilman. Jos yrittää ohittaa asian ohjaamalla urlin sisältävällä lausekkeella, niin sitten on syytä pitää huolta, että mikään muu url ei ala samalla tavalla. Koko ongelma johtuu siitä, että WordPress uudelleeenkirjoittaa aivan kaikki osoitteet (ja samasta syystä virtul hostissa redirect-tiedot on oltava ennen WordPressin uudelleenohjauksia, ainakin Apachessa)

• Apachella /foo$ ja /foo/ toimii WordPressille aivan samalla tavalla, kun ohjaus on backendissä
• Ngixillä /foo$, /foo ja /foo/ toimivat kaikki eri tavalla, jos se on frontendinä

Minulla on Nginx > Varnish > Apache2. Silloin kävijän pyyntö menisi:

• Nginx siivoaa SSL:n ja ohjaa Varnishille
• Varnish toteaa, että ei ole cachessä ja ohjaa Apachelle
• Apache toteaa, että error 410 ja lähettää tiedon sekä uudelleenohjausosoitteen sisällön Varnishille (tai kysyy saman asian WordPressiltä, jos tieto on siellä lisäosan takia)
• Varnish saa 410 tiedon sekä uudelleenohjatun sivun sisällön ja siirtää sen Nginxille
• Nginx kertoo tilatiedon ja esittää kävijälle uudelleenohjatun sivun sisällön
• Koska Varnish cacheaa 410 osumat, niin seuraava samaa kysyvä saa heti tiedon cachestä eikä Apachelle mennä ollenkaan

Jos uudelleenohjaus olisi frontendsissä, niin

• Nginx siivoaa SSL:n ja toteaa, että tässä on uudelleenohjaus ja kysyy uudelleenohjaussivun sisältöä Varnishilta
• Varnish toteaa, että ei ole cachessa ja ohjaa Apachelle
• Apache lukee sivun ja antaa sen Varnishille
• Varnish antaa sisällön Nginxille
• Nginx palauttaa asiakkaalle tiedon error 410 ja näyttää uudelleenohjaussivun
• Koska Varnish cacheaa 410 osumat, niin seuraava samaa kysyvä saa heti tiedon cachesta eikä Apachelle mennä ollenkaan

Koska varsinaista ero ei ole sen mukaan mistä 410 tieto saadaan, niin ne kannattaa tehdä sinne mikä mukavammalta ja helpommalta tuntuu. Ja jos olet tuttu Nginxin kanssa niin map 410 virheille ei anna mahdollisuutta tehdä uudelleenohjausta.

WordPress ja custom 404

Asiaa ohittaen, mutta jos teema tarjoaa oman 404-sivun, niin serverille ei kannata moista asettaa. WordPress, siis teema, ohittaa sen. Serverin 404-sivu saadaan näkyviin vain jos teeman 404-rutiini poistetaan. Turhaa vaivaa taistella moisen kanssa.

Jos teema ei tarjoaa mahdollisuutta omaan 404-sivuuun, niin sitten voi hyödyntää .htaccess-tiedostoa, virtual hostia tai asentaa siihenkin hommaan erillisen lisäosan.

Mitä käyttäjälle tapahtuu?

Kun uudelleenohjaus erilliselle 410-sivulle tehdään, niin teknisemmin pompitaan näin:

• Google (ja käyttäjän selain) saa serveriltä virheen 410 ja Googlen pitäisi omien väitteidensä mukaan siivota url pois listoiltaan
• annetaan redirect 302 eli väliaikainen kääntö error 410 sivulle (se ei saa olla 301, koska silloin Google ja kaikki muut yhdistäisivät periaatteessa vanhan urlin virhe-sivuun)
• käytäjälle esitetään sivu, jossa kerrotaan mitä on tapahtunut; Google toteaa moisen olemassaolon, ja jatkaa matkaansa

Tee melkein mitä tahansa muuta, mutta älä käännä sellaista sivua, joka löytyy Googlen hakutuloksista, johonkin toiseen osoitteeseen poistotilanteissa. Tee error 410 siitä. Jos sivulla on jotain SEO- ja liikennearvoa, niin älä jeesustele hakukoneoptimoinneilla, vaan olet poistamatta moista kävijämagneettia aivan riippumalla miten se mallaa uuteen sisältöön. Sen sijaan voit jutun yhteydessä kertoa, että ”tässä on tämä, ja meillä on nykyään myös tällaista, jos kiinnostaa”.

Jos poistettua osoitetta ei löydy hakutuloksista, niin on herttisen yhdentekevää mitä sille teet – anna olla tai uudelleenohjaa miten lystäät, niin ketään ei kiinnosta, ei edes Googlea, SEO-arvosta puhumattakaan.