Sivustouudistus - vältä nämä virheet ja onnistut

Sivustouudistukseen liittyy usein tiettyjä sudenkuoppia. Seuraavassa lyhyt ohjeistus sivustouudistuksen perusasioihin.

301 -uudelleenohjaus

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.

Nopeus

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.

Ei liian raskaita sivuja

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 ›

Mobiiliystävällisyys

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)

Sallikaa indeksointi

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ää.

Call-to-action id-attribuutit

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.

HTML-standardi

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 ›

Sananen Wordpress-julkaisujärjestelmästä

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 -uhat

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.

Wordpress-suosituksia

Tietoturvan kannalta hosting näyttelee tärkeää osaa. Hosting-toimittajalla pitää olla seuraavat asiat kunnossa:

  • Wordpress ja sen lisäosat päivitetään hallitusti esim. 1-3 kuukauden välin, jolloin Wordpress-järjestelmä on aina teknisesti ns. tip-top kunnossa.
  • Säännölliset backupit sivustosta joka päivä 14 vrk taaksepäin. Virhetilanteessa otetaan backup käyttöön.
  • Backupin palauttaminen pitää olla toimenpiteenä ns. muutama klikki, eli ei esim. raskasta tietokantojen kopiointiprosessia.
  • Cloudflaren tai vai vastaavan käyttö on suositeltavaa ks. Cloudflare ›

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.

  • Sivueditori: Elementor. Lisäosalla voi siis luoda esim. halutun kaltaisen alasivun ks. Elementor-plugin. Elementor -sivueditori (page builder) on maailman suosituin ja saanut erittäin hyvät arvostelut Wordpress-kehittäjien ja -käyttäjien keskuudessa.
  • SEO Yoast tai All in one SEO ks. SEO Yoast -työkalu helpottaa hakukoneoptimoinnin perusasioissa.
  • Contact Form 7 eli lomake-editori tai vastaava.
  • Cache esim. Litespeed eli välimuistin hallinta.
  • Kuvien optimointi esim. Shortpixel.
  • Sopiva tietoturva-plugin esim. Wordfence tai vastaava.
  • ACF Avanced Custom Fields ns. aputietokanta on hyvä olla (ehkä) olemassa.
  • 301 redirects plugin tai vastaava. Hoitaa sivujen uudelleenohjauksen.
  • Monster Insights -analytiikka.
  • Google Search Console -integraatio.

Lopuksi

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.

Hyvin pienet sivustot

Moni pieni yritys tai yhteisö voi pärjätä aivan hyvin Wordpressiä kevyemmillä ratkaisuilla kuten esim. wix.com tai webnode.fi.

Hyvin suuret sivustot

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ä.

Tehdään sivustostasi tuottavampi - Ole yhteydessä

Aloitetaanko yhteistyö? Pyydä tarjous sivustosi tuottavuuden parantamisesta.

Primus72 Oy - 2467174-9 / FI24671749

hannu@primus72.com

+358-(0)45-1677117

Viestisi on lähetetty! Olen yhteydessä sinuun mahdollisimman pian!