Sivustouudistukseen liittyy usein tiettyjä sudenkuoppia. Seuraavassa lyhyt ohjeistus sivustouudistuksen perusasioihin.
Google:lle ja hakukoneille URL -osoite esim. www.domain.fi/artikkelit/joku-alasivu/ on avain www-dokumenttiin. Usein kun alla oleva julkaisujärjestelmä vaihtuu niin www-osoitteet muuttuvat samalla esim. muotoon www.domain.com/palvelut/joku-alasivu/. Nyt syntyy tilanne, jossa vanha osoite ei enää toimi. Google katsoo, että sivu on poistunut eikä osaa sitä ilman apua yhdistää uuteen vastaavan sivuun. Tätä ongelmaa varten on olemassa HTTP 301 -uudelleenohjaus. Siinä vanha osoite pysyy toiminnassa, mutta se ohjaa käyttäjän/indeksointirobotin automaattisesti oikealle sivulle. Näin dokumentti ja sen hyvä historia (statistiikka) säilyy, vaikka osoite muuttuukin ts. Google-sijoitukset säilyy.
Tämä pätee myös domainiin eli jos https://domain.fi muuttuukin muotoon https://www.domain.fi. Googlen silmissä tämä on täysin uusi domain ja tarvitaan 301 -uudelleenohjauksen lisäksi merkintä Google Search Console -työkaluun, jotta Google osaa huomioida domainin muutoksen.
Julkaisujärjestelmistä esimerkiksi Wordpress, Joomla ja Concrete5 jne. tarjoavat paljon lisäosia, jotka hoitavat työn helposti.
Nykyisin www-sivustot sisältävät valtavat määrät Javascript- ja CSS(tyyli)-tiedostoja, raskaita kuvatiedostoja ja videoita.
Useat tiedostot ladataan sivun alkuosassa. Tämä johtaa ongelmaan, jossa sivu piirtyy käyttäjän selaimeen hitaasti. Saattaa kulua jopa useita sekunteja
ennen kuin sivu on luettavissa käyttäjän selaimessa. Googlen hakualgoritmi rankaisee hitaita sivustoja.
Ks. työkalu Page Speed Insights ›
Hyvä nopeus on yli 75/100. Lähelle 100/100 on vaikea päästä, koska joitain seurantaskriptejä pitää ladata sivun alkuosassa (jotta sivusto toimii oikein) joka puolestaan hidastaa sivustoa. Hyvällä suunnittelulla pääsee kuitenkin nopeuteen 90/100. Sivuston suunnittelijan pitää ottaa nopeus huomioon heti kun sivustoa lähdetään suunnittelemaan. Jälkikäteen ei yleensä saada yhtä hyviä tuloksia.
Vaikka raskaistakin sivuista voidaan saada teknisten mittareiden näkökulmasta nopeita niin ne ovat silti raskaita ja näin niiden sivulataus on hidas.
Hyvän www-sivun koko on alle 700 kb. Tietenkin jos paljon esimerkiksi kuvia voidaan mennä jopa 3 Mb.
Lue lisää nopeudesta ›
Huomattava määrä www-selailua tehdään mobiililaitteilla ja määrä kasvaa vaan koko ajan. Googlen sijoitusindeksointi
on ns. mobile first. Eli mobiiliystävälliset sivustot menestyvät paremmin. Lue lisää ›
”Mobile-first indexing means Google will predominantly use the mobile version of the content for indexing and ranking.”
(developers.google.com)
Tämä on asia, jonka kanssa joutuu usein ”painimaan” järjestelmäsuunnittelijoiden kanssa. Google haluaa, että kaikkien indeksointiin tarvittavien tiedostojen
indeksointi on sallittu. Näin siksi, että sivu voi näyttää joltain, vaikka Javascript- ja CSS-tiedostojen indeksointi on kielletty, mutta indeksoinnin kielto estää
täydellisen sivun indeksoinnin ja tämä on vastoin Googlen suosituksia.
Lue lisää ›
” For optimal rendering and indexing, always allow Googlebot access to the JavaScript, CSS, and image files used by your website so that Googlebot can see your site like an average user.”
(developers.google.com)
Tietenkin sivun esim. ./intra/ tms. indeksointi voidaan kieltää.
Analytiikka perustuu pitkälti oikeastaan kahden työkalun yhteistoimintaan ja nämä ovat Google Analytics ja Google Tag Manager. Google Analytics mittaa ja Google Tag Manager määrittelee mitä ja miten mitataan. Suosittelen asettamaan kaikille call-to-action -elementeille yksilöllisen id-attribuutin. Tämä tekee analytiikan määrittämisestä merkittävästi helpompaa, kun kaikki tärkeät elementit on yksilöity. Call-to-action -elementtejä ovat esimerkiksi lomakkeet, buttonit, yhteystiedot-linkki jne. On myös huomioitava, että HTML-dokumentissä voi yksittäinen id-attribuutti esiintyä vain kerran eli se on aina uniikki. Muussa tapauksessa analytiikka voi toimia virheellisesti ja lisäksi toistuva id-attribuutti on HTML-standardivirhe.
Hakukoneet (Google) suosivat oikeaoppisesti tehtyjä sivuja. Käytännössä tämä tarkoittaa, että sivun lähdekoodi on HTML-standardin mukaista.
Vaikka sivu toimisikin oikein saattaa koodi sisältää silti paljon virheitä. Selaimet osaavat korjata näitä virheitä. Selaimia on kuitenkin paljon ja niistä useita eri versioita
erilaisilla päätelaitteilla. Jos HTML-koodissa on paljon virheitä niin hakukone ei voi enää luottaa siihen, että k.o sivu toimii oikein, koska siinä on niin paljon koodivirheitä.
Suositan siis tarkistamaan HTML-koodin oikeellisuuden, laadukas koodi on positiivinen signaali hakukoneille ja Googlelle.
W3C-validator ›
Yleensä julkaisujärjestelmäksi valitaan Wordpress-julkaisujärjestelmä. Wordpress hyvillä ja luotettavilla ja hyväksi todetuilla lisäosilla on järkevä, turvallinen ja perusteltu valinta.
Wordpress on maailman suosituin sisällönhallintajärjestelmä. Koska se on suosittu, niin sitä myös yritetään murtaa eniten - päivitysten ja tietoturvan pitää olla siis kunnossa. Toinen ongelma on Wordpress-toteutukseen liittyvä: Osa Wordpress-kehittäjistä suosii suurta määrää Wordpress-plugineita eli lisäosia. Suuri määrä lisäosia tarkoittaa suurta määrää ohjelmistokoodia, joka taas puolestaan saattaa aiheuttaa sen, että järjestelmästä tulee epävakaa. Usein onkin niin, että tietyt lisäosat eivät ole keskenään yhteensopivia, tai vaikka ne alkutilanteessa olisivatkin, niin päivityksen jälkeen ne saattavat aiheuttaa virhetilanteen ja näin koko sivusto ei enää toimi.
Tietoturvan kannalta hosting näyttelee tärkeää osaa. Hosting-toimittajalla pitää olla seuraavat asiat kunnossa:
Käytetään sellaisia lisäosia, jotka ovat yhteensopivia, suosittuja ja niitä edelleen kehitetään. Mielestäni Wordpress:ssä saisi olla maksimissaan noin 12 lisäosaa (tapauskohtainen). Aivan muutamallakin pärjää.
Muutamia lisäosasuosituksia – ei tarvitse käyttää juuri näitä, mutta samankaltaisia ja yhtä suosittuja.
Yleensä yrityksen toimiala ei ole tieto- ja viestintäteknologiassa. Yritys tarvitsee vain luotettavat ja hyvin toimivat sekä yleiskäyttöiset kotisivut. Ei ole järkevää valita julkaisujärjestelmäksi ns. ei-mainstream -ratkaisua. Wordpress on aika varma valinta. Wordpress-kehittäjiä on hyvin tarjolla, ja monet ihmiset osaavat käyttää jo lähtökohtaisesti Wordpressiä. Jos valittaisiin jokin tuntemattomampi ratkaisu julkaisujärjestelmäksi, niin silloin seuraisi seuraavia haasteita: ratkaisu on yleensä sidottu yhteen toimittajayritykseen, julkaisujärjestelmän käytössä pitää olla uudelle henkilölle aina uusi käyttöönottokoulutus ja yhteensopivuus muihin järjestelmiin on heikompi.
Moni pieni yritys tai yhteisö voi pärjätä aivan hyvin Wordpressiä kevyemmillä ratkaisuilla kuten esim. wix.com tai webnode.fi.
Wordpress saattaa olla haasteellinen sisällönhallintaratkaisu, jos yritys tai organisaatio on hyvin suuri. Yksinkertaisesti ylläpitäjien lukumäärä, erilaisten ulkoasuelementtien hallinta ja ohjelmistointegraatiot ulkopuolisiin järjestelmiin aiheuttavat Wordpress-ratkaisulle haasteita. Tällöin hyviä vaihtoehtoja voisivat olla avoimen lähdekoodin Concrete5 tai kotimainen Stato-julkaisujärjestelmä.
Aloitetaanko yhteistyö? Pyydä tarjous sivustosi tuottavuuden parantamisesta.
Primus72 Oy - 2467174-9 / FI24671749
hannu@primus72.com
+358-(0)45-1677117