Mobiili-SEO-auditointi 2026: Täydellinen opas

Google siirtyi mobile-first-indeksointiin 2018, ja 2026 mennessä se on ollut ainoa moodi yli viisi vuotta. Silti useimmissa toimistoissa SEO-auditit ajetaan yhä Lighthousen oletusasetuksilla, jotka suosivat nopeaa kannettavaa ja kuituyhteyttä. Raportti näyttää siistiltä, suositukset osuvat sivuun, ja asiakas miettii, miksi sijoitukset valuvat vaikka tekninen kunto on muka kunnossa.

Tämä opas korjaa tilanteen käytännönläheisesti. Käsitellään miksi mobiiliauditit hallitsevat vuonna 2026, mitä mobiiliauditissa on teknisesti eri tavalla, mobiilin Core Web Vitals -todellisuus, mitä mobiilikohtaisia ongelmia pitää löytää, 12 kohdan tarkistuslista, tärkeimmät työkalut, miten priorisoit korjaukset ja miten viestit löydökset asiakkaalle, joka ei ole tekninen.

---

Miksi mobiiliauditit hallitsevat vuonna 2026

Google on indeksoinut mobile-first jo vuodesta 2018 — 2026 mennessä se on ollut yli viisi vuotta ainoa toimintatapa. Crawleri, joka päättää sivuversion indeksissä, on mobiilicrawleri. Renderöity ulkoasu, joka tallennetaan, on mobiiliversio. Core Web Vitals -arvot, joita painotetaan, ovat mobiiliarvoja. Työpöytäversioon ei ole paluuta.

Käyttäjäkäyttäytyminen on seurannut perässä. Useimmilla kuluttajatoimialoilla mobiilin osuus orgaanisesta haustahausta on nyt 65 % tai enemmän, ja joillain aloilla — paikalliset palvelut, uutiset, viihde, edullisempi verkkokauppa — mobiili ohittaa 80 %. Työpöytä on yhä tärkeä B2B-tutkimukseen ja pitkän harkinnan ostoihin, mutta löytymishetki tapahtuu lähes aina puhelimella.

Liiketoiminnallinen vaikutus on suoraviivainen. Sivusto, joka latautuu 2,1 sekunnissa nopealla kannettavalla mutta 6,8 sekunnissa keskihintaisella Androidilla, on käytännössä hidas sivusto. Mobiilikokemus ratkaisee, jääkö kävijä, konvertoiko hän ja sijoittaako Google sivun niille hauille, joilla on väliä. Pelkkä työpöytäaudit on kuin tarkastaisi rakennuksen takaa eikä katsoisi sisäänkäyntiä lainkaan.

---

Mitä mobiiliauditissa on oikeasti eri tavalla

Mobiiliauditti ei ole pelkästään työpöytäauditti kapeammalla näkymällä. Erot kulkevat läpi koko teknologiapinon.

Throttlattu CPU

Lighthousen mobiilipreset hidastaa prosessoria noin 4-kertaisesti — simuloiden Moto G Power -luokan laitetta, joka on reilu kuvaus vuoden 2026 Android-mediaanista. JavaScript, joka jäsentyy 200 ms:ssa kehittäjän kannettavalla, voi viedä 1,5 sekuntia tällä laitteella. Hydraatio, joka lukitsee pääsäikeen 80 ms:ksi työpöydällä, lukitsee sen 400 ms:ksi mobiilissa. Jokaisella scriptipaketilla, polyfillilla ja analytiikkatagillä on kerroin.

Tämä on Suomessa erityisen merkityksellinen yksityiskohta. iPhonen markkinaosuus on Suomessa korkeampi kuin Euroopan keskiarvo, mutta Android-laitteita on yhä noin 35-40 % puhelimista, ja niiden mediaanihinta on selvästi Apple-laitteita matalampi. Käytännössä iso osa kävijöistä saapuu suorituskyvyltään 2-3 vuoden takaisella keskihintaisella Androidilla — eli juuri Moto G Power -luokassa.

