Mitä julkaisujärjestelmältä tulee vaatia parhaan hakukonenäkyvyyden saamiseksi?
Otathan huomioon, että tämä artikkeli on yli 16 vuotta vanha, joten sisältö ja linkit eivät ole välttämättä ihan ajan tasalla. Tuoreena lukemisena samasta kategoriasta: Verkkosivut ja tekoäly - mikä muuttuu?.
Vierityspalkin julkaisujärjestelmän valinta -artikkelisarjassa käsitellään vaatimuksia ja toimintoja, joita kannattaa sivustonsa sisällönhallinnalta edellyttää.
Artikkelin lähtökohtana on se todellisuus, että lähes kaikki suuret verkkopalvelut elävät ja kuolevat jonkun sisällönhallintajärjestelmän avulla. Sisällönhallintajärjestelmät ovat tärkeässä roolissa aina kun kyseessä on kehitystyö jolla on sisällöllisiä ja teknisiä ulottuvuuksia. Hakukoneoptimointi on juuri tällainen ulottuvuus jossa yhdistyy sisältö ja teknologia.
Hakukoneoptimoinnin ja julkaisujärjestelmien suhdetta pidetään usein monimutkaisena ja moni julkaisujärjestelmätoimittaja mainostaa omaa tuotettaan hyvällä “hakukoneyhteensopivuudella”. Tämän mainoslauseen todenperäisyys päätettiin kyseenalaistaa. Tukena kirjoituksessa on ollut Vierityspalkin tekninen asiantuntija Aki Björklund.
Alkuperäisen kysymyksen voisi muotoilla myös, että “kuinka tärkeitä ovat julkaisujärjestelmän ominaisuudet hakukonenäkyvyyden kannalta?“. Vastauksen katsotaan tässä artikkelissa riippuvan siitä ovatko perusasiat julkaisujärjestelmässä kunnossa vai eivät. Julkaisujärjestelmän ominaisuudet voivat olla joko äärimmäisen olennaisia tai niillä ei ole lainkaan merkitystä. Huono sisällönhallintajärjestelmä tekee sisällön löydettävyyden ja indeksoinnin hakukoneille äärimmäisen vaikeaksi. Hyvällä järjestelmällä sisältö indeksoituu laadukkaasti ilman erikseen ostettavaa lisätyötä. Huonon ja hyvän järjestelmän välinen ero ei tässä tapauksessa ole kuitenkaan yleensä etukäteen tunnistettavissa.
Seuraavana esitetään top-3 asiakokonaisuudet jotka liittyvät sisällönhallintajärjestelmiin ja joilla on merkittävää vaikutusta verkkopalveluiden hakukonenäkyvyyteen.
1. Tärkein yksittäinen ominaisuus: Sisältöotsikoista muodostuvat automaattiset titlet ja mahdollisuus muokata titleä manuaalisesti
Monista hakukoneoptimointiin liittyvistä asioista kiistellään, mutta titlen vaikutusta sivun hakukonesijoitukseen ei vähättele kukaan. Hyvän titlen kirjoittaminen on ihan oma artikkelinsa, mutta pääasia on, että jokainen sisältösivu verkkopalvelussa saa oman, uniikin titlensä.
Nyrkkisääntönä on, että sivun pääotsikon tulisi aina muodostaa sivun title-elementti. Lisäksi titlessä voi olla sivustokohtaisia elementtejä, kuten aihepiirin nimi, kategorian nimi ja sivuston nimi. Muutokset sivun otsikkoon pitäisi myös heijastua sivun titleen. Esimerkiksi Plaza.fi-sivuston titlet ovat muotoa “Sivun otsikko + osion otsikko + sivuston nimi. Esimerkiksi “Onko uusi Max Payne –peli työn alla? – eDome – Plaza*“.
Lisäominaisuutena voi olla mahdollisuus määritellä title manuaalisesti ja ohittaa sisällön otsikosta automaattisesti muodostuva title. Esimerkiksi verkkopalvelun etusivun title ei saisi alkaa sanalla “Etusivu”. Myöskään “Palvelut” -sivun title ei kerro hakukonetuloksissa edes palveluiden aihepiiriä, joten title tulisi pystyä määrittelemään manuaalisesti esimerkiksi muotoon “Hakukoneoptimointipalvelut”. Tällöin hakukonetuloksissa näkyvä otsikko olisi esimerkiksi “Hakukoneoptimointipalvelut – Firma X”.
Hakukoneoptimoinnissa on myös usein tilanteita joissa title halutaan määritellä erilaiseksi kuin sivun varsinainen otsikko. Esimerkiksi matkatoimistot ovat havainneet tämän asian. Ihmiset googlettavat mielellään halpoja matkoja, mutta sivustolle saapuessaan ovat kiinnostuneita ainoastaan edullisista matkoista. Se mitä haemme ei välttämättä ole se mitä haluamme saada.
2. Tärkein kokonaisuus: Julkaisujärjestelmän teknisen käyttöönoton suunnitteluvaihe on tärkein, yksittäinen vaihe sivuston hakukoneoptimoinnissa
Suurimmat esteet hakukonenäkyvyydelle tehdään yleensä teknisen käyttöönoton (engl. implementation) vaiheessa. Järjestelmän asennuksessa ja konfiguroinnissa tehdään ratkaisuja jotka eivät ole löydettävyyden kannalta optimaalisia. Tyypillinen esimerkki tällaisesta ratkaisusta on URL-osoitejärjestelmän määrittely, eli millaisin säännöin järjestelmä muodostaa url-osoitteet. Esimerkiksi aikaisemmin käytetyn plaza.fi-artikkelin url-osoite on: “http://plaza.fi/edome/uutiset/onko-uusi-max-payne-peli-tyon-alla”. Käytännössä kaikki julkaisujärjestelmät saadaan taipumaan millaiseen URL-osoitejärjestelmään tahansa. Haluttu osoitemalli pitää vain määritellä ja koodata käyttöön samalla kun järjestelmä asennetaan.
Teknisen käyttöönoton vaiheeseen liittyy myös kysymys URL-osoitteiden “ikuisuudesta”. Esimerkiksi sivustoa uusittaessa tai tehtäessä muutoksia sivustoon pitäisi vanhat URL-osoitteet aina uudelleenohjata uusille sivuille. Hyvän verkkopalvelun osoitteistosta ei koskaan kuole osoitteita. Vaikka sisältöä poistettaisiin, niin nämä osoitteet tulisi ohjata sivulle jossa sisällön poistumisesta kerrotaan.
Moni järjestelmä myös sallii saman sisällön saavuttamisen usean eri osoitteen kautta ja tämä johtaa helposti tilanteeseen jossa samaan sisältöön linkitetään sivuston sisällä ja muualla verkossa eri osoitteilla. Tämänkin tilanteen estäminen tapahtuu teknisen käyttöönoton vaiheessa.
3. Tärkein jatkuvaan kehitykseen liittyvä asia: Sisällöntuottajien tukeminen optimoinnissa mittaustiedolla
Mahdollisesti tärkein yksittäinen asia hakukoneoptimoinnissa on se, että verkkopalvelu on elossa ja kehittyy koko ajan. Täten hakukoneoptimoinnin on oltava prosessimaista toimintaa ja työkalut tähän työhön pitäisi tarjota kaikille sisällöntuottajille. Mitä enemmän sisällöntuottajat pystyvät parantamaan omaa työskentelyään omatoimisesti, niin sitä paremmin verkkopalvelukin menestyy. Oli verkkopalvelun tavoitteena sitten saada enemmän kävijöitä, lisätä vietettyä aikaa sivustolla, tai saada enemmän liidejä tai kauppoja aikaiseksi, niin sisällöntuottajien tulisi itse nähdä mitkä toimenpiteet tuottavat eniten tulosta. Sisällöntuottajiksi rinnastettavia henkilöitä voivat tässä kohtaa olla myös esimerkiksi tuotepäälliköt, markkinointipäälliköt, myyntipäälliköt ja monet muut henkilöt jotka tuottavat verkkopalveluun uusia sisältökokonaisuuksia tai myytäviä tuotteita.
Sisällöntuottajien tulisi saada mahdollisimman täsmällistä tietoa siitä kuinka nimenomaan heidän tuottamansa sisältö menestyy. Esimerkiksi kävijämäärät, sivulla vietetty aika, tehdyt toiminnot, annetut arvioinnit, palautteet, kommentit pitäisi kaikki kertyä sisällöntuottajien näkyville sellaisessa muodossa, että kaiken tämän tiedon perusteella omaa työtä voi ohjata ja kehittää.
Käytännössä tämä tarkoittaa varsin laajaa näkökulmaa “julkaisujärjestelmään” ja siihen mitä kaikkea julkaisujärjestelmältä voi vaatia. Olennaista ei kuitenkaan ole, että onko mittausjärjestelmä integroitu täydellisesti julkaisujärjestelmään vaan että olennainen tieto saavuttaa myös sisällöntuottajat ja nämä tietävät kuinka tietoa voi tulkita. Käytäntö on vain osoittanut, että mitä lähempänä sisältöjä tiedot ovat, niin sitä enemmän luontaista, jatkuvaa kehitystä tapahtuu.
Yhteenveto: käyttöönottovaihe ja jatkuva kehitysprosessi ratkaisevat
Loppujen lopuksi keskustelu top-3 listasta päätyi siihen, että vain ensimmäinen asia (titlejen muodostus) liittyy aivan selkeästi julkaisujärjestelmän ominaisuuksiin. Toinen kohta (käyttöönottovaihe ja ennakkosuunnittelu) liittyy enemmän julkaisujärjestelmän tekniseen käyttöönottoon kuin julkaisujärjestelmän ominaisuuksiin. Käyttöönottovaiheen laadulta pitäisi siis vaatia paljon. Kolmas kohta taas liittyi mittaustiedon välittämiseen myös sisällöntuottajille. Tämäkin voidaan ratkaista muutoin kuin julkaisujärjestelmän ominaisuuksien avulla.
Top-10-lista tästä aiheesta olisikin sitten jo paljon vaikeampi ja listalle nousisivat monet varsin tekniset asiat, kuten sivukarttojen automaattinen muodostus, monipuoliset metatietojen hallintamahdollisuudet ja erilaisten sisältöjen vaatimat optimointimenetelmät. Epäilemättä moni haluaisi kontrolloida jopa sivuston indeksointia ja linkkien nofollow-attribuutteja. Näistä useimmat voidaan kuitenkin luokitella asioiksi, jotka vain tulee ottaa huomioon teknisessä käyttöönotossa eikä näiden toteutus täten liity olennaisesti julkaisujärjestelmien tarjoamiin perusominaisuuksiin. Julkaisujärjestelmiä on täten hyvin vaikea pitää valmiiksi “hakukoneoptimoituina”, koska hakukoneoptimoinnin kannalta isoimmat asiat eivät liity julkaisujärjestelmien sisältämiin ominaisuuksiin.
Loppujen lopuksi tärkeimmät julkaisujärjestelmään liittyvät hakukoneoptimointivaatimukset kohdistuvat julkaisujärjestelmän käyttöönottovaiheeseen ja käyttöönoton jälkeiseen prosessiin – eli siihen kuinka verkkopalvelua kehitetään ja kuinka kehitystä ohjataan.
Lue lisää: Digitaalinen markkinointi Suomessa – kaikki artikkelit Vierityspalkissa
(*Toim. huom. Linkkejä poistettu toimimattomina.)
PS. Aina ajantasaisen katsauksen julkaisujärjestelmien markkinaan löydät North Patrolin sivustolta: Julkaisujärjestelmät ja verkkokauppajärjestelmät -hakemisto
Perttu Tolvanen
Perttu on Vierityspalkin päätoimittaja ja kirjoittaja.
Perttu Tolvanen on digitaalisten palveluiden suunnittelun, arkkitehtuuriratkaisujen ja kumppanivalintojen asiantuntija. Perttu on konsulttiyhtiö North Patrol Oy:n konsultti ja toinen perustaja. North Patrol on digitoimistoista ja järjestelmätoimittajista riippumaton konsulttiyhtiö, joka suunnittelee digitaalisia palveluita ja auttaa asiakkaita onnistumaan uudistushankkeissaan. Ota yhteyttä Perttuun!
9 kommenttia on “Mitä julkaisujärjestelmältä tulee vaatia parhaan hakukonenäkyvyyden saamiseksi?”
Kommentointi on suljettu.
Lasse Larvanko
Kelpo pointteja hakukonenäkyvyyden varmentamiseksi julkaisujärjestelmässä.
Aktiivisella hakukoneoptimoijalle tärkein vaatimus julkaisujärjestelmässä on sen taipuminen vapaavalintaiseen lähdekoodiin. Julkaisujärjestelmän ei pitäisi teknisellä puolella ota kantaa mikä on julkaistavan sivuston lähdekoodi. Tämä pitää sisällään kaiken lähtien titleistä, urleista, miten otsikot merkataan ja mikä on sivuston lähdekoodin järjestys etc.
Artikkelissa rinnastetaan julkaisujärjestelmän hakukonenäkyvyys hakukoneoptimointiin. Hakukoneoptimointi on paljon laajempi kenttä kuin pelkästään sivuston tekninen toteutustapa ja sisältöä. Hakukoneoptimointiin toki kuuluu kyseiset asiat, mutta ne eivät vielä riitä.
Artikkelin lopussa asia kuitenkin kiteytyy aika hyvin:
”Julkaisujärjestelmiä on täten hyvin vaikea pitää valmiiksi “hakukoneoptimoituina”, koska hakukoneoptimoinnin kannalta isoimmat asiat eivät liity julkaisujärjestelmien sisältämiin ominaisuuksiin.”
Hienoa oli myös hakukoneoptimoinnin jatkuvan tarpeen esille tuominen. Olen melko usein törmännyt asiakkaan taholta sellaiseen mielikuvaan että hakukoneoptimointi on tekninen projekti, jonka voi yhdellä julkaisujärjestelmää muuttavalla teknisellä ratkaisulla poistaa päiväjärjestyksestä.
Parhaan tuloksen hakukoneoptimoinnissa saa kuitenkin tuloksia ja sijoituksia aktiivisesti seuraamalla ja niihin reagoimalla.
Kennu
Lasse, olen hiukan eri mieltä siitä, etteikö hyvä julkaisujärjestelmä ottaisi kantaa sivuston HTML:n rakenteeseen jne.
Annan case-esimerkiksi Drupalin. Se tuottaa oletuksena kohtalaisen siistiä ja loogista koodia. Tämän rakenteen päälle on hyvä ruveta rakentamaan oma osuutensa. Julkaisujärjestelmä toimiikin eräänlaisena frameworkkina, joka muodostaa sen mallin, jonka mukaan teemat ja moduulit oman HTML:nsä ja CSS:nsä muotoilevat.
Huom: Kaiken voi kyllä kustomoida jos haluaa, mutta oleellista on valmis toimintamalli, ettei tarvitse keksiä pyörää uudelleen.
Mielestäni HTML ja CSS ovat tulossa nyt siihen vaiheeseen, jossa ohjelmointi (ml. JavaScript) on ollut jo jonkin aikaa. Eli asioita rakennellaan valmiiden frameworkkien ja mallien varaan, eikä joka kerta puhtaalta pöydältä. Tällöin myös SEO-optimointi voi olla valmiiksi jo pitkälle huomioituna kyseisessä frameworkissa.
Juha Söderholm
Ongelma on siinä, että monet rinnastavat hakukoneoptimoinnin hakukoneystävälliseen toteutukseen, eli tässä menee törkeästi termit sekaisin. Suurin osa suomessa myytävästä “hakukoneoptimoinnista” onkin vain itseasiassa hakukoneystävällisyyden lisäämistä.
Drupal kuuluu itselläni inhokkilistalle sen karmean käytettävyyden takia.
Lasse Larvanko
Kennu: Jotenkin asetin oletuksen että julkaisujärjestelmä tuottaa kelvollista 2000-luvun koodia.
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.
Petri Mertanen
Väittäisin, että huonon ja hyvän julkaisujärjestelmän ero hakukonelöydettävyyden suhteen on helposti etukäteen tarkastettavissa. Toimittajalta pyydetään järjestelmällä toteutettuja referenssejä ja tarkistetaan esim. yksinkertaisella haulla “site:www.asiakasreferenssi.fi” kuinka sivusto löytyy hakukoneen indeksistä. Samalla voi helposti tarkastella missä muodossa sivuston otsikot eli titlet ovat.
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?
Sara H
Meidän pitää muistaa että julkaisujärjestelmällä on eri tyyppisiä käyttäjiä:
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 www-yritys-com ja 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.
Etuovi.com kaipaisi hakukoneoptimointia « Vierityspalkki.fi
[…] Vierityspalkin artikkelissa julkaisujärjestelmien ja hakukoneoptimoinnin suhteesta määriteltiin tärkeimmiksi asioiksi kuvaavat sivujen titlet ja julkaisujärjestelmän tekninen käyttöönotto. Tässä Etuoven esimerkissä korostuvat kummatkin näistä asioista. Ensinnäkin tilannetta auttaisi jos Etuoven sivuilla olisi järkevät titlet, koska tällöin kävijät edes tietäisivät mille sivuille tuloksista päätyvät. Järkevä title-systeemi olisi jo saattanut myös estää koko ongelman syntymisen. Toisena isona ongelmana Etuovella näyttää olevan julkaisujärjestelmä joka sallii hakutulosten indeksoimisen. Jo pelkästään dynaamisen sisällön indeksoinnin kontrolloinnilla esiintyvät ongelmat estettäisiin helposti. […]
Kimmo Huima
“Käytännössä kaikki julkaisujärjestelmät saadaan taipumaan millaiseen URL-osoitejärjestelmään tahansa. Haluttu osoitemalli pitää vain määritellä ja koodata käyttöön samalla kun järjestelmä asennetaan.”
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.
Perttu Tolvanen
Itsekin on tullut parin Notes-toteutuksen kanssa oltua tekemisissä, mutta ei koskaan aivan alkuvaiheissa joissa tuohon asiaan olisi todella voinut vaikuttaa. Joskushan tuollaiset asiat ovat tietysti harvinaisen tiukassa ja “konfigurointi” saattaa tarkoittaa järjestelmän puolittaista uusiksi koodaamista.
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: 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:
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: www-metso-com/corporation/about_eng.nsf/WebWID/WTB-041026-2256F-55957?OpenDocument
Tuohon verrattuna SharePoint 2007 tuottaa suorastaan elegantteja url-osoitteita: www-eon-fi/fi/asiakaspalvelu/sahko/Sivut/S-bonusta.aspx