Pagine AMP e SEO: ha ancora senso usarle nel 2026?

Le pagine AMP non danno più nessun vantaggio di posizionamento diretto, ed è una domanda legittima perché per anni non è stato così: tra il 2016 e il 2021 Google ha reso l'AMP una condizione per apparire nel carosello Top Stories su mobile, quindi molte redazioni italiane l'hanno adottata non per convinzione tecnica ma perché altrimenti restavano fuori da uno spazio di traffico enorme. Quel vincolo è stato rimosso nel 2021, quando Google ha eliminato il requisito AMP per Top Stories e ha introdotto l'esperienza di pagina come fattore di ranking: da quel momento qualsiasi pagina idonea, con o senza AMP, può comparire nel carosello.

Il risultato è che oggi molti siti — soprattutto testate giornalistiche e negozi online che l'hanno introdotta nella prima ondata — si trovano con un'infrastruttura AMP che non serve più lo scopo per cui era nata, ma che continuano a mantenere per inerzia o per paura di perdere traffico nel passaggio. Questo articolo affronta due domande separate: se AMP porti ancora qualcosa dal punto di vista SEO, e come dismetterla senza rischi — redirect, canonical, continuità dei dati analytics — per chi decide che è arrivato il momento di farlo.

Cosa è cambiato dal requisito Top Stories a oggi

Fino al 2021 l'equazione era semplice: niente AMP, niente carosello Top Stories su mobile. Era un requisito esplicito, non un'inferenza SEO: la documentazione di Google per Top Stories elencava l'AMP come condizione tecnica per l'inclusione, insieme a criteri editoriali come la data di pubblicazione visibile e l'autore identificabile. Questo ha spinto moltissimi editori a costruire in fretta una versione AMP parallela del sito, spesso con un team diverso da quello che gestiva il tema principale: risultato, due codebase da mantenere per lo stesso contenuto.

Nel 2021 Google ha annunciato che il page experience update, basato sui Core Web Vitals, sarebbe diventato un fattore di ranking anche per Top Stories, e che il requisito AMP sarebbe stato eliminato. Da allora una pagina non-AMP idonea può entrare nel carosello esattamente come una pagina AMP, senza dover superare una soglia minima di Core Web Vitals. Il badge a forma di fulmine che segnalava i risultati AMP nella SERP mobile è stato rimosso già in quella fase, quindi anche il segnale visivo che un tempo distingueva le pagine AMP agli occhi dell'utente non esiste più.

• Il requisito AMP per apparire nel carosello Top Stories è stato eliminato e l'esperienza di pagina è diventata un fattore di ranking
• Il badge a fulmine che nella SERP mobile segnalava i risultati AMP è stato rimosso
• L'AMP Cache di Google continua a funzionare per le pagine AMP esistenti, ma non è più un prerequisito per nessuna superficie di ricerca

Perché AMP non è mai stato un fattore di ranking a sé

È importante distinguere due cose che spesso vengono confuse: un requisito di eleggibilità per un carosello specifico e un fattore di ranking generale. AMP non ha mai fatto parte dell'algoritmo di ranking organico standard: una pagina AMP non batteva una pagina non-AMP identica solo per il fatto di essere AMP. Quello che AMP garantiva, per costruzione, era il rispetto di soglie di performance stringenti, perché il framework limita deliberatamente cosa uno sviluppatore può fare — niente JavaScript custom bloccante, immagini con dimensioni dichiarate obbligatorie, componenti come amp-img che gestiscono il caricamento in modo asincrono, e distribuzione tramite la cache di Google che pre-carica la pagina prima ancora che l'utente tocchi il link nei risultati di ricerca.

Il beneficio di ranking indiretto veniva quindi dalla velocità, non dal framework in sé. Ed è esattamente il motivo per cui oggi l'AMP ha smesso di essere necessaria: gli stessi risultati di performance si ottengono con tecniche disponibili su qualsiasi stack — dichiarare width e height (o usare aspect-ratio in CSS) su ogni immagine, precaricare i font critici con rel=preload, differire ogni script non essenziale al rendering del contenuto principale, e servire gli asset statici da un CDN con edge caching che replica quello che l'AMP Cache di Google faceva in automatico. La differenza è che con AMP questi comportamenti erano imposti dal framework; senza AMP vanno progettati e mantenuti dal team.