Throttlattu 4G-verkko

Oletettu mobiiliverkkoprofiili olettaa tavallisen 4G-yhteyden — noin 1,6 Mbps alaspäin ja 150 ms edestakaista latenssia. Todelliset olosuhteet vaihtelevat, mutta profiili on tarkoituksella pessimistinen, jotta ongelmat, jotka katoavat gigabitin toimistolinjalla, näkyvät kovaan ääneen. Raskaat heroe-kuvat, suuret web-fontit ja vesiputouspyyntökuviot näkyvät tässä selvästi.

Näkymäerot

Suunnittelu 375 px leveälle näkymälle — iPhonen pitkäaikainen referenssi — pakottaa valintoihin, joita työpöytä ei koskaan vaadi. Sarakkeet romahtavat. Navigaatio piiloutuu hampurilaisen taakse. Heroteksti, joka näytti hyvältä 1440 px:ssä, katkeaa kömpelösti 375 px:ssä. Auditissa pitää testata, miten layout käyttäytyy 360, 375 ja 414 pikselin levyisenä, sillä kävijöitä tulee kaikilta kolmelta.

Kosketus vs hover

Mobiilissa ei ole hover-tilaa. Pudotusvalikko, joka aukeaa hoverissa, on rikki. Työkaluvinkki, joka näkyy hoverissa, on näkymätön. Mikä tahansa hiiren kursoria varten suunniteltu vuorovaikutus on parhaimmillaan kömpelö ja pahimmillaan saavuttamaton kosketusnäytöllä.

Kosketusalueiden vaatimukset

Googlen suositus on vähintään 44x44 CSS-pikselin kosketusalue, ja vähintään 8 px tilaa elementtien välissä. Nappi, joka on tätä pienempi, hylkää saavutettavuuden ja Lighthousen, ja luo aitoa turhautumista pienellä näytöllä. Yllättävän moni evästepalkki, footer-linkki ja sivutuskontrolli rikkoo tätä yhä.

Luettavuus pienillä fonttiko'oilla

Alle 16 px:n leipäteksti on vaikealukuista puhelimella. Monet teemat tarjoavat yhä 14 tai 15 px oletuksena, koska se näyttää tyylikkäältä Retina-kannettavalla. 375 px:n näkymässä se pakottaa kävijän zoomaamaan — ja zoomaus on signaali, että jokin on vialla.

---

Mobiilin Core Web Vitals: miksi pisteet ovat usein 25-35 pistettä työpöytää alempana

Jos olet koskaan ajanut saman URL:n PageSpeed Insightsiin kahdesti — kerran työpöydän välilehdellä, kerran mobiilin — olet nähnyt eron. 92 työpöydällä putoaa 58:aan mobiilissa. Ero ei ole bugi. Se on throttlausprofiili tekemässä työtään.

Jokaisella kolmesta Core Web Vitalsista on oma mobiilin epäonnistumistapansa:

LCP hitaalla CPU:lla

Largest Contentful Paintia mobiilissa hallitsee kaksi asiaa: aika, jonka herokuva tarvitsee latautuakseen ja dekoodautuakseen, sekä aika, jonka pääsäie on lukittuna JavaScriptin takia ennen kuvan renderöintiä. Throttlatulla CPU:lla 600 KB:n herokuva, joka dekoodautui 80 ms:ssa työpöydällä, voi viedä 350 ms. Yhdistettynä hydraatioon LCP päätyy usein yli 4 sekunnin — "poor"-kynnyksen yläpuolelle.

INP kosketuksissa

Interaction to Next Paint, joka korvasi First Input Delayn 2024, mittaa jokaisen vuorovaikutuksen viiveen koko sivuelinkaaren ajan. Mobiilissa kosketukset laukaisevat käsittelijöitä, jotka ketjuuntuvat usein kalliisiin tilapäivityksiin. Kosketus, jonka pitäisi vastata alle 100 ms:ssa, voi viedä 400 ms, jos pääsäie on kiireinen renderoimassa karusellia tai lataamassa kolmannen osapuolen scriptiä.

