vaihtoehtoinen helvetti
Unessa.net : Web :
Tämä sivu sai alkunsa pitkällisen palvelintilastojen seurannan jälkeen kun lopulta sain tarpeekseni alati kasvavista virheellisten hakujen määrästä. Tässä dokumentissa on selostettu muutamia tapoja, joilla onnistuin vähentämään 404-virheilmoitusten määrän murto-osaan kahden kuukauden tarkastelujaksolla.
Tämä dokumentti kannattaa nähdä sekä opettavaisena kertomuksena siitä, miten ei kannata missään nimessä toimia, mutta toivottavasti myös jollain tavalla virikkeellisenä ohjeena yleisten ongelmakohtien löytämiseksi ja niiden ratkomiseksi.
Kaikki alkoi suunnilleen samana hetkenä kun siirsin unessa.net -domainin alle sisältöä vanhan kotisivuston pohjalta (helmikuussa 2000). Ensimmäinen perustavaa laatua oleva virhe oli siinä, että ajattelin onnistuvani yhdistämään vanhan ja uuden sivuston jotenkin niin, ettei vanhoihin sivuihin tarvitsisi juurikaan koskea. Tässä vaiheessa vanhoja, entiseltä sivustolta suoraan siirrettyjä sivuja, sivustolla oli suunnilleen n. 50-60.
Noin vuotta myöhemmin oli jo ilmeisen selvää, että entiseltä sivustolta siirretty materiaali (joka oli pääosin henkilökohtaisten kotisivujeni sekalaista, kevyttä tekstipainotteista sisältöä) olisi päivittämättömänä enemmän riesaksi kuin iloksi historiallisena muistona. Tein toisen ratkaisevan virheen ja poistin koko hakemistopuun ajattelematta sen kummemmin tästä aiheutuvia seurauksia.
Seuraukset olivat vähintäänkin ikäviä. Toimenpide aiheutti koko sivuston suurimman ylläpidollisen ongelman, jonka seuraukset ulottuvat osittain vielä kahden vuoden päähän, kirjoitushetkeen asti. 404-virheilmoituksia alkoi ropisemaan sekä hakukoneista että sivuston sisäisiltä sivuilta.
Joulukuussa 2001 tapahtui toinen suuri yksittäinen tapaus, jonka seuraukset olivat myöskin erittäin pitkäkestoiset. Ongelma syntyi kun palveluntarjoaja päätti palvelinkuorman alentamiseksi muuttaa web-palvelimen asetuksia lennossa. Asiasta ei tiedotettu etukäteen, joten muutokseen vastaaminen piti tehdä melkoisella kiireellä.
Uusi konfigurointi ei parsinut enää .html -päätteisiin tiedostoihin SSI-määreitä, joten yhdeltä istumalta lähes kaikki sivuston sivut (joita tuolloin oli kolmisen sataa) lakkasivat toimimasta.
Jälleen kerran, vielä täysin pelastettavissa ollut tilanne muuttui vakavaksi ja pitkävaikutteiseksi ongelmaksi väärin tehdyn nopean tilannearvion ja sen mukaan tehtyjen ratkaisujen vuoksi.
Lisäsin omaan .htaccess -tiedostoon rivin, joka korjasi ongelman ennalleen, mutta samalla päätin muuttaa useiden sivujen koodia niin, että sivut parsittaisiinkin SSI:n sijaan PHP:llä. Sivusto pirstaloitui täydelliseksi sekametelisopaksi kun joukossa olikin yhtäkkiä samaan aikaan .html, .shtml, .phtml ja .php -tiedostoja.
Arvatenkin samassa rytäkässä rikkoutui valtava määrä sivuston sisäisiä linkkejä, sekä erittäin monia hakukoneiden indekseissä olleita linkkejä. Soppa alkoi vaatimaan jo hämmennystä.
Unessa.net -sivuston (tätä kirjoitettaessa kolmen vuoden) kehitystyön aikana on tullut tehtyä myös lukuisia pienempiä yksittäisiä virhearviointeja ja suoranaisia mokia liittyen sivujen nimeämisiin ja poistamisiin yms.
Tällaiset yksittäiset virheet tuottavat edelleen jonkin verran 404-virheilmoituksia, yleensä sellaisista paikoista joista niitä ei itse huomaa. Tätä kirjoitettaessa sivuston sisäisen hakukoneen indeksissä on jo yli 500 sivua. Vaikka virhemarginaali olisi pienikin, joukkoon eksyy väkisinkin jo melkoisesti rikkinäisiä linkkejä ja sivulatausten kasvaessa 404-virheiden määrän paisumisen huomaa jo selvästi tilastoissa. Tämä oli viimeinen tikki - jotain täytyy tehdä!
Käytännössä 404-virheilmoitusten paikallistamisen ja karsimisen ainoa kunnollinen työkalu on web-palvelimen logit ja niistä johdetut raportit. Nebula tarjoaa asiakkailleen varsin kattavan ja hyvän statistiikkapalvelun, jonka avulla seurantaa on helppo tehdä. Käytännössä omat analyysini perustuivatkin täysin Weblog ja Webalizer -ohjelmien tuottamiin statistiikkoihin ja niiden analysointiin.
Edelliset marras- ja joulukuun tilastot näyttivät murheellisilta:
| Kuukausi | Kävijöitä | Sivulatauksia | 404 -virheitä | 404 -virheitä päivässä |
| Marraskuu 2002 | 18151 | 316347 | 2255 | 75,17 |
| Joulukuu 2002 | 17049 | 280489 | 2122 | 68,45 |
Rikkinäisten linkkien ongelman voi jakaa kolmeen osaan:
Sivuston sisäiset rikkinäiset linkit on helppo paikallistaa statistiikkaohjelmien 404-tilastoista, mutta niistä selviää vain ongelman toinen puoli, eli URL joka ei enää toimi. Sivu jolta tälle sivulle on linkattu jää arvoitukseksi.
Melkein kaikki sivustonhallintaohjelmat osaavat etsi ja korvaa-toiminnon, mutta moneen kertaan siihen pettyneenä en halunnut lähteä kokeilemaan onneani moisilla. Unix komentorivin hallitseva onnistunee myös verrattain helposti paikallistamaan halutut tiedostot, mutta allekirjoittanut tunnustautui kykenemättömäksi tähänkin ratkaisuun. Oli siis keksittävä jotain muuta.
Sain ajatuksen PHP:n käyttämisestä tämän ongelman ratkaisuun. Kun palvelin lataa joka 404-virheilmoituksen yhteydessä halutun virheilmoitussivun, miksei tälle sivulle voisi laittaa pientä ohjelmanpätkää, joka keräisi halutut tiedot yhteen?
Kehittelin ajatusta hieman lisää ja muutaman minuutin päästä ideoitu skripti olikin jo melkein valmis. Päätin laittaa skriptin lähettämään jokaisesta 404-virheilmoituksesta sähköpostia tiettyyn kontrolliosoitteeseen. Sähköpostiohjelmani lukee postit automaattisesti parin munuutin välein, joten tällä tavalla virheilmoituksista saisi samalla jonkunlaisen perstuntuman. Sähköpostin sisällöksi tuli 404-virheilmoituksen kutsun aiheuttanut URL, sivu, jolta tälle sivulle päästiin (palvelimen REFERER-tieto), sekä muita geneerisiä tietoja kuten lataajan selain, host ja ip.
Parin ensimmäisen tunnin jälkeen fiilis oli aika maaginen - sain samantien muutamia virheilmoitusmaileja postiini ja pystyin korjaamaan oman sivuston sisäisiä rikkinäisiä linkkejä melkein reaaliajassa.
Huomasin hyvin pian monien 404-virheilmoitusten tulevan Googlen (ja satunaisesti myös muiden) hakukoneiden hakusivuilta. Erityisen hämmästyttävältä vaikutti se, että Googlen indeksointirobotti tuntui sinnikkäästi käyvän useilla sivuilla yhä uudestaan ja uudestaan, vaikka saikin näistä vastaukseksi pelkän 404-virheilmoituksen.
Google-seikkailu
Suurimmat hakukoneet tarjoavat jonkinlaista palvelua rikkinäisten linkkien poistamiseen omista tietokannoistaan. Googlen ollessa selkeästi suurin yksittäinen 404-virheilmoitusten aiheuttaja, päätin listauttaa kaikki sen löytämät rikkinäiset linkit Googlen automaattiseen URLinpoistojärjestelmään. Kirjautumisen jälkeen syötin kymmenkunta rikkinäistä URLia ja jäin odottelemaan pending-tilan muuttumista. Sivulla luvattiin normaalin päivityksen hoituvan alle päivässä.
Seuraavana päivänä koin suurehkon hämmästyksen kun Googlen sivuilta tullut linkkibotti oli kolunnut syöttämiäni URLeja tasaisesti tunnin välein. Noin kymmenen URLin voimin 404-ilmoituksia oli tullut siis yön aikana yli 100 kappaletta! Olin hieman ymmälläni, mutta ajattelin kuitenkin odottaa ainakin toisen yön ennenkuin teen asialle mitään. Seuraavana aamuna tilanne ei ollut muuttunut miksikään. Virheilmoituksia tulvi sadoittain ja linkkibotti kävi itsepintaisesti tasan tunnin välein koluamassa samat URLit. URLinpoistojärjestelmä kertoi kaikkien syöttämieni osoitteiden tilan olevan edelleen pending. Olin varma, että järjestelmä oli mennyt jotenkin sekaisin ja lähetin asiasta samantien sähköpostia Googlen tekniselle osastolle. Automaattiviesti vastasi viestin tulleen perille. Meni vielä yksi päivä saman rumban parissa ennenkuin rummutus lopulta loppui. En koskaan saanut vastausta lähettämääni meiliin, mutta 404-virheilmoituksia sitäkin enemmän. Muutaman rikkinäisen osoitteen poistamiseen Googlen indeksistä tarvittiin reilut 700 404-kutsua. Mielenkiintoista. (Ehkä kyseessä on jonkinlainen tarkastusmekanismi siltä varalta, ettei sivua saa poistettua kannasta niin, että se otetaan hetkeksi pois ja laitetaan samantien takaisin. Todennäköisesti näin.)
Tämän seikkailun jälkeen tilanne vaikutti jo varsin hyvältä. Virheilmoituspostien määrä oli laskenut selvästi murto-osaan siitä, mitä se oli ollut muutamaa päivää aikaisemmin. Työtäkin oli tosin jo takana, sisäisiä linkkejä korjattu kymmeniä ja kaikki havaitut rikkinäiset linkit oli nyt poistettu Googlen indeksistä. Kaikki tämä muutaman päivän aikana.
Huomasin varsin nopeasti muutamia ulkopuolisia sivuja, joilta oli linkitetty sivuilleni siten, että sivun osoite oli myöhemmin muuttunut ja ko. linkki oli jäänyt siten rikkinäiseksi. Päätin lähettää näiden kaikkien sivujen ylläpitäjille sähköpostia.
Kerroin sähköpostissa mahdollisimman lyhyesti ja ytimekkäästi, että sivulla x on tämän ja tämän niminen linkki sivulle y, jonka osoite on muuttunut sivuksi z. Kehoitin meilissä ystävälliseen sävyyn päivittämään rikkinäisen linkin ja kiitin samalla linkityksestä.
Tämä toimi yhtä poikkeusta lukuunottamatta varsin hyvin, melkein kaikki ylläpitäjät päivittivät linkkinsä vähintään parin viikon viiveellä sähköpostin lähettämisestä. Osa jopa meilasi takaisin ja kiitti huomautuksesta.
Nyt olin tiettävästi tehnyt melkein kaiken mitä osasin minimoidakseni 404-virheilmoitukset. Melkein.
Monet hakurobotit käyttävät etsintänsä apuna sivuston juurelle asetettavaa robots.txt -tiedostoa. Tällä tiedostolla voidaan (periaatteessa) estää hakurobotteja indeksoimasta tiettyjä sivuja tai sivuston tiettyjä osia. Samaten itse html-sivun head-osioon voi asettaa meta-tagi, jolla voidaan (yrittää) estää tiettyjä sivuja indeksoitumasta.
Tässä nimenomaisessa tapauksessa ongelmat kuitenkin johtuvat sellaisista sivuista, joita ei enää ole, tai jotka on nimetty uudelleen tai siirretty toiseen paikkaan. Fiksu webmaster ei ensinnäkään koskaan muuta sivun URLia, mutta nyt kun vahinko oli ehtinyt jo tapahtua, oli hyvä kun oli mahdollisuus käyttää web-palvelimen palvelimen omia tekniikoita uudelleenohjaukseen.
Apache www-palvelimen voi konfiguroida mm. ohjaamaan muuttunut sivu automaattisesti uuteen osoitteeseen ja palauttamaan tapahtuman päätteeksi 410-koodi, eli "Siirretty pysyvästi". Selaaja ei tätä siirtoa huomaa kuin osoitteen muuttumisena selaimen osoitepalkissa ja fiksu hakurobotti ymmärtää päivittää uuden osoitteen vanhan rikkinäisen tilalle. Tämä olisi ihanneratkaisu kunhan robotit vaan toimisivat käytännössä yhtä hienosti.
Kunnollinen 404-sivu on hyvin tärkeä osa sivustoa. Sivulla tulisi kertoa käyttäjälle selkeästi ja yksiselitteisesti, että tämän tavoittelemaa sivua ei syystä tai toisesta löydy. Pahin mahdollinen tapa on kertoa käyttäjälle pelkästään virheilmoituksen numero (404) tai jotain muuta vastaavaa teknistä informaatiota, jolla tavallinen käyttäjä ei tee yhtään mitään.
Unessa.netin 404-sivulla kerrotaan lyhyen tilanneraportin (hakemaasi sivua ei löydy palvelimelta) lisäksi mistä tämä saattaa johtua (sivu on siirretty tai poistettu, kirjoitusvirhe linkissä) ja miten tavoitellun sivun voisi kenties löytää (tarkosta mahdolliset kirjoitusvirheet ja ääkköset osoitteesta). Sivulle on vielä liitetty hakukoneen lomake ja kehoitus yrittää etsiä haluttua tietoa hakukoneella tai sivuston etusivulta (jonne myös tarjotaan selkeä linkki). Viimeiseksi käyttäjää voidaan opastaa lähettämään sähköpostia sivuista vastaavalle (pelkkä mailto-linkki riittää). Tällainen virheilmoitussivu yrittää palvella käyttäjää epäonnistuneesta palvelutilanteesta huolimatta ja parhaassa tapauksessa se saattaa auttaa käyttäjää ratkaisemaan kohtaamansa ongelman.
Tämä kaksi kuukautta kestänyt projekti oli monellakin tapaa hyödyllinen. Pääsin tavoitteeseeni, eli pienensin sivustolle kohdistuvien 404-virheilmoitusten määrää ratkaisevasti, murto-osaan lähtötilanteesta. Projekti opetti myös paljon muuta.
Havaitsin tämän kahden kuukauden tarkkailujakson aikana mielenkiintoisen ilmiön. Tietyistä ip-osoitteista lähetetään enemmän tai vähemmän säännöllisesti hakuja /cgi-bin/formmail.pl -tiedostoon. Haut varioivat tiedoston nimeä (FormMail.pl, FormMail.cgi, formmail.cgi) ja epäilemättä näillä yritetään etsiä avoimia skriptejä spämmäykseen. Kannattaa siis olla tarkkana omien formmail-skriptien kanssa!
Verrattuna alkutilanteeseen, nykyinen tilanne näyttää erittäin hyvältä. Arvioin projektin alussa ns. luonnollisen minimin olevan noin kymmenen promillen luokkaa (404 per sivulataus), mutta tämäkin arvo alittui helmikuun aikana. Todellisuudessa luonnollinen 404-virheilmoitusten määrä saattaisi siis olla luokkaa 0,07-0,09 % (404/Sivulataus).
| Kuukausi | Kävijöitä | Sivulatauksia | 404 -virheitä | 404 -virheitä päivässä |
| Marraskuu 2002 | 18151 | 316347 | 2255 | 75,17 |
| Joulukuu 2002 | 17049 | 280489 | 2122 | 68,45 |
| Tammikuu 2003 | 20522 | 327242 | 673 | 21,71 |
| Helmikuu 2003 | 19425 | 302339 | 276 | 9,86 |
Nyt tuntuu hyvältä. Projekti oli menestys. Erityisesti kehittelemäni 404-Automaagi on osoittautunut loistavaksi välineeksi sivuston fiksailuun. Sivuston lukijat hyötyvät lopputuloksesta eniten. Todennäköisyys törmätä rikkinäiseen sisäiseen linkkiin on nyt todella pieni ja ajan mittaan tämä todennäköisyys toivottavasti vain pienenee.
Kerro mielipiteesi tästä sivusta!
|
|
vaihtoehtoinen helvetti |