• Dimensionare sempre le immagini (width/height o aspect-ratio) per evitare Cumulative Layout Shift
• Precaricare font e risorse critiche above-the-fold con rel=preload
• Rimandare o rendere asincrono ogni script di terze parti non necessario al primo rendering
• Usare un CDN con cache agli edge per ottenere tempi di risposta comparabili a quelli dell'AMP Cache

I costi di mantenere AMP oggi

Chi ha ancora AMP attiva sostiene, di fatto, due versioni del sito. Ogni redesign del tema, ogni nuovo componente nel layout degli articoli, ogni modifica alla gestione del consenso cookie va replicata e testata sia sulla versione canonica che su quella AMP, perché il template AMP non condivide il motore di rendering della pagina principale: usa componenti dedicati (amp-img, amp-carousel, amp-sidebar) con un validatore che rifiuta qualsiasi markup non conforme. Un cambiamento che su una pagina normale richiede un'ora di lavoro, su AMP può richiederne il doppio.

C'è poi un problema meno visibile ma altrettanto concreto sugli analytics. Le pagine AMP servite dalla cache di Google vivono, dal punto di vista del browser, su un'origine diversa dal vostro dominio, quindi il tracciamento richiede il componente amp-analytics con una configurazione a parte rispetto al tag di misurazione usato sul resto del sito. Se le due configurazioni non sono allineate — stesso ID di proprietà, stessi eventi custom — finite con due flussi di dati che raccontano storie leggermente diverse sulla stessa pagina, e riconciliarli a posteriori è un lavoro che nessuno ha voglia di fare quando i numeri già non tornano.

• Due template da mantenere sincronizzati a ogni redesign
• Un validatore AMP che rifiuta script e markup non conformi, limitando test A/B e nuovi formati pubblicitari
• Tracciamento analytics separato (amp-analytics) da riconciliare con la misurazione standard del sito
• Gestione del consenso cookie più rigida, perché non tutti i CMP hanno un'integrazione AMP nativa

Quando ha ancora senso tenerla, e come verificarlo senza darlo per scontato

Ci sono casi in cui spegnere AMP oggi è prematuro. Il più comune: un sito con un frontend molto pesante lato JavaScript, dove portare la versione non-AMP allo stesso livello di LCP e INP della versione AMP richiede una ristrutturazione che non è ancora stata pianificata. In quel caso AMP resta, temporaneamente, la versione più veloce che gli utenti mobile vedono, e spegnerla prima di aver risolto il problema di performance sul sito principale significa peggiorare l'esperienza reale, non solo un numero su un report.

La decisione non va presa a intuito: va misurata. Search Console e PageSpeed Insights riportano i dati di campo del Chrome UX Report separatamente per URL AMP e per URL canonico. Il confronto va fatto pagina per pagina, non a livello di sito, perché una homepage ottimizzata e un articolo con dieci embed di terze parti possono avere esiti opposti. Se la versione non-AMP delle pagine con più traffico eguaglia o supera già i valori della versione AMP sulle stesse metriche di campo, non c'è più una ragione funzionale per tenerla.

Come dismettere AMP senza perdere traffico: redirect, canonical e analytics

Dismettere AMP male produce due danni concreti e visibili in Search Console nel giro di pochi giorni: pagine che finiscono in errore 404 perché qualcuno aveva un link diretto o un salvataggio nei preferiti verso l'URL AMP, e un buco temporaneo nei dati di traffico perché l'attribuzione si rompe a metà passaggio. Dismetterla bene richiede un ordine preciso di operazioni, non solo le operazioni giuste.

