Er Google AMP død i 2026? (Og hva du bør bruke i stedet)

Lynet har falmet. I 2016 lanserte Google AMP. I juni 2021 forsvant kravet om AMP for Top Stories. I 2026 er formatet uten rangeringsverdi for et WordPress-nettsted.

Er AMP død? Ja. Bør du bruke det på WordPress-siden din? Nei.

Denne teksten er et post-mortem og en fjerningsguide. Den tar for seg hva AMP faktisk var under panseret, hvorfor prosjektet tapte, hvordan du tar det ut av WordPress uten å miste indekserte adresser, og hvilken stack som erstatter det. Den tar også opp et norsk poeng som den amerikanske AMP-historien gjerne hopper over: VG, Aftenposten og NRK levde aldri på WordPress AMP slik amerikanske nyhetsredaksjoner gjorde. Norsk WordPress-AMP er rest-plugins, ikke en nyhetsstack.

#Er AMP fortsatt relevant i 2026

Nei. AMP (Accelerated Mobile Pages) er ikke relevant for nye WordPress-prosjekter i 2026. Google fjernet AMP-kravet for Top Stories i juni 2021. Core Web Vitals tok over som det primære ytelsessignalet for rangering. Formatet virker fortsatt teknisk. Googles cache svarer fortsatt. Det gir deg ingenting i søkeresultatene som en vanlig, rask side ikke også får.

Hvis nettstedet ditt kjører AMP i dag, er det eneste relevante spørsmålet hvordan du fjerner det uten å miste URL-er. Bygger du nytt, hopper du over AMP og går rett på stacken lenger nede.

Google sier at AMP er «støttet». Det er ikke det samme som anbefalt eller påkrevd. Ingen søkefunksjon krever AMP-formatet. Lynikonet i resultatene er borte. AMP-rapporten i Search Console er avviklet som særskilt flate, nettopp fordi Google sluttet å behandle formatet som noe eget.

#Hva AMP faktisk var

AMP var aldri et eget språk. Det var en innsnevret HTML-profil med tre deler som måtte virke sammen. Forstår du de tre, forstår du også hvorfor prosjektet endte der det endte.

AMP HTML. Et kuratert utvalg tagger. Du fikk ikke skrive din egen <script>. Standard elementer ble byttet ut med AMP-komponenter: <img> ble <amp-img>, iframe ble <amp-iframe>, analyse gikk gjennom <amp-analytics>, karuseller gjennom <amp-carousel>, og dynamikk ble uttrykt deklarativt med <amp-bind> og <amp-list> i stedet for vanlig kode. Inline CSS var tillatt, men med et hardt tak. Opprinnelig 50 KB, senere hevet til 75 KB. Eksterne stilark var forbudt. Det taket er ikke en anekdote. Det er grensen som gjorde at et vanlig WordPress-tema aldri kunne gjenbrukes som AMP uten å kastes om.

AMP-runtime (v0.js). Hver AMP-side lastet ett JavaScript-bibliotek hostet av Google. Runtime styrte ressurslasting, satte størrelse på hvert element før maleri for å unngå layoutskift, og lastet det under folden seint. Sidene ble forutsigbare fordi runtime eide renderløpet. Den forutsigbarheten var salgsargumentet.

AMP Cache og forhåndsvisning. Dette er delen de fleste glemmer. Google rangerte ikke bare AMP-sider. Google kopierte dem til egen CDN (cdn.ampproject.org) og forhåndsrenderte dem i søkeresultatene før du trykket. Derfor føltes et AMP-treff øyeblikkelig: bytene lå allerede på Googles kant, delvis malt utenfor skjermen. Følelsen kom aldri bare fra formatet. Den kom fra formatet pluss at Google hentet siden fra egen infrastruktur. Byttet var hastighet mot at Google eide visningen av sidene dine. Derfra vokste resten av problemene.

#Teknisk sammenligning

Tabellen under stiller Google AMP mot en vanlig ytelsesstack i 2026. Tallene i Core Web Vitals-raden er Googles publiserte terskler, ikke et labresultat fra ett nettsted.

