Kort svar: Bekræft først, at LiteSpeed-serveren har crawlerfunktionen aktiveret; plugin-knappen alene kan ikke omgå en serverbegrænsning. Test derefter sitemap uden login, kontroller korrekt Server IP og kør en lille gæstecrawl. URL'er med
X-LiteSpeed-Cache-Control: no-cacheeller andre svar end godkendt 200/201 kan havne på blocklist. Øg ikke interval, tråde eller timeout før en manuel URL viser korrekt miss→hit og serverens CPU/PHP-kapacitet er målt.
Fagligt gennemgået: 28. august 2026 Kontrolgrundlag: WordPress 7.1, LiteSpeed Cache 7.9, PHP 8.4.23 og Chrome 151 på isoleret staging. Crawlerens serverfeature og en fuld crawl er ikke aktiveret eller verificeret, og QUIC.cloud-integration og quota er heller ikke aktiveret eller verificeret; følg derfor målepunkterne i dit eget hostingmiljø.
Crawleren varmer cache ved at besøge sitemap-URL'er. Den reparerer ikke en page cache, der i forvejen mangler serverstøtte eller altid returnerer no-cache. Få først manuel cache miss→hit til at virke.
På denne side
| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Plugin siger crawler disabled | Server feature er ikke tilladt | Crawler Summary og server X-LSCACHE | Hosting aktiverer funktionen |
| Crawler kan ikke hente sitemap | Login, 403, forkert URL eller SSL | Anonym HTTP-status | Ret sitemapadgang |
| Alle URL'er går på blocklist | Forkert Server IP eller alle svar no-cache/ikke 200 | Header/status og debuglog | Ret IP/cacheability |
| Nogle URL'er blocklistes | De er dynamiske, redirecter eller timeout | URL-specifik header/status | Bevar tilsigtet no-cache eller ret fejlen |
| Crawl starter aldrig | Cron/schedule/runner | Crawler schedule og Site Health | Ret WP-Cron/servercron |
| Crawl stopper undervejs | Load limit, timeout eller ressourcepres | CPU/PHP/log og crawlstatus | Sænk belastning, ret langsom URL |
| Mange varianter/crawlers | Mobile/roles/Guest/cache varies | Crawler map | Fjern kun unødvendige varianter |
Crawleren skal være aktiveret på LiteSpeed-serverniveau. I pluginets Crawler → Summary vises en advarsel, hvis feature mangler. Hosting kan kontrollere servervariablen/konfigurationen; X-LSCACHE skal indeholde crawlerfunktionen efter deres platformdesign.
Forsøg ikke at omgå en host-begrænsning med et tredjepartscrawlerplugin eller aggressive HTTP-requests. Begrænsningen kan beskytte delte ressourcer.
Sitemap skal kunne hentes uden login/basic auth og returnere gyldige URL'er. Gem status, content-type og antal URLs. Hvis et sikkerhedsplugin beskytter staging, lav en snæver undtagelse til sitemap/crawler på testmiljøet.
Kontroller at sitemap kun indeholder canonical, publicerede URL'er. Redirects, 404, private endpoints og query-varianter spilder crawlerkapacitet og kan blocklistes.
Hvis alle sider blocklistes, er forkert Server IP en officiel hovedmistanke. Bekræft den autoritative origin-IP med hosting og LiteSpeed-indstillingen. Ved reverse proxy/load balancing skal crawlerens rute være dokumenteret. Offentliggør ikke origin-IP i screenshots.
Test én URL gennem samme crawlersti og kontroller HTTP 200/201 samt cacheheader.
Crawleren kan blockliste sider, der er bevidst no-cache eller ikke svarer med understøttet 200/201. En checkoutside bør forblive no-cache og skal ikke tvinges ind. En offentlig artikel med 301, 403 eller timeout skal rettes ved redirect/firewall/performance.
Brug debugloggen til den konkrete URL. Deaktiver ikke hele blocklist-funktionen for at få grønne tal; den beskytter crawleren mod uegnede sider.
Crawleren bruger sin tidsplan og WordPress/serverrunner. Se Site Health for cronfejl og sammenlign planlagt med faktisk start. På lavtrafiksite kan WP-Cron være uregelmæssig. En rigtig server-cron skal aftales med hosting og eksisterende cronkonfiguration; slå ikke WP-Cron fra uden en verificeret erstatning.
Brug en begrænset test-sitemap eller få URL'er på staging. Standardcrawleren kører som gæst. Rolle-simulation og flere cache varies opretter ekstra crawls og bør først tilføjes, når gæstecrawl er stabil.
Aktuelle LiteSpeed-versioner begrænser rolle-simulation af sikkerhedshensyn, blandt andet for høje roller. Brug aldrig administrator-ID til crawleren. Testbrugere må ikke have rigtige kundedata.
Crawleren kan sende mange requests og opbygge flere cachevarianter. Mål CPU, load, PHP-workers, memory, database og frontend-TTFB før, under og efter. Øg kun belastning én parameter ad gangen. Stop hvis checkout, admin eller almindelige besøgende bliver langsommere.
En højere timeout kan hjælpe enkelte langsomme sider, men ret selve langsomheden før hele crawlens timeout hæves.
Definér grænser sammen med hosting eller den eksisterende driftsbaseline: frontend-responstid, aktive PHP-workers, CPU/load, databasebelastning og fejlrate. Start med få URL'er og én crawlerinstans. Stop eller pause ved vedvarende overskridelse, nye 5xx/429, langsommere checkout/admin eller en voksende blocklist. En crawler, der “gennemfører” ved at forringe sitet, er ikke en succes.
Kør ikke første fulde test samtidig med backup, import, billedregenerering, cachepurge eller anden tung cron. Gem tidsstempler for start, hvert interval og stop, så ressourcegrafen kan kobles til crawleren. På delt hosting kan serverens crawlerbegrænsning være bevidst og bør respekteres.
Brug sitemap som en produktionsliste, ikke som en samling af alle URL'er, WordPress kan generere. Udelad redirects, noindex, login, søgning, preview, feeds, query-filtre og sessionbaserede sider. Bevar tilsigtet no-cache for kurv, checkout og konto. Hvis sitemap ejes af et SEO-plugin, rettes kilden dér i stedet for at vedligeholde en separat manuel kopi uden ejer.
Mobil-, sprog-, valuta-, rolle- og Guest-varianter multiplicerer crawls. Opret kun en crawlervariant, når den har en forskellig cachebar respons og et konkret behov. Dokumenter forventet antal URL'er × varianter før aktivering; en pludselig mangedobling er et tidligt tegn på forkert vary eller sitemap.
Gruppér blocklist efter status og årsag. Tilsigtet no-cache kræver ingen rettelse. 301/302 bør erstattes af den endelige canonical URL i sitemap. 403 kræver kontrol af den specifikke crawlersti og sikkerhedsregel. 404 fjernes eller rettes ved kilden. 5xx/timeout undersøges som en side-/serverfejl før næste crawl. Denne sortering giver en kort, kontrollerbar retest i stedet for at rydde hele blocklisten og håbe.
Vælg tre cachebare test-URL'er. Purge dem målrettet, kør crawleren, og hent dem derefter anonymt. De skal vise hit og korrekt indhold. En crawlerstatus “complete” uden hitbevis er ikke nok.
En 404 i sitemapet skal normalt rettes ved kilden og fjernes fra sitemap, ikke force-caches. En 301 kan indikere, at sitemap bruger en gammel kanonisk URL. no-cache kan være tilsigtet for login, konto eller preview og bør ikke “repareres” til hit. En 5xx kræver fejldiagnose før crawleren prøver igen.
Gruppér derfor blokeringer efter status og ejer. Ret én repræsentativ URL i hver kategori, genkør en lille test, og fjern først derefter resten af samme dokumenterede mønster. Det er sikrere end at tømme blocklisten, fordi en nulstilling ikke ændrer årsagen og kan belaste sitet med de samme fejl igen.
Dashboardet viser gennemførte URL'er, men en anonym request er stadig miss hver gang. Kontrollér først den manuelle cachetest. Hvis samme URL ikke kan gå miss → hit uden crawler, er problemet page cache, exclude eller løbende purge — ikke crawlerens schedule. Hvis manuel cache virker, sammenlignes crawlerens host, variant og cookies med den offentlige request; den kan have varmet en anden cachekey.
En lille batch gennemføres, mens en fuld sitemapkørsel presser PHP-workers og øger TTFB. Øg ikke tråde. Sænk batch og interval, fjern unødvendige URL-varianter, og aftal kapacitetsgrænser med hosting. Stopkriteriet skal beskytte besøgende: stigende fejlrate, vedvarende worker-kø eller mærkbart dårligere frontend har forrang over en varm cache.
Et site med stabil organisk trafik kan opbygge cache naturligt og have mere værdi af korrekt purge end af en aggressiv crawler. Crawleren giver især mening, når mange vigtige, offentlige URL'er skal være varme før den første besøgende, og serveren har kapacitet til det kontrollerede ekstra arbejde. Hvis målingen ikke viser en reel gevinst, er “deaktiveret” en fuldt gyldig driftstilstand.
Vurder derfor resultatet på repræsentative URL'er og rigtig brugertrafik, ikke på hvor hurtigt dashboardets kø bliver tom. En komplet crawl, som forringer TTFB eller konstant genopvarmer unødvendige varianter, er ikke en succes.
Slå crawler schedule fra, gendan tidligere interval/load/timeout og fjern testroller/sitemaps. Purge ikke hele cache automatisk ved rollback; bevar fungerende cache og logs. Hvis hosting aktiverede serverfeature midlertidigt, følges deres rollbackprocedure.
Hosting skal have crawlerstatus, sitemap, redigeret Server IP, blocklist-log og ressourcemålinger. Pluginudvikleren skal have en URL-specifik cache/headerfejl. Se LiteSpeed hosting hos Hostious ved serverfeature og kapacitet.
Oftest fordi serveren ikke tillader crawling – knappen i pluginet kan ikke omgå en serverbegrænsning. Bekræft først hos hosten, at crawler er aktiveret på LiteSpeed-serveren.
Et tilgængeligt sitemap uden login, korrekt Server IP i indstillingerne (så crawleren ikke går via CDN), fungerende cron og en stabil basis-cache. Ellers crawler du fejl ind i cachen.
Ja, den opvarmer cachen ved at besøge siderne. Start med lav belastning og få samtidige tråde, kør uden for spidsbelastning, og øg kun, hvis serveren har luft.
Gem serverens featurestatus, sitemapets HTTP-status og en lille testkøs start- og sluttid. For en blokkeret URL noteres status, no-cache-årsag og blocklist-kategori; query strings og private paths fjernes. Sammenhold køen med CPU, PHP-workers og TTFB i samme tidsrum.
Eftertesten bør vise miss før og hit efter crawl på tre ufølsomme URL'er, mens login, konto og andre dynamiske sider fortsat ikke caches. Brug dine egne målinger og stopkriterier frem for at kopiere et tråd- eller intervaltal – serverens crawlerfunktion og den rette belastning afhænger af dit miljø.