CLS myöhään latautuvista mainoksista ja embedeistä

Cumulative Layout Shift on usein pahempi mobiilissa, koska näkymä on pienempi — yksi 200 px:n bannerisiirtymä on paljon suurempi osuus näkyvästä sivusta. Mainokset, jotka latautuvat ensimmäisen renderöinnin jälkeen, upotetut sosiaalisen median kortit, jotka tulevat myöhässä, ja web-fontit, jotka swappaavat FOIT/FOUT-tyyliin, kaikki nostavat pistettä.

Järkevä mittari vuodelle 2026: jos työpöydän Core Web Vitals -piste on 90+, oleta mobiilin asettuvan 55-75 väliin, ellet ole erityisesti optimoinut sitä. Mikä tahansa yli 80 mobiilissa on aidosti vahva tulos.

---

Mobiilikohtaiset ongelmat, jotka pitää löytää

Osa ongelmista näkyy vain mobiilissa. Kypsä auditti etsii niitä tarkoituksella, eikä törmää niihin sattumalta.

Häiritsevät interstitiaalit

Googlen mobiili-UX-ohjeistus rankaisee sivuja, jotka peittävät pääsisällön ponnahdusikkunalla heti navigoinnin jälkeen. Tähän kuuluvat koko ruudun evästepalkit, uutiskirjelomakkeet ja sovellusasennuskehotteet, joita on vaikea sulkea. Evästeiden vaatimustenmukaisuus on pakollinen, mutta toteutus ratkaisee — pieni palkki alareunassa on hyväksyttävä; koko ruudun overlay, joka pitää napsauttaa läpi ennen sisällön näkemistä, ei ole.

Renderöintiä estävä JavaScript

Throttlatulla mobiili-CPU:lla yksi 200 KB:n synkroninen scripti headissä voi viivästyttää first contentful paintia yli sekunnin. Renderöintiä estävät scriptit, jotka "tuntuvat nopeilta" työpöydällä, käyvät kalliiksi mobiilissa.

Optimoimattomat herokuvat

Herokuva on lähes aina LCP-elementti mobiilissa. Saman 1920x1080 JPEG:n tarjoaminen 375 px:n näkymälle on tuhlausta — kävijä lataa neljä kertaa enemmän pikseleitä kuin koskaan näkee. Modernit formaatit (AVIF, WebP), responsiivinen srcset ja eksplisiittiset width/height -attribuutit eivät ole neuvoteltavissa.

Hoveriin perustuva UI

Megavalikot, jotka aukeavat vain hoverissa, vinkit, jotka näkyvät vain hoverissa, kuvagalleriat, jotka paljastavat kuvatekstit hoverissa — kaikki nämä rikkoutuvat kosketuksella. Auditin pitää merkitä jokainen hoveria vaativa vuorovaikutus ja suositella klikkaus-/kosketusvaihtoehtoa.

Autoplay-videoiden akkukulutus

Mobiililaitteen taustalla automaattisesti soiva video on kolminkertainen rangaistus: kuluttaa dataa, syö akkua ja työntää lähes aina LCP:tä ylöspäin, koska selain priorisoi videon dekoodausta. Jos design vaatii liikettä, käytä lyhyttä WebM-luuppia eksplisiittisellä muted- ja playsinline-attribuutilla, ja mieluiten vain riittävän nopeilla verkoilla.

Rikkinäinen viewport-meta

Puuttuva tai väärin konfiguroitu <meta name="viewport"> -tagi on yksi yleisimmistä — ja vahingollisimmista — mobiiliongelmista. Ilman width=device-width, initial-scale=1 -määrittelyä selain palaa 980 px:n virtuaalinäkymään ja kutistaa koko sivun. Jokaisen mobiiliauditin pitää tarkistaa viewport-tagi.