AMP-sidene er ikke «skrudd av». Cachen svarer. Rammeverket parser. Økosystemet som gjorde AMP verdifullt, er borte:

• Ingen rangeringsfordel. AMP-sider får ikke særbehandling i søket.
• Ingen Top Stories-plikt. Enhver side som møter Core Web Vitals, kvalifiserer.
• Utgivere har tatt formatet ut. Store redaksjoner har fjernet AMP og rapportert at trafikken ble der den var, fordi kravet allerede var borte.
• Utviklingen har stoppet. Ingen vesentlige AMP-funksjoner har kommet siden 2023.

For WordPress-eiere er den praktiske statusen derfor: avinstaller tillegget, sett omdirigeringer, og invester i native ytelse. Feltmåling og labmåling av det arbeidet ligger i guiden oppnå 100/100 Core Web Vitals i 2026.

#Hvorfor AMP feilet

Målet var hastighet. Løsningen var å forby JavaScript. Den rammen løste et ekte 2015-problem og skapte flere nye.

I 2015 var en typisk mobilartikkel treg fordi den bar med seg annonsestabler, sporingspiksler og synkron skript fra et skrivebordstema. AMP kuttet det med regel, ikke med disiplin. Siden ble rask fordi du ikke fikk lov til å gjøre den treg. Det er en dårlig avtale den dagen nettleseren, CDN-en og måleverktøyene kan belønne den samme disiplinen uten å ta URL-en din.

#Kompromisset

Kostnaden var høy, og den kom i tre faste poster.

1. Utvanning av merkevare. Sidene ble servert fra Googles cache. Brukeren så google.com/amp/dinside.no i adresselinjen, ikke ditt eget domene. Deling, kopiering og gjenkjennelse brøt. Et bokmerke pekte på Google, ikke på deg.
2. Konvertering. JavaScript-forbudet som gjorde sidene forutsigbare, gjorde dem også trege i betydningen inerte. Flertrinns skjema, dynamisk pris, stengt kasse og tredjeparts booking virket ikke, eller krevde sprø AMP-spesifikke omskrivninger. For en ren artikkel var det tålelig. For alt med trakt var det en skatt på omsetning.
3. To maler. AMP betydde nesten alltid to visninger av hver mal: den kanoniske versjonen ekte brukere landet på, og AMP-versjonen Google serverte. To kodeveier, to sett feil, to QA-runder for hver endring. I WordPress ble det temaet pluss AMP-tilleggets egne komponenter, ofte med en tredje variant for ?amp=1.

#URL-problemet og Signed Exchanges

Google skjønte at cache-URL-en skadet utgiverne, og brukte år på en fiks: Signed HTTP Exchanges (SXG), en del av Web Packaging. Cachen kunne da servere en kryptografisk signert kopi og likevel vise utgiverens ekte URL. SXG virket. Det var tungt, dårlig støttet utenfor Chrome, og det kom etter at tålmodigheten var brukt opp. At URL-problemet krevde kryptografi, sier hvor dypt det satt.

#Inngjerdet hage

Over tid så AMP mindre ut som et ytelsesprosjekt og mer ut som en spak. En endret konkurranseklage fra en koalisjon av amerikanske delstatsadvokater hevdet at Google brukte AMP til å begunstige egen annonsebørs og bremse rivaliserende annonseformater. Uansett juss satt oppfatningen: et rammeverk solgt som åpen hastighetsstandard styrte trafikk og annonseinntekt mot selskapet som eide cachen.

For et norsk bedriftsnettsted på WordPress var det sjelden annonsebørsen som gjorde vondt. Det som gjorde vondt, var at skjemaet på kontaktsiden døde i AMP-malen, at bookingwidgeten ikke fikk kjøre, og at byrået likevel måtte vedlikeholde to maler fordi noen i 2018 hadde slått på tillegget «for SEO».

#Skiftet til Core Web Vitals

I 2021 innførte Google Core Web Vitals (CWV). Beskjeden: Google bryr seg ikke om du bruker AMP. Google bryr seg om at siden er rask.

