Din webbplats kan se bra ut och ändå läcka intäkter. En långsam startsida, en trasig mobilmeny, varningar om blandat innehåll eller saknade grunder för tillgänglighet får i tysthet människor att lämna (och de är svåra att upptäcka utan en process). De flesta team ”fixar saker när de märker dem”, vilket ärligt talat är så problem blir kvar i månader.
Den här checklistan för teknisk granskning är byggd för marknadschefer som behöver en tydlig överlämning till utvecklare inför en kampanjpush, webbplatsägare som försöker ringa in varför konverteringen föll efter en tema-/pluginändring, och konsulter som måste leverera en trovärdig teknisk granskning utan att göra det till ett sex veckor långt uppdrag. Resultatet är en prioriterad, kryssrute-baserad granskning av hastighet, mobil, HTTPS/säkerhet, tillgänglighet (WCAG-relaterade kontroller) och övergripande webbplatshälsa, plus en punchlista för ”nästa 48 timmar”.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Det här får du |
|---|---|---|
|
|
|
Hela AI-prompten: prioriterad checklista för teknisk webbplatsgranskning
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[WEBBPLATS_URL] |
Ange den fullständiga URL:en till webbplatsen du vill granska, inklusive protokoll (t.ex. https://). Till exempel: "https://example.com"
|
|
[KONTEXT] |
Lägg till relevant bakgrund eller eventuella begränsningar kring webbplatsen, till exempel specifika problem, målgrupp eller affärsmål. Till exempel: "Webbplatsen är en e-handelsbutik som riktar sig till millennials och har höga avvisningsfrekvenser på mobila kassasidor."
|
|
[PRIMART_MAL] |
Ange huvudmålet med granskningen, till exempel att förbättra laddhastighet, uppnå efterlevnad av Core Web Vitals eller öka konverteringar. Till exempel: "Förbättra LCP till under 2,5 sekunder på viktiga produktsidor för att öka e-handelskonverteringar."
|
|
[PLATTFORM_STACK_LEDTRADAR] |
Ange vilken plattform eller teknisk stack webbplatsen använder, till exempel CMS, ramverk eller hostingmiljö. Till exempel: "WordPress med WooCommerce-plugin, hostad på SiteGround."
|
|
[TON] |
Beskriv önskad ton i granskningsrapporten, till exempel formell, teknisk eller mer samtalston. Till exempel: "Formell och teknisk, anpassad för utvecklare och IT-personal."
|
|
[VERSALER_MED_UNDERSCORE] |
Ange text med versaler separerade med understreck, vanligtvis använt för konstanter eller kodidentifierare. Till exempel: "KARNA_WEBBVARDEN"
|
Proffstips för bättre resultat med AI-prompten
- Ange en riktig URL och en testsökväg, inte bara startsidan. Om din viktigaste sida är /pricing eller /checkout, ta med det i kontexten så att checklistan speglar sidorna som faktiskt betyder något. Testa: ”Granska https://example.com och prioritera problem som påverkar /pricing och /checkout på mobil.”
- Lägg till affärskontext så att prioriteringen speglar verkligheten. Använd det valfria kontextfältet för att säga vad ”framgång” innebär (lead gen, bokningar, e-handel) och vad som nyligen förändrats. En bra tilläggsprompt är: ”Eftersom detta är en Shopify-butik, prioritera åtgärder som minskar avbrutna varukorgar och förbättrar Core Web Vitals.”
- Be om verktygsspecifika verifieringssteg. Prompten flaggar redan vad som måste verifieras, men du kan vässa den genom att be om exakta kontroller. Till exempel: ”För varje punkt som ska ’verifieras med verktyg’, ange exakt Lighthouse-mått eller Search Console-rapport att granska, samt godkänd/underkänd-trösklar.”
- Iterera i två pass: triage, sedan implementation. Efter första resultatet, fråga: ”Skriv nu om de kritiska och höga punkterna som Jira-ärenden med acceptanskriterier, reproduktionssteg (om relevant) och uppskattad insats (S/M/L).” Då får du något en utvecklare kan agera på direkt.
- Tvinga fram avvägningar när resurserna är begränsade. Om du bara har en sprint, låt modellen välja. Använd: ”Anta att vi har 8 utvecklartimmar den här veckan. Välj de 5 åtgärderna med bäst effekt i förhållande till insats och motivera i en mening per åtgärd.”
Vanliga frågor
Marknadschefer använder den för att översätta ”webbplatsen känns långsam” till en prioriterad lista som en utvecklare kan implementera före betalda kampanjer och lanseringar. Tekniska SEO-specialister lutar sig mot den för att strukturera granskningar kring Core Web Vitals, mobilbeteende, HTTPS och crawl-/indexhygien utan att missa grunderna. Frilansande webbutvecklare använder kryssruteformatet för att avgränsa arbete, uppskatta insats och undvika luddiga önskemål som ”gör den snabbare”. Byråkonsulter använder den när de behöver en trovärdig, effekt-rankad granskningsleverans som de kan gå igenom med en kund i ett enda samtal.
E-handelsvarumärken får värde eftersom hastighet, mobil UX och HTTPS-förtroendesignaler direkt påverkar ”lägg i varukorg” och att checkout slutförs; listan för ”nästa 48 timmar” är perfekt inför en kampanj. SaaS-bolag använder den för att vässa prestanda på landningssidor och mobil responsivitet för demo-förfrågningar och provregistreringar, där små fördröjningar kan sänka konverteringsgraden. Företag inom professionella tjänster (juridik, redovisning, kliniker) gynnas av tillgänglighets- och mobilkontroller som minskar friktion för leadformulär och tidsbokningar, särskilt för trafik med lokal intention. Publicister och innehållssajter använder den för att förbättra laddhastighet, minska layoutskiften och skydda annons-/analytiksprestanda utan att slå sönder grundmallar.
En typisk prompt som ”Skriv en teknisk SEO-granskning för min webbplats” misslyckas eftersom den: saknar en tydlig, obligatorisk omfattning (hastighet, mobil, HTTPS/säkerhet, tillgänglighet och hälsa) så resultatet blir slumpmässigt, inte ger någon kryssrutestruktur som du kan genomföra, ignorerar rangordning efter allvarlighetsgrad/påverkan så team inte vet vad som ska åtgärdas först, ger generiska råd (”komprimera bilder”) i stället för konkreta kontroller och fixar (”konvertera hero-JPG till AVIF; sätt lång cache för /assets/*”), och hoppar över vägledning för verktygsverifiering när modellen inte kan testa webbplatsen live. Den här prompten tvingar fram en process: omformulerat mål, kategoriserade fynd, prioriterade åtgärder och en kort punchlista för att komma igång direkt.
Ja. Det enklaste är att vara specifik i inmatningsfälten: använd en exakt [WEBSITE_URL] (inkludera den exakta sökvägen du bryr dig om), och använd [CONTEXT] för att beskriva din stack (WordPress, Shopify, Webflow), senaste ändringar och vad ”primärt mål” betyder (leads, checkout, bokningar). När du fått första checklistan kan du köra en uppföljning som: ”Skriv om bara de kritiska/höga punkterna för en WordPress-webbplats som använder Cloudflare och inkludera exakta plugin-/konfigförslag.” Om webbplatsen ligger bakom inloggning eller blockerar skanning, berätta för modellen vad den kan anta och vad du kan tillhandahålla (skärmbilder, Lighthouse-rapporter, serverheaders).
Det största misstaget är att lämna [WEBSITE_URL] för vag — i stället för ”min webbplats”, använd ”https://example.com/pricing” eller ”https://example.com/checkout” så att granskningen fokuserar på sidor med hög effekt. Ett annat vanligt fel är att hoppa över [CONTEXT]; ”WordPress-webbplats” säger lite, medan ”WordPress + Elementor, WooCommerce, Cloudflare, la till en chattwidget förra veckan” leder till mycket mer genomförbara åtgärder. Många glömmer också att ange det primära målet, vilket ändrar prioriteringen (t.ex. driftsäkerhet för leadformulär vs. hastighet på produktsidor). Till sist behandlar vissa resultatet som en juridisk tillgänglighetscertifiering; prompten är en praktisk WCAG-inriktad checklista, inte ett efterlevnadsutlåtande.
Den här prompten är inte idealisk för penetrationstester, juridisk efterlevnadscertifiering eller djupa applikationssäkerhetsgranskningar, eftersom den uttryckligen undviker de områdena. Den passar också dåligt om du behöver en plan för en full kodomskrivning eller en komplett UX-/varumärkesomdesign; du får ingen kreativ omplattformsstrategi, utan ingenjörsnära åtgärdssteg. Om du inte är redo att agera på fynden (ingen utvecklaråtkomst, ingen budget, ingen sprinttid), gör först en mindre diagnos med PageSpeed Insights och välj en flaskhals att åtgärda.
Tekniska problem talar inte om att de finns. De bara nöter ned rankningar, förtroende och konverteringsgrad. Klistra in den här prompten i ditt AI-verktyg, kör checklistan och börja med punkterna för ”nästa 48 timmar” medan du har momentum.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.