Itse en pidä “täydellistä” url-skeemaa mitenkään erityisen kriittisenä juttuna. Tärkeintä on, että url-malliin voi vaikuttaa ja järjestelmä saadaan konfiguroitua siten, että vaikka id-numerot olisivat ensisijainen tunnistustapa, niin osoitteisiin saataisiin mukaan myös sisältöä selkokielisesti kuvaavat metasanat.

Esimerkiksi tämäntyyppisen url-skeeman saa useimpiin järjestelmiin:
 http://www.delta.fi/Etusivu/Ajankohtaista/DavidHermanistaDeltanhallituksenpuheenjohtaja/tabid/1383/Default.aspx

Tuota voisi parantaa vielä lisäämällä sanojen erottelemiseksi viivat ja karsimalla turhat tasot jolloin saataisiin jotain seuraavaa:

http://www.delta.fi/Ajankohtaista/David-Hermanista-Deltan-hallituksen-puheenjohtaja/tabid/1383/Default.aspx

Kauniimpaakin jälkeä voisi tietysti tehdä, mutta ainakin jos kyse on järjestelmän jatkokehittämisestä, niin enemmän saa varmasti aikaan panostamalla sisältöasioihin, linkityksiin ym. kuin siihen että polttaa rahaa julkaisujärjestelmän url-osoitemallin muokkaamiseen. (Esimerkiksi tuossa käytetyssä esimerkissä kannattaisi tehdä mahdollisuus määritellä sisällöille kanoniset url-osoitteet jolloin Google ei indeksoisi tuplasisältöä niin herkästi.)

Uudistuksessa joutuu sitäpaitsi aina tekemään 301 uudelleenohjauksia massiivisen määrän, niin loppujen lopuksi “ikuisilla” osoitteilla ei ole niin älyttömästi arvoa käytännön elämässä.

Mutta totta turiset noiden Notes-saittien url-systeemien kauheudesta. Esim. case Metson About Us -sivu:
 http://www.metso.com/corporation/about_eng.nsf/WebWID/WTB-041026-2256F-55957?OpenDocument

Tuohon verrattuna SharePoint 2007 tuottaa suorastaan elegantteja url-osoitteita:
 http://www.eon.fi/fi/asiakaspalvelu/sahko/Sivut/S-bonusta.aspx

Tämä laittoi kulmakarvani kohoamaan useamman sentin. Itse olen ollut tekemisissä jonkin verran Notes-pohjaisten järjetelmien kanssa, ja siellä en ole vielä nähnyt ratkaisua, jolla sivuille saataisiin selkokieliset url:t. Vähintäänkin sovelluksen nimi (sovellus.nsf) jää kummittelemaan url:iin.

Jos joku on joskus kuullut ratkaisusta Notes-puolen url:heihin, niin kuulen siitä enemmän kuin mielelläni.

a) päivittäjiä jota eivät ymmärrä optimoinnista mitään
b) päivittäjiä jotka ymmärtävät, mutta eivät osaa koodata
c) SEO-ammattilaisia.

Mitä laajempi sivusto ja isompi firma, sitä enemmän meillä on a) –tyypin käyttäjiä ja sitä tärkeämpi on julkaisujärjestelmän tekemä automaattinen optimointi.

Olemme omassa julkaisujärjestelmässämme yrittäneet ottaa huomioon näitä kaikkia käyttäjätyyppejä, painopiste kuitenkin a) ja b) -päivittäjissä. Tässä nyt muutama ”ominaisuus” jotka edesauttaa hakukonelöydettävyyttä:

1) Automaattinen Title, joka voidaan päivittää manuaalisesti
2) Automaattinen URLien selkokielistäminen, mikä voidaan asettaa myös manuaalisesti
3) Sivukohtaiset metatiedot
4) Oikeiden sisältöelementtien (H1…) pakotettu käyttö
5) Kuvien ja linkkien alt / title –arvot
6) Automaattinen Google XML -sivukartta
7) Oletuskieli aina suoraan domainin alla (ei esim /fi/)
8) Jokaisella sivulla vain yksi urli (ei http://www.yritys.com ja http://www.yritys.com/etusivu)

Sinänsä ihan basic-juttuja, mutta nostaa asiakkaidemme sijoituksia hämmästyttävän hyvin hakutuloksissa, eikä SEO -ammattilaiset kauheasti ole valittanut julkkarin asettamista rajoituksista. Lassen toivomaa julkkaria, jossa lähdekoodi on täysin vapaa sanotaan meillä ”notepadiksi” …

Mutta, kuten kaikki tiedämme, sisältö on kaiken hakukonenäkyvyyden perusta ja olen Pertun kanssa täysin samaa mieltä, että olisi mahtavaa jos julkaisujärjestelmä tukisi myös sisällön arvioimista ja kehittämistä. Odotan kärsimättömänä kävijäseurantojen uusia rajapintoja, jotka toivon mukaan mahdollistavat tämän.

Toimittajaehdokkaalta voi myös kysyä, että mitä heidän mielestään “hakukoneyhteensopivuus” heidän mielestään tarkoittaa ja löytyykö nimenomaan referenssejä missä hakukoneoptimointia olisi tehty ja millä avainsanoilla.

Sanoisin, että hieman on vähätelty tässä artikkelissa julkaisujärjestelmän teknisiä ominaisuuksia hakukoneoptimoinnin mahdollistajana. Oma esitykseni aiheesta on vapaasti nähtävissä blogissani.

Olen kyllä täsmälleen samaa mieltä, että hakukoneoptimointia pitää tehdä säännöllisesti, kuten myös sivuston sisällön ja tavoitteiden mittaamista. Hakukoneoptimointi sisällön tuottajan kannalta ei ole rakettitiedettä ja oikeanlaisella koulutuksella siihen oppiii kuka tahansa.

Perusväittämän suhteen olen hieman siis eri mieltä: huonolla julkaisujärjestelmävalinnalla voi hakukoneoptimointityöstä saada hankalaa, joissakin tapauksissa jopa mahdotonta! Järjestelmävalinnan kriteereihin voinee siis helposti lisätä esim. avoimen lähdekoodin ja hakukoneoptimointiin vaikuttavat asiat. Mutta kuinka moni yritys oikeasti listaa ja pisteyttää järjestelmä- sekä toimittajavaatimukset?

Hakukoneystävällinen koodi on toki hyvä perusta hakukoneoptimointiprosessile, mutta usein kun halutaan saada aikaan loistavia tuloksia yksittäisillä sivuilla ne julkkarin perusratkaisut ovat enemmän tiellä kuin hyödyksi. Tällöin vapaat kädet lähdekoodiin helpottavat hakukoneoptimointia kummasti.

Drupal kuuluu itselläni inhokkilistalle sen karmean käytettävyyden takia.