Det var dødsdommen. En vanlig responsiv side som passerer tersklene (LCP under 2,5 s, INP under 200 ms, CLS under 0,1) får samme rangeringsbehandling som AMP en gang stengte bak formatkravet, uten restriksjonene. Hvorfor holde en parallell, innskrenket versjon av nettstedet når originalen kan bli rask nok?

INP erstattet FID som Core Web Vital i mars 2024. AMP hadde i praksis ikke et INP-problem fordi egen JavaScript var forbudt. Det er ikke et argument for å beholde AMP. Det er et argument for å fjerne tredjepart fra hovedtråden på den kanoniske siden, som er det INP faktisk måler.

#Tidslinje

#Hvorfor utgiverne gikk, i praksis

Utgangen var ikke en koordinert protest. Det var en langsom oppsamling av små nederlag. En nyhetsdesk fant at AMP-artikkelen ikke kunne kjøre samme samtykkebanner som hovedsiden, så personvern krevde en andre implementasjon. Annonseoperasjonen fant at et AMP-bare-format tjente mindre enn standardstakken. Analyse kom gjennom <amp-analytics> med annen sesjonskobling, så tallene aldri stemte med den kanoniske siden, og hver kvartalsrapport trengte en fotnote. Design ba om én interaktiv funksjon AMP-komponentene ikke hadde, og svaret var alltid «ikke på AMP». Hver av delene var til å leve med alene. Sammen var det et fullt parallelt produkt for å beholde et merke Google deretter tok vekk.

75 KB CSS-taket forklarer en konkret del av den splittelsen. Et WordPress-tema med WooCommerce, et skjemaplugin og et cookie-banner er ferdig med 75 KB før du har malt headeren ferdig. AMP-løsningen var ikke å gjøre temaet slankere. Den var å kaste temaet og bygge en andre, magrere mal. Da Google sluttet å kreve den magre malen, ble den andre malen ren kostnad.

#Fjerne AMP trygt

Hvis WordPress-nettstedet fortsatt kjører AMP, bærer du alle kostnadene og ingen av de gamle fordelene. Fjerningen er rett frem. Omdirigering og canonical er der nettstedene mister rangering hvis de haster. Gå i denne rekkefølgen.

#Mål AMP-trafikken du faktisk har

Før du rører noe, åpne analyse og Search Console og tallfest hvor mange økter og inntrykk som fortsatt lander på /amp/-adresser. Eksporter listen over AMP-URL-er som fortsatt får inntrykk, slik at du omdirigerer de rette stiene og kan se regresjon etterpå.

Se etter begge variantene. Tillegget og eldre temaer har brukt både /innlegg/amp/ og ?amp=1. Noen har også /amp/innlegg/. En eksport som bare matcher den ene, etterlater den andre i indeksen.

Sjekk også om AMP-adressene i det hele tatt konverterer. På de fleste norske bedriftsnettsteder er svaret nei, fordi skjemaet på AMP-malen er ødelagt eller forenklet. Da er «AMP-trafikk» ofte bare crawlet innhold, ikke forretning.

#Bekreft at de kanoniske sidene er raske først

Ikke fjern AMP mens standardmalen er treg. Da bytter du en rask, innskrenket side med en treg, fri side. Kjør de viktigste kanoniske malene gjennom PageSpeed Insights og bekreft at de klarerer Core Web Vitals på mobil. Fiks malen først, pensjoner AMP etterpå. Rekkefølgen betyr noe.

LCP på en WordPress-artikkel er som regel hero-bildet, TTFB og render-blokkerende CSS. INP er som regel chat, taggstyring og skjemaplugins som spiser hovedtråden. CLS er som regel et banner uten reservert høyde. Ingen av delene løses av AMP i 2026. Alle løses på den kanoniske malen. Hvis du trenger en formell gjennomgang av felt pluss lab, er det jobben til Core Web Vitals-revisjonen.

#301-omdirigeringer fra alle AMP-adresser

AMP-URL-er som /post-name/amp/ må omdirigeres til originalen med 301. Query-varianten ?amp=1 trenger egen regel. Glemmer du den, ligger indekserte adresser som 404 i ukesvis. Det er den største SEO-risikoen i hele løpet.

Nginx:

rewrite ^/(.*)/amp/?$ /$1/ permanent;
if ($arg_amp) {
    set $args "";
    rewrite ^(.*)$ $1 permanent;
}