---

Työpöytä- vs mobiiliauditin näkökulmat

Tekijä	Työpöytäauditti	Mobiiliauditti
CPU-throttlaus	Ei lainkaan (1x)	4x hidastus (Moto G Power -luokka)
Verkko	Kaapeli / nopea laajakaista	Throttlattu 4G (~1,6 Mbps, 150 ms RTT)
Näkymä	1350-1920 px leveä	360-414 px leveä
Syötemalli	Hiiri + näppäimistö, hover saatavilla	Vain kosketus, ei hoveria
LCP-kynnyksen todellisuus	Usein alle 2 s	Usein 3-5 s ilman optimointia
Kosketusalueet	Pikselitarkkuus mahdollinen	Vähintään 44x44, 8 px tila
Fonttikoon minimi	14 px yleensä riittää	16 px leipätekstille
Interstitiaalin sieto	Korkeampi	Rangaistaan tiukasti

---

12 kohdan mobiiliauditin tarkistuslista

Aja tämä lista jokaista sivustoa vasten. Se löytää oleellisen ja sivuuttaa kohinan.

1. Viewport-meta-tagi. Tarkista, että <meta name="viewport" content="width=device-width, initial-scale=1"> on headissä. Ei user-scalable=no.
2. Mobiilin Lighthouse-piste. Aja Lighthouse mobiilipresetillä. Kirjaa Performance, Accessibility, Best Practices ja SEO. Vertaa työpöytään. Yli 35 pisteen ero kertoo todellisista mobiiliongelmista.
3. Core Web Vitals CrUX:sta. Hae kenttädata PageSpeed Insightsista. Labra-arvot voivat valehdella; kenttädata ei.
4. LCP-elementin tarkistus. Tunnista mobiilin LCP-elementti. Jos se on herokuva, varmista että se on preloadattu, responsiivinen ja modernissa formaatissa.
5. Kosketusalueiden auditointi. Käy päämatka läpi oikealla laitteella. Jokaisen interaktiivisen elementin pitää olla vähintään 44x44 riittävällä välityksellä.
6. Hoverriippuvuuksien tarkistus. Käy kotisivu ja päänavigaatio läpi kosketuslaitteella. Merkitse jokainen UI, joka ei vastaa oikein kosketukseen.
7. Fontin luettavuus. Varmista, että leipäteksti on vähintään 16 px. Tarkista otsikoiden skaalaus 375 px:ssä.
8. Interstitiaalin tarkistus. Lataa sivu mobiilissa. Jos jokin elementti peittää yli 30 % näkymästä ennen kuin sisältö on luettavissa, merkitse riski.
9. Kuvien optimointi. Ota viisi kuvanäytettä sivustolta. Vahvista modernit formaatit, responsiivinen mitoitus ja eksplisiittiset mitat.
10. JavaScript-paketin koko. Yli 300 KB ensimmäisen osapuolen JS:ää mobiilissa on punainen lippu. Yli 500 KB vaatii uudelleenkirjoitusta.
11. Kolmannen osapuolen skriptien auditointi. Laske kolmannen osapuolen scriptit. Jokainen on mahdollinen estäjä. Tagimanagerit, chat-widgetit ja synkroniset analytiikkatagit ovat yleisiä syyllisiä.
12. Search Consolen mobiilikäytettävyys. Tarkista Search Consolesta mobiilikäytettävyysongelmat. Ne ovat ongelmia, jotka Google on jo nähnyt aidoilla käynneillä.

Siisti työpöydän Lighthouse-piste yhdistettynä heikkoon mobiilipisteeseen ei ole pikkuongelma. Se on ero sen välillä, miltä auditti näyttää ja miltä Google sivustoa katsoo.

---

Työkalut, joilla on merkitystä