Il primo passo, prima ancora di toccare redirect o tag, è portare la versione canonica allo stesso livello di performance della versione AMP sulle pagine a più alto traffico, altrimenti si sta scambiando una pagina rapida con una più lenta, e quello sì è un rischio SEO reale, indipendentemente da AMP. Verificate LCP, INP e CLS sulle pagine canoniche con lo stesso volume di dati di campo usato per la versione AMP, e chiudete il gap prima di procedere con la dismissione.

Una volta raggiunta la parità, impostate un redirect 301 permanente da ogni URL AMP al corrispondente URL canonico, un mapping uno a uno, mai un redirect generico verso la homepage: un redirect che non porta l'utente e il crawler sulla pagina equivalente perde tutto il valore che quella pagina aveva accumulato. Se AMP è generata da un plugin del CMS, il plugin normalmente gestisce anche il routing delle URL /amp/: disattivarlo prima di aver messo in produzione i redirect lascia quelle URL a rispondere con un errore nel frattempo, quindi l'ordine corretto è redirect prima, disattivazione del plugin dopo, mai il contrario.

Rimuovete anche il tag link rel amphtml dalle pagine canoniche: se lo lasciate attivo dopo aver eliminato la pagina AMP a cui punta, state dicendo a Google di cercare una risorsa che non esiste più, il che genera solo rumore in fase di scansione. Sulla pagina AMP stessa, prima di eliminarla, il tag canonical dovrebbe già puntare alla versione non-AMP: verificate che quella coppia sia coerente su tutto il sito prima di procedere.

Sul fronte analytics, il redirect 301 lato server preserva referrer e pagina di destinazione nei report, a differenza di un redirect via JavaScript, che perde questi dati per gli utenti con script bloccati o troppo lenti. Prima di spegnere amp-analytics, controllate che la proprietà di misurazione a cui punta sia la stessa, o venga riconciliata, con quella del sito principale. In Search Console non rimuovete manualmente le URL AMP dall'indice: lasciate che il redirect le faccia deindicizzare nel giro di alcune settimane, e monitorate il report sulle pagine per confermare che le impression si spostino dalle vecchie URL a quelle canoniche invece di sparire.

Infine, non spegnete tutto in un giorno. Fate un rollout scaglionato, una sezione del sito e poi un'altra, e osservate per un paio di settimane l'andamento di posizionamento e Core Web Vitals su quella sezione prima di estendere la dismissione al resto. Se qualcosa non torna, la superficie di errore è contenuta e reversibile; se lo fate su tutto il sito insieme, un problema di configurazione nei redirect diventa un incidente su scala intera.

• Portare la versione non-AMP alla parità di performance sulle pagine chiave prima di toccare qualsiasi redirect
• Redirect 301 uno a uno da ogni URL AMP alla corrispondente URL canonica, mai verso la home
• Disattivare il plugin o il generatore AMP solo dopo che i redirect sono già in produzione
• Rimuovere il tag amphtml dalle pagine canoniche e verificare la coerenza dei canonical residui
• Riconciliare o migrare la configurazione analytics prima di spegnere amp-analytics
• Rollout scaglionato per sezione del sito, non un taglio unico su tutto il dominio

Errori comuni durante la dismissione

La maggior parte dei problemi che emergono dopo una migrazione da AMP non nasce da un errore di strategia ma da un errore di sequenza: le operazioni giuste fatte nell'ordine sbagliato.

• Disattivare AMP prima che i redirect siano in produzione, generando errori su link storici, email già inviate e risultati ancora in cache nei motori di ricerca
• Lasciare i tag amphtml e canonical incoerenti dopo la rimozione, confondendo la scansione e sprecando budget di crawl su risorse inesistenti
• Cambiare l'identificativo di misurazione analytics nello stesso momento della dismissione, rendendo impossibile confrontare il traffico prima e dopo
• Rimuovere manualmente le URL AMP da Search Console invece di lasciare che il redirect le deindicizzi, perdendo la possibilità di verificare che il traffico si sia davvero trasferito
• Tagliare AMP su tutto il sito in un solo giorno invece che per sezioni, trasformando un problema di configurazione locale in un incidente sitewide