Apache (.htaccess):

RewriteEngine On
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]
RewriteCond %{QUERY_STRING} (^|&)amp=1(&|$)
RewriteRule ^(.*)$ /$1? [R=301,L]

WordPress (functions.php eller et lite must-use-plugin):

add_action('template_redirect', function () {
    $uri = $_SERVER['REQUEST_URI'] ?? '';
    if (isset($_GET['amp']) || preg_match('#/amp/?$#', $uri)) {
        $clean = preg_replace('#/amp/?$#', '/', $uri);
        $clean = remove_query_arg('amp', $clean);
        wp_redirect(home_url($clean), 301);
        exit;
    }
});

Omdirigeringen skal tre i kraft før du deaktiverer tillegget, eller i samme deploy. Et vindu der /amp/ gir 404 er unødvendig. Test et utvalg av de eksporterte URL-ene med curl -I og bekreft 301 og Location: mot den rene kanoniske adressen, uten AMP-sti og uten amp-parameter.

Behold reglene etter at tillegget er borte. Google crawler gamle AMP-adresser i månedsvis. En 301 som blir stående, koster ingenting. En 404 som kommer tilbake fordi noen ryddet «midlertidige» rewrite-regler, koster crawl-budsjett og forvirrer indeksen.

#Canonical-tagger og sitemap

Mens AMP levde, pekte standard sidene ofte rel="canonical" mot AMP-versjonen, eller AMP-versjonen kanoniserte seg selv. Hver side skal nå bære en selvrefererende canonical til den rene URL-en. Yoast og Rank Math fikser dette automatisk når AMP er borte, men verifiser et utvalg for hånd. Åpne kildekoden. Canonical skal være den adressen du står på, med samme protokoll og uten /amp/.

Regenerer XML-sitemap slik at den ikke lenger advertiserer AMP-URL-er. Send inn sitemap på nytt i Search Console. Hvis et eget AMP-sitemap finnes (noen tillegg laget et), fjern det fra Search Console og slutt å generere det.

Sjekk også interne lenker. Et gammelt innlegg som peker til /annet-innlegg/amp/ er en unødvendig hopp. Rett de du eier. 301 tar resten.

#Search Console etter fjerning

Etter at AMP er borte:

• Sjekk Sider-rapporten for 404 på gamle AMP-adresser.
• Verifiser omdirigeringer med en crawler (Screaming Frog eller tilsvarende) mot listen du eksporterte i trinn 1.
• Følg mobilbrukbarhet for nye feil som AMP tidligere skjulte.
• Gi Google to til fire uker på å reprosessere.

Den gamle AMP-rapporten i Search Console ble selv avviklet da Google sluttet å behandle AMP som noe eget. Det er statusen til formatet, skrevet av Google.

Ikke slett omdirigeringene etter fire uker. Fire uker er tiden du overvåker aktivt. Reglene skal ligge.

#Kort beslutningsliste

1. AMP-trafikk kartlagt, begge URL-varianter.
2. Kanoniske maler grønne på LCP, INP og CLS på mobil.
3. 301 på plass for /amp/ og ?amp=1.
4. Tillegget deaktivert og slettet, ikke bare slått av i en innstilling.
5. Canonical selvrefererende, sitemap uten AMP, Search Console oppdatert.

Hvis punkt 2 ikke er sant, stopp. Fjerning uten rask kanonisk mal er det eneste scenarioet der AMP-fjerning kan se ut som et trafikkfall. Fallet er da den trege malen, ikke omdirigeringen.

#Moderne stack 2026

Du trenger ikke AMP for å være rask. Å fjerne AMP hjelper bare hvis den native siden faktisk er rask, fordi AMP tvang gode vaner med regel og du nå må velge dem. Dette er stacken vi standardiserer på.

#Hosting og tid til første byte

Alt nedstrøms sitter oppå servertid. En delt vert som svarer første forespørsel på 800 ms, har allerede brukt mesteparten av LCP-budsjettet før en eneste byte optimalisert HTML når nettleseren. Sett origin på hosting som returnerer et cachet dokument godt under 200 ms, og bekreft det under last, ikke på en tom staging-boks. AMP skjulte treg hosting bak Googles cache. Når du serverer dine egne sider, er verten synlig igjen.