• Lighthousen mobiilipreset. Chrome DevToolsin oletus. Käytä lähtötasona jokaisessa auditissa. Mobiilipreset soveltaa CPU-throttlaa, verkkohidastusta ja mobiilinäkymää.
• Chrome DevToolsin laite-emulointi. Vaihda laitepalkki iPhone 14:ään, Pixel 7:ään ja Galaxy S22:een nähdäksesi, miten layout vastaa referenssilaitteilla. Yhdistä Performance-välilehteen CPU-profilointia varten.
• Search Consolen mobiilikäytettävyysraportti. Näyttää Googlen omat löydökset mobiilicrawlerista. Kiinnitä huomiota viewport-, tekstikoko- ja kosketusaluevaroituksiin.
• PageSpeed Insights. Yhdistää labradataa (Lighthouse) ja kenttädataa (CrUX). Kenttävälilehti on rehellisin arvio siitä, mitä aidot käyttäjät kokevat.
• BrowserStack tai aito laite. Korkeapanoksisissa auditeissa emulointi ei riitä. Testaa ainakin yhdellä keskihintaisella Androidilla. CPU, kosketusviive, verkkokäyttäytyminen — kaikki rehellisempää kuin simulaatio.
• WebSEO Auditor. Ajaa täyden mobiili- ja työpöytä-Lighthousen, paljastaa eron näiden välillä ja lisää GEO-pisteen, saavutettavuuden ja strukturoidun datan tarkistukset, jotka tekevät auditista kokonaisen.

---

Mitä korjata ensin: prioriteettimatriisi

Jokainen löydös ei ansaitse samaa huomiota. Nopein tie mitattavaan mobiiliparannukseen on triage vaikutuksen ja työmäärän mukaan.

Nopeat voitot (suuri vaikutus, pieni työmäärä)

• Korjaa viewport-meta-tagi
• Muunna herokuva AVIF/WebP-muotoon responsiivisella srcsetillä
• Lykkää ei-kriittiset kolmannen osapuolen scriptit
• Nosta leipäfontti vähintään 16 px:ään
• Suurenna pienet kosketusalueet päänavigaatiossa ja CTA-napeissa

Isot projektit (suuri vaikutus, suuri työmäärä)

• Pienennä ensimmäisen osapuolen JavaScript-pakettia
• Rakenna hoveriin perustuvat valikot kosketusystävällisiksi
• Rakenne uudelleen layoutin CLS-ongelmien poistamiseksi
• Korvaa renderöintiä estävä CSS kriittisellä inline-CSS:llä

Siisteyskorjaukset (pieni vaikutus, pieni työmäärä)

• Lisää eksplisiittiset width/height jäljellä oleville kuville
• Korvaa bittikartta-ikonit SVG:llä
• Karsi käyttämätön CSS

Älä priorisoi (pieni vaikutus, suuri työmäärä)

• Server-side renderointiin siirtyminen pelkän marginaalisen suorituskyvyn vuoksi
• Framework-migraatiot ilman selvää suorituskykykattoa

Tyypillisellä sivustolla nopeiden voittojen korjaaminen nostaa mobiilin Performance-pistettä 15-25 pistettä. Sillä siirtää auditin "tarvitsee välitöntä työtä" -kaistalta "optimoi vähitellen" -kaistalle.

Suomalaisten verkkokauppojen ja palvelusivustojen tyypillinen mobiili-Performance-piste asettuu vuonna 2026 välille 42-58. Se on selvästi kansainvälisen mediaani-arvon alapuolella, ja syy on yleensä sama yhdistelmä: WordPress-pohjainen julkaisualusta, raskaaksi optimoimaton herokuva ja kerros kolmannen osapuolen analytiikkaa, joka latautuu synkronisesti. Nämä kolme ongelmaa ratkaisemalla pääsee usein 70:n yläpuolelle ilman alustamigraatiota.

