Verktøyet under henter den offentlige versjonen av én adresse og forteller hva som følger av den. Det logger ikke inn, skanner ikke nettverk og gjetter ikke. Det leser det samme som nettleseren til den besøkende: statuskoden etter videresendinger, headerne, HTML-en og de filene denne HTML-en ber om før noe kan tegnes. Disse filene lastes faktisk ned og veies, i stedet for å anslås.
Nettstedssjekk
Se hva nettstedet ditt viser offentlig
Oppgi adressen til et nettsted du driver. Vi henter det slik en nettleser ville gjort, og viser hva som følger av det, sammen med nøyaktig det vi leste.
Hva vi sjekker
Svarhoder, tid til første byte, tittel og beskrivelse, kanonisk adresse, overskrifter, strukturerte data, bilder, robots.txt og nettstedskartet, og på WordPress også hva kildekoden røper om installerte plugins. I tillegg henter vi ressursene som blokkerer første opptegning og summerer hva de faktisk veier.
Hva vi ikke sjekket
- administrasjonsområdet og alt bak en innlogging
- databasen, størrelsen og tilstanden
- sikkerhetskopier, om de finnes og om de lar seg gjenopprette
- plugin-versjoner mot en sårbarhetsdatabase
- hvordan nettstedet oppfører seg for en innlogget bruker
- alle sider utenom den ene adressen du oppga
Hva sjekken faktisk måler
Første lag er våre egne HTTP-forespørsler fra en Cloudflare-kant: tid til første byte, statuskode etter at videresendinger er løst opp, sikkerhetsheadere, cache-headere og komprimering. Andre lag er HTML-en selv, som gir tittel, metabeskrivelse, kanonisk adresse, antall overskrifter på øverste nivå, JSON-LD-blokker, språkattributt og hvordan bildene er deklarert.
Tredje lag er startvekten til siden, og det er den som oftest endrer en samtale. Sjekken samler alle stilark og alle skript uten defer fra head, altså nøyaktig det en nettleser må ha lastet ferdig før den kan tegne noe. Deretter henter den dem og oppgir det ekte kilobytetallet, delt mellom CSS og JavaScript, med tiden til den tregeste og listen over fremmede domener de kommer fra.
For WordPress kommer noen ting i tillegg som er offentlige ved design og likevel overrasker eiere. Stier til plugin- og temafiler avslører hva som er installert og i hvilken versjon, fordi versjonsnummeret som regel står i adressen til stilarket. REST-endepunktet med brukerlisten svarer uten innlogging med mindre noen har stengt det. Filen xmlrpc.php svarer ofte fortsatt, selv om de fleste installasjoner ikke trenger den til noe.
Hvorfor det ikke finnes en poengsum her
Dette er en beslutning, ikke en mangel. En poengsum inviterer til nøyaktig ett oppfølgingsspørsmål, nemlig hva man skal gjøre med den, og det ærlige svaret på det spørsmålet er enda en gjennomgang. Vekt har ikke det problemet. Nitten blokkerende forespørsler er et tall man kan se synke. En megabyte JavaScript før første opptegning peker på en konkret plugin. Elleve forespørsler fra to fremmede domener peker som regel på en fonttjeneste og en tag manager, og begge deler er valg noen har tatt og kan ta tilbake.
Laget har et tak, og det taket skal nevnes. Vi måler vekt og svartid, ikke opplevelsen til brukerne dine. Dette er ikke en Core Web Vitals-måling og erstatter ingen. Feltdata samles inn fra ekte besøkende over tjueåtte dager, og de er allerede dine, gratis, i Google Search Console under rapporten om Core Web Vitals. Vil du vite hvordan kassen oppleves på en mobil med svakt nett i Tromsø, er den rapporten det eneste stedet som svarer. Våre tall sier hvilken del av siden som står bak det den rapporten viser.
Hva sjekken ikke kan se
Listen over det utilgjengelige er kort og verdt å kjenne før noen tar resultatet for et helhetsbilde. Sjekken går aldri inn i administrasjonspanelet og vet derfor ingenting om kontoer, roller eller hvem som sist logget inn fra en ukjent adresse. Den ser ikke databasen og sier derfor ikke om tabellene sveller av forlatte transients. Den sjekker ikke sikkerhetskopier, fordi sikkerhetskopier per definisjon ikke er offentlige. Den sammenligner ikke oppdagede plugin-versjoner mot en sårbarhetsdatabase, så en avlest versjon er et faktum og ikke en risikovurdering. Og den sjekker nøyaktig den ene adressen du oppga, ikke hele nettstedet.
Den innloggede visningen er et eget hull. WordPress serverer innloggede besøkende et helt annet sett databasespørringer og slår som regel av sidecache for dem. En butikk som svarer en gjest på noen hundre millisekunder, kan bruke flere ganger så lang tid på en innlogget kunde med full handlekurv. En sjekk utenfra viser ikke det, og ingen verktøy uten kontotilgang viser det.
Hvordan lese hver funnklasse
Funn med høy alvorlighetsgrad koster penger eller sikkerhet med en gang. Manglende HTTPS på måladressen, en robots noindex på en side som skal indekseres, et åpent endepunkt med brukerlisten, fire eller flere manglende av de fem sikkerhetsheaderne, en treg første byte. Hit hører også en tung start: femten eller flere blokkerende forespørsler, eller over en halv megabyte før første opptegning. Hvert av disse har én konkret løsning, som regel i serveroppsettet eller i en plugin som allerede er installert.
Funn med middels alvorlighetsgrad beskriver en tilstand man kan kjøre i et år uten avbrudd, mens forspranget sakte forsvinner. Ingen cache på HTML-en, blokkerende filer uten komprimering, skrifter lastet fra Googles servere i stedet for eget domene, manglende metabeskrivelse, ingen blokk med strukturerte data, bilder uten mål, ingen sitemap. Den som har stabil trafikk, planlegger dette til neste gjennomgang. Den som driver butikk i høysesongen, tar komprimering, cache og bilder først, fordi de når handlekurven raskest.
Funn med lav alvorlighetsgrad er stort sett spor teknologistabelen legger igjen: WordPress-versjonen i metagenerator, servernavn og versjon i en header, flere overskrifter på øverste nivå på én side, kort cachelevetid på statiske filer, bilder uten lat lasting. Ingenting av dette velter et nettsted. Rydd dem sammen med annet arbeid, ikke i stedet for det.
Bekreftelsene står for seg selv. Når verktøyet melder at sikkerhetsheaderne er komplette, at HTML-en kom fra cache, at strukturerte data finnes og at sidestarten er lett, er det ikke fyllstoff. Det svarer på spørsmålet eiere stiller oftest, nemlig om forrige team gjorde jobben.
Når det ærlige svaret er at ingenting trenger å gjøres
Dette skjer oftere enn markedet for diagnoseverktøy antyder. Et bedriftsnettsted på anstendig hosting, med oppdatert WordPress, komplette headere, fornuftig cache og lett start, trenger ingenting fra oss. Viser rapporten bare funn med lav alvorlighetsgrad og bekreftelser, er det nettopp dette tilfellet. Lukk fanen og kom tilbake om et halvår.
Det finnes også en mellomtilstand der det riktige er å vente. Byttet du tema eller hosting forrige uke, beskriver våre tall allerede den nye versjonen, mens Search Console beskriver den gamle en måned til. Ikke bestill arbeid på grunnlag av to kilder som beskriver to forskjellige nettsteder. La vinduet flytte seg først.
Og et tredje tilfelle: et ekte funn som ikke er ditt. Manglende sikkerhetsheader, manglende komprimering eller HTML uten cache er ofte oppsett hos leverandøren og ikke i nettstedet. Én melding til teknisk støtte hos hostingleverandøren løser det billigere enn noe prosjekt.
Hva vi gjør med adressen du oppgir
Vi henter offentlige sider på adressen du sender inn, vi logger ikke inn noe sted, og vi lagrer ingenting utover en anonym teller over kjøringer. Rapporten havner på ingen e-postliste, fordi vi aldri ber om en e-postadresse. Klikker du deg videre til kontakt, kommer skjemaet ferdig utfylt med adressen og de tre alvorligste funnene, og du ser hele teksten før noe sendes.
Hvor du går videre hvis rapporten fant noe ekte
Gjentagende funn med middels alvorlighetsgrad betyr som regel at ingen passer på nettstedet, ikke at én ting er ødelagt, og svaret på det er vedlikehold av WordPress-nettsider. Tung start og treg første byte fører til å gjøre en WordPress-side raskere. Åpent brukerendepunkt, svarende xmlrpc.php og fraværende headere er materiale for en WordPress sikkerhetsrevisjon, fordi de tre ikke er verdt å fikse én om gangen.