Full-page cache foran PHP er det som gjør TTFB stabil. Uten den maler WordPress hver anonyme treff gjennom bootstrap, spørringer og tema. AMP tok den kostnaden vekk ved å la Google eie HTML-en. Den ærlige erstatningen er at du eier HTML-en og cacher den selv.

#Bildeoptimalisering (AVIF)

AVIF gir meningsfullt mindre filer enn WebP ved samme opplevde kvalitet. Send AVIF med WebP-fallback og riktig srcset/sizes slik at hver enhet henter den oppløsningen den trenger. Bruk ShortPixel eller Imagify til å konvertere ved opplasting, eller konverter på kanten med Cloudflare Polish.

AMP krevde <amp-img> med eksplisitt bredde og høyde. Det var en god regel. Native HTML har den samme regelen uten komponenten: width, height og aspect-ratio på <img> og <picture>. CLS-gevinsten AMP solgte, ligger i å reservere plass, ikke i tagnavnet.

#Interaction to Next Paint (INP)

INP erstattet FID i mars 2024 og er metrikken de fleste WordPress-sider feiler på nå. Den måler hvor fort siden svarer på trykk eller klikk. Vanlig synder er tung tredjeparts-JavaScript som hogger hovedtråden. Utsett ikke-kritisk skript (chat, piksler, taggstyring) til første interaksjon, bruk requestIdleCallback, og fjern plugins som sprøyter inn render-blokkerende skript du ikke bruker.

AMP «løste» INP ved å forby koden. Det er ikke en løsning du kan ta med over. Du må ta stilling til hvert skript. Det er også derfor INP er mer ærlig enn AMP: den straffer den faktiske siden brukeren klikker på, ikke en parallell, avkledd visning.

#Cache og CDN

Du trenger ikke Googles AMP Cache. Du trenger din egen kantcache. Full-page caching servert fra en CDN nær brukeren (Cloudflare, Bunny.net) gjenskaper det meste av AMP-hastigheten uten å gi fra deg URL-en, med TTFB godt under 50 ms globalt når dokumentet treffer kanten. Legg objektcache (Redis) bak, slik at innloggede og dynamiske treff også holder seg raske.

Forskjellen mot AMP Cache er eierskap. HTML-en er din. Domenet i adresselinjen er ditt. Du kan sette cache-nøkler etter cookie, språk og innloggingsstatus. AMP Cache kunne det ikke, fordi den serverte én AMP-variant til alle.

#Kritisk CSS

Sett inn CSS som trengs over folden, og utsett resten, slik at første maleri ikke blokkeres av hele stilarket. WP Rocket og FlyingPress gjør dette automatisk. 75 KB-taket i AMP var en brutal versjon av samme idé: bare det du får plass til i dokumentet, får lov å styre første visning. Moderne kritisk CSS gjør jobben uten å forby resten av designsystemet.

#Fonter

Bruk font-display: swap, forhåndslast fontene i hero slik at tekst er synlig under last, subset til tegnene du faktisk bruker, og vurder systemfonter til brødtekst. AMP løste fontblink ved å kontrollere hele lasteløpet. Du løser det med preload og swap, uten å gi Google runtime.

#Speculation Rules for umiddelbar navigasjon

Dette er den ærlige erstatningen for AMP-forhåndshentingen. Speculation Rules API lar nettleseren forhåndsrendre neste sannsynlige side før brukeren klikker. Samme øyeblikkelige følelse, fra ditt origin, på din URL, uten rammeverk.

<script type="speculationrules">
{
  "prerender": [
    { "where": { "href_matches": "/*" }, "eagerness": "moderate" }
  ]
}
</script>

moderate er det fornuftige utgangspunktet. Aggressiv prerender av hele domenet koster båndbredde og kan kjøre analyse dobbelt. AMP Cache forhåndsvisning skjedde i Googles UI, på Googles regning. Speculation Rules skjer i brukerens nettleser, på din origin. Det er en bedre avtale, men den er ikke gratis. Mål.

