Verkkosivustolla voi olla kaunis ulkoasu ja SEO-lisäosan vihreä ympyrä, ja silti se voi menettää kävijöitä ennen kuin pääsisältö on edes latautunut. Tai Google voi indeksoida eri URL-osoitteen kuin odotat. Tai tilaus voi toimia, mutta mittaus lähettää sen kahdesti.
Siksi en aloita teknistä auditointia jahtaamalla sadan pisteen tulosta yhdessä testissä. Ensin etsin virheitä, jotka estävät liiketoimintaa, indeksointia tai verkkosivuston käyttöä. Vasta sen jälkeen viimeistelen pienet yksityiskohdat.
1. Varmista, että tärkeät URL-osoitteet palauttavat oikean tilan
Käy läpi tärkeimmät palvelusivut, liikennettä saavat artikkelit, yhteydenottosivu ja konversiopolku. Tärkeän sivun pitäisi palauttaa 200. Pysyvästi siirretyllä sisällöllä pitäisi olla yksi suora 301-uudelleenohjaus. Poistetun sivun ei pitäisi päätyä hiljaa etusivulle.
Tarkistan myös HTTP- ja HTTPS-versiot, www- ja ei-www-versiot, lopun vinoviivat sekä parametrit. Tuloksen pitäisi olla yksi kanoninen URL-osoite. Google kuvaa uudelleenohjausta vahvaksi kanonisointisignaaliksi ja suosittelee yhdistämään sen johdonmukaiseen canonical-määritteeseen ja sivustokarttaan kanonisia URL-osoitteita käsittelevässä dokumentaatiossaan.
2. Tarkista indeksointi oikean sivun näkökulmasta
Robots.txt, meta robots, canonical ja sivustokartta toimivat yhdessä. Yleinen virhe on indeksoida sivu, jolla ei ole paikkaa haussa, samalla kun tärkeää sisältöä estetään. Käytä Search Consolen URL-tarkastusta useilla edustavilla URL-osoitteilla. Se näyttää, mitä Google tietää sivusta, ja antaa testata aktiivista versiota.
- Onko kanoninen URL-osoite haluamasi?
- Onko sivu käytettävissä ilman kirjautumista tai estettä?
- Sisältääkö sivustokartta vain indeksoitavia 200 URL-osoitteita?
- Välttävätkö sisäiset linkit uudelleenohjauksia?
- Ovatko tärkeät sivut irrallisia?
Google ylläpitää näistä alueista yleiskatsausta indeksointia ja ryömintää käsittelevässä dokumentaatiossaan.
3. Mittaa nopeutta ihmisillä, ei vain laboratoriossa
PageSpeed Insights ja Lighthouse ovat hyödyllisiä diagnostiikkatyökaluja. Laboratoriotesti ei kuitenkaan ole sama asia kuin oikeiden kävijöiden kokemus. Nykyiset Core Web Vitals -mittarit ovat LCP, INP ja CLS; kenttädata perustuu oikeisiin laitteisiin ja yhteyksiin. Virallinen Web Vitals -dokumentaatio selittää yleiskatsauksen sekä kenttä- ja laboratoriotiedon eron.
Tarkastelisin prioriteetteja näin:
- LCP: milloin pääsisältö näkyy.
- INP: kuinka nopeasti sivu reagoi käyttöön.
- CLS: hyppivätkö elementit latauksen aikana.
- TTFB ja verkko: alkaako mikään tapahtua nopeasti.
Google sanoo myös suoraan, ettei hyvä tulos takaa kärkisijoituksia. Käytön kokonaislaatu on tärkeämpää kuin yhden numeron jahtaaminen. Katso sivukokemusta käsittelevä dokumentaatio.
4. Etsi latauksen todellinen syyllinen
Etsi waterfall-näkymästä ja DevToolsista pitkää palvelinaikaa, estävää CSS:ää ja JavaScriptiä, liian suuria kuvia, fontteja, toistuvia pyyntöjä ja kolmansia osapuolia. Vanha sääntö ”yhdistä kaikki tiedostot” ei enää päde kaikkialla. Nykyaikaisilla protokollilla käyttämättömän koodin määrä ja pääsäikeen estäminen voivat olla tärkeämpiä.
- Lataa pääkuva sopivan kokoisena ja nykyaikaisessa muodossa.
- Määritä kuville mitat, jotta ne eivät siirrä sisältöä.
- Ensimmäisen näkymän alapuolinen sisältö voi käyttää selaimen natiivista laiskaa latausta.
- Lataa vain tarvittavat fontin leikkaukset ja merkistöt.
- Lataa markkinointiskriptit asynkronisesti ja vain siellä, missä niillä on tarkoitus.
- Pakkaa tekstiresurssit ja määritä versioiduille tiedostoille pitkä välimuisti.
Kolmas osapuoli maksaa muutakin kuin millisekunteja. Jokainen pikseli, chat-widget ja lämpökartta lisää operatiivista ja datan hallintaan liittyvää vastuuta. Jos kukaan ei käytä raporttia, poista skripti.
5. Käy verkkosivusto läpi asiakkaan tavoin näppäimistöllä ja puhelimella
Käy mobiilissa läpi navigointi, lomake, evästedialogi ja tilaus. Suurenna tekstiä, poista kuvat käytöstä ja käytä näppäimistöä. Otsikoiden pitäisi muodostaa ymmärrettävä rakenne, lomake tarvitsee kenttien nimet ja virheilmoituksen pitää kertoa, mitä korjataan.
Jokaisella sivulla pitäisi olla yksi päätehtävä. Se ei tarkoita yhtä painiketta hinnalla millä hyvänsä, vaan selkeää hierarkiaa. Löydät lisää käytännön kohtia UX:n perustarkistuslistasta.
6. Korjaa resurssi- ja JavaScript-virheet
404 kuvavirhe, fonttivirhe tai skriptivirhe ei ole kosmeettinen. Se voi rikkoa ulkoasun, mittauksen tai toiminnallisuuden. Tarkista selaimen konsolin virheet, epäonnistuneet verkkopyynnöt ja toistuvat 5xx-vastaukset palvelimella. Testaa kriittiset polut jokaisen julkaisun jälkeen.
7. Käytä jäsenneltyä dataa vain totuudenmukaiseen sisältöön
Schema ei ole keino pakottaa tähtiarvosteluja. Se on koneellisesti luettava kuvaus siitä, mitä sivulla oikeasti on. Käytä tuettua tyyppiä ja testaa se Rich Results Testissä. Google listaa nykyiset tuetut muodot ja testaustyökalut jäsenneltyä dataa käsittelevässä dokumentaatiossaan.
8. Mittaus ei saa rikkoa verkkosivustoa, jota sen on tarkoitus mitata
Lataa GA4, mainosalustat ja muut skriptit estämättömällä tavalla. Nimeä tapahtumat päätösten, ei jokaisen klikkauksen, mukaan. Tarkista duplikaatit, suostumus ja se, käyttääkö kukaan dataa oikeasti. Löydät käytännön perustan artikkeleista, jotka käsittelevät Google Tag Manageria ja Google Analyticsia 4.
9. Raha ja riski määrittävät korjausten järjestyksen
- Rikkinäinen tilaus, lomake tai kirjautuminen.
- Tärkeä sivu, joka ei ole käytettävissä tai indeksoitavissa.
- Tietoturvaongelma ja vanhentuneet komponentit.
- Merkittävät mobiilikäytettävyyden ja Core Web Vitals -ongelmat.
- Mittausvirheet, jotka johtavat huonoihin päätöksiin.
- Vasta sitten pienet piste- ja kosmeettiset ongelmat.
Tekninen SEO on lähtöviiva. Se ei voita kilpailua yksin, mutta rikkinäinen verkkosivusto voi hävitä ennen lähtölaukausta. Jos haluat muuttaa tekniset havainnot liiketoiminnan prioriteeteiksi, voit kuvata verkkosivuston ja päätöksen, jonka kanssa työskentelet.