Käytä tämän priorisoinnin pohjana sprintin tai kuukausibudjetin runkoa. Nopeat voitot mahtuvat yhden sprintin sisään ja näkyvät seuraavassa raportissa. Isot projektit ansaitsevat oman roadmapin tai erillisen tarjouksen. Tämä erottelu auttaa asiakasta ymmärtämään, mistä laskutetaan nyt ja mistä myöhemmin.

---

Löydösten raportointi asiakkaalle

Useimmat asiakkaat eivät ole teknisiä. Kehittäjälle kirjoitettu löydös — "LCP on 4,2 s renderöintiä estävän JS:n ja optimoimattoman herokuvan takia" — ei merkitse mitään pienyrittäjälle. Mobiiliauditin raportin pitää kääntää.

• Aloita liiketoiminnallisesta lopputuloksesta. "Sivustosi tarvitsee yli 4 sekuntia käyttökelpoiseksi tyypillisellä Androidilla. Se on kaksi kertaa enemmän kuin kilpailijoillasi ja se vie sinulta kävijät ennen kuin he edes näkevät tarjoustasi."
• Näytä, älä kerro. Rinnakkainen kuvakaappaus sivuston latautumisesta nopealla työpöydällä ja throttlatussa mobiilissa on vakuuttavampi kuin mikään piste. 30 sekunnin näyttötallenne on vielä parempi.
• Ryhmittele löydökset vaikutuksen mukaan, ei kategorian mukaan. "Kolme asiaa, jotka liikuttavat mittaria eniten" on hyödyllisempää kuin "kaikki SEO-löydökset" ja sitten "kaikki suorituskykylöydökset".
• Kvantifioi voitto. "Pelkän herokuvan korjaaminen nostaa mobiilin Performance-pisteesi 54:stä noin 72:een." Konkreettiset luvut tuntuvat saavutettavilta.
• Lopeta yhteen suositukseen. Valinnan tuska tappaa toteutuksen. Suosittele yhtä korkeimman ROI:n korjausta ja tarjoa tekemään se.

---

Yhteenveto

Vuoden 2026 vaikuttavat auditit ottavat mobiilin tosissaan. Lighthousen oletukset, aidon laitteen testaus, yllä oleva 12 kohdan tarkistuslista ja prioriteettimatriisi, joka kunnioittaa työmäärää — nämä ovat ainekset auditille, joka löytää oikeat ongelmat ja tuottaa korjauslistan, jonka asiakas oikeasti toteuttaa.

Tärkein viesti: työpöytäversio ei ole enää totuus. Crawleri näkee mobiilin. Käyttäjät katsovat mobiilia. Konversiot tapahtuvat mobiilissa. Auditin pitää alkaa ja loppua siihen näkymään, jota Google itse käyttää sivuston arviointiin. Kaikki muu on toissijaista.

Käytännön suositus toimistolle: rakenna sisäinen mobiili-tarkistusrutiini, joka ajetaan jokaisen uuden asiakkaan kanssa ensimmäisen kahden viikon aikana. Käytä 12 kohdan listaa pohjana, dokumentoi lähtötaso, ja sovi mitattavat tavoitteet 90 päivän jaksolle. Tämä tekee SEO-työstä asiakkaalle näkyvää ja sinulle toistettavaa.

Lopuksi: mittaa uudelleen. Auditin todellinen arvo paljastuu vasta, kun samat kohdat ajetaan uudestaan 30 ja 90 päivän kuluttua. Nousseet pisteet vahvistavat suositukset; pysähtyneet luvut paljastavat, mitkä korjaukset jäivät ilman ympäristön tukea ja ansaitsevat lisätyötä.

Jos haluat ajaa kokonaisen mobile-first-auditin mille tahansa sivustolle alle minuutissa — sisältäen Performance, SEO, Accessibility, Best Practices, GEO ja strukturoitu data — kokeile WebSEO Auditoria ilmaiseksi osoitteessa webseoauditor.com/try. Mobiili- ja työpöytäpisteet näkyvät rinnakkain ensimmäisestä raportista alkaen.