Detaljene i LCP, INP og CLS på WordPress, felt mot lab, ligger i 100/100-guiden. Revisjonen som tar ut tredjepart fra hovedtråden og setter rekkefølge på malene, er Core Web Vitals-revisjonen.

#AMP ble aldri standard i norsk presse

Den internasjonale AMP-historien er en pressehistorie. I USA ble formatet en del av nyhetsstacken fordi Top Stories-karusellen krevde det. Store engelskspråklige utgivere, mange av dem på WordPress eller med WordPress i porteføljen, bygde AMP som en andre publiseringskanal ved siden av den kanoniske artikkelen. Lynet i søkeresultatet var distribusjon, ikke et plugin-eksperiment på en bedriftsside.

Norsk rikspresse satt ikke i det sporet.

VG, Aftenposten og NRK kjører ikke det offentlige nyhetsnettstedet på WordPress AMP. De tre er de sidene folk i Norge faktisk mener når de sier «pressen på nett». De lever på egne publiseringssystemer, bygget for nyhetsdesk, video, live og betaling, ikke på det offisielle AMP-tillegget fra WordPress.org. Hvis de noen gang sendte ut AMP, kom det som en eksport fra deres egen CMS, ikke som en parallell WordPress-mal slått på i wp-admin. Det er en annen arkitektur enn den amerikanske WordPress-AMP-historien, og den forskjellen styrer hva du faktisk finner når du åpner et norsk WordPress-nettsted i 2026.

Det du finner, er rest.

Et typisk norsk AMP-spor er ikke VG.no. Det er et bedriftsnettsted satt opp i 2017 eller 2018, ofte av et byrå, der noen slo på AMP-tillegget fordi et SEO-notat sa at mobil og Google krevde det. Temaet fikk en andre visning. Kontaktskjemaet sluttet å virke i AMP-malen, eller ble erstattet av en amp-form som aldri ble ferdig. /om-oss/amp/ og /blogg/innlegg/amp/ ligger fortsatt i Search Console. Canonical peker feil vei på et utvalg av sidene. Tillegget har ikke blitt rørt siden 2021, fordi ingen eier det, og fordi det «bare virker» i den forstand at det ikke kaster synlige feil i wp-admin.

Det er leftover plugin, ikke en nyhetsstack-standard.

Forskjellen betyr tre praktiske ting når du rydder.

For det første: du rydder ikke et redaksjonelt produksjonsløp. Du rydder et WordPress-tillegg og et sett URL-er. Det er mindre drama enn amerikanske AMP-fjerningsprosjekter der AMP var bundet til annonseoperasjon, nyhetsapp og Google News-feed. Det er også lettere å undervurdere, fordi det ser ut som «bare et plugin». Pluginet eier stier i indeksen. Stiene trenger 301.

For det andre: du skal ikke bruke VG, Aftenposten eller NRK som mal for om du «trenger AMP for å synes i nyheter». De tre er ikke WordPress-AMP-case, og Top Stories-kravet er uansett borte siden juni 2021. Et norsk magasin eller et bransjenett på WordPress konkurrerer ikke om karusellen ved å slå på AMP. Det konkurrerer ved å ha en kanonisk artikkel som møter Core Web Vitals, har synlig forfatter, og ikke serveres fra google.com/amp/....

For det tredje: internlenker og «relaterte saker» på norske WordPress-sider peker ofte til AMP-stien fordi tillegget skrev om permalinks eller fordi noen kopierte URL-en fra søkeresultatet i 2019. Det er ikke et pressesystem som genererer AMP fra en artikkel-ID. Det er rot i permalinks. Rett det i databasen og i 301-reglene, ikke ved å bygge en ny AMP-mal «fordi pressen gjør det». Pressen gjør det ikke, ikke på WordPress, og ikke som standard.

Et konkret spor du kan lete etter i en norsk installasjon:

• amp som query-parameter i tilgangslogger, ikke bare /amp/ i stien.
• Et barn-tema med amp-katalog som ingen har åpnet siden temaet ble levert.
• Yoast eller Rank Math med en rest av AMP-spesifikke innstillinger etter at selve AMP-tillegget er borte.
• En Google-cache-URL som fortsatt rangerer på merkevarenavnet, mens den kanoniske siden er raskere og likevel taper klikk fordi cache-URL-en er den gamle trefflinjen.

Ingen av delene er en nyhetsdesk. Alle er plugin-gjeld. Behandle dem som plugin-gjeld.

Sammenligningen med USA er nyttig bare som kontrast, ikke som reiseplan. Der var AMP en distribusjonskanal inn i Google-eide flater. Her var AMP et avkrysningsfelt i et WordPress-byråoppsett, kopiert fra engelske sjekklister. Sjekklistene ble utdaterte i juni 2021. Avkrysningsfeltet ble stående. Det er hele den norske AMP-historien for WordPress, og det er derfor fjerningen er et omdirigerings- og ytelsesprosjekt, ikke et redaksjonelt.

Hvis du eier et slikt nettsted, er jobben den samme som i avsnittene over. Den er ikke annerledes fordi Norge har VG og NRK. Den er annerledes fordi du sannsynligvis ikke har et eget AMP-team, ikke har AMP-annonseformater, og ikke har en nyhetsapp som leser AMP-HTML. Du har et tillegg, et sett 301-er og en kanonisk mal som må tåle mobil alene. Det er en mindre jobb enn det amerikanske post-mortemet antyder, og den blir ikke gjort ved å vente på at «pressen slutter med AMP». Pressen i denne betydningen sluttet aldri, fordi den aldri startet på WordPress AMP.

#AMP mot native

For et nytt eller eksisterende offentlig nettsted er valget ikke knapt. Det ene levende bruksområdet for teknologien er AMP for e-post: Gmail renderer fortsatt dynamiske AMP-e-poster der mottakeren kan svare, bla eller sende et skjema inne i meldingen uten å forlate innboksen. Det er et annet produkt enn web-AMP, det kjører på en annen runtime, og det rammes ikke av noe over. Hvis din eneste AMP-eksponering er et markedsteam som prøver interaktiv e-post, er det i orden og uten sammenheng med nettstedet.

Native vinner ikke fordi det er ideologisk «åpent». Native vinner fordi Google allerede belønner den samme hastigheten uten formatkravet, og fordi et WordPress-nettsted med skjema, innlogging og tredjepart ikke får plass i AMP uten å kaste funksjon. 75 KB CSS og forbud mot synkron egen JavaScript er ikke en disiplin du tar med over i 2026. Det er en grense som gjorde den andre malen nødvendig, og den andre malen er det du nå sletter.

Hvis noen i styret fortsatt siterer et SEO-notat fra 2018, er svaret én setning: Top Stories krevde AMP til juni 2021. Etter det teller LCP, INP og CLS på den URL-en du eier. Notatet er fem år ugyldig.

#Konklusjon

AMP-eksperimentet er over. Det åpne nettet vant. Avinstaller tillegget.

AMP løste et ekte 2016-problem og overlevde deretter vilkårene som rettferdiggjorde det. Core Web Vitals ga Google en nøytral måte å belønne hastighet på. Nettlesere fikk native API-er som gjenskaper AMP-følelsen. Moderne hosting gjorde raske standardsider til rutine. Byttet AMP ba om, kontroll over URL og kode mot hastighet, kjøper ingenting du ikke får på en annen måte.

Handlingsplanen er kort: mål AMP-trafikken, få de kanoniske malene gjennom Core Web Vitals, deaktiver tillegget, 301-omdiriger hver AMP-URL, reparer canonical og sitemap, og følg Search Console. Brukerne beholder den rikere opplevelsen. Utviklerne beholder ett kodegrunnlag.

I Norge er det ekstra grunn til å slutte å behandle AMP som «noe pressen gjør». VG, Aftenposten og NRK levde ikke på WordPress AMP. Det du rydder, er et leftover plugin på et bedriftsnettsted. Rydd det som plugin-gjeld.

Gå videre i Core Web Vitals-revisjonen hvis malen fortsatt er rød på mobil, og i guiden for 100/100 i 2026 hvis du skal sette rekkefølge på LCP, INP og CLS etter at AMP er borte.