O Google AMP morreu em 2026? (E o que usar em vez disso)

O relâmpago desapareceu. Em 2016, a Google lançou o AMP. Em 2026, o requisito para Top Stories desapareceu.

O AMP morreu? Sim. Deve usar-se num sítio WordPress? Não.

O AMP (Accelerated Mobile Pages) resolveu um problema real de 2015: páginas móveis inchadas, cheias de anúncios, que demoravam vários segundos a pintar no telemóvel. A Google ofereceu um formato restrito, uma cache própria e um sítio privilegiado no carrossel Top Stories. Durante uns anos o relâmpago nas SERP valeu tráfego. Essa barganha acabou. Em junho de 2021 a Google retirou o requisito de AMP das Top Stories. Os Core Web Vitals passaram a ser o sinal de desempenho. O INP substituiu o FID em março de 2024. O plugin oficial AMP para WordPress deixou de publicar versões relevantes e as instalações ativas que ainda restam no WordPress.org são inventário legado, não adoção nova.

Esta análise cobre o que o AMP era por dentro, porque falhou, como o retirar de um WordPress sem partir o posicionamento, que stack o substitui em 2026, e porque o resíduo que ainda aparece na Search Console em Portugal vive sobretudo nas redacções, não nas lojas.

#O AMP ainda é relevante em 2026

Não. O AMP já não é relevante para projectos WordPress novos em 2026. A Google removeu o requisito de AMP para Top Stories em 2021, e os Core Web Vitals substituíram o AMP como sinal primário de desempenho para posicionamento. O plugin AMP para WordPress perdeu cerca de 80% das descargas desde o pico.

O formato em si ainda funciona. A Google não desligou a cache (cdn.ampproject.org) nem o runtime. A posição oficial é que o AMP continua “suportado”, mas já não é recomendado nem obrigatório para nenhuma funcionalidade de pesquisa. Não há vantagem de ranking. Não há requisito de Top Stories. Qualquer URL que cumpra os limiares de Core Web Vitals pode aparecer no carrossel. Muitos editores grandes retiraram as implementações AMP e não reportaram perda de tráfego. O projecto recebe actualizações mínimas. Não saíram funcionalidades significativas desde 2023. Em 2025 o plugin oficial já não publicava uma versão há mais de um ano. Em 2026 o AMP está morto para projectos WordPress novos. As mais de 400 000 instalações ativas no WordPress.org são restos, não procura.

Se o sítio ainda corre AMP, a única pergunta útil é como o retirar em segurança. Se o sítio ainda nem existe, saltar o AMP e ir directo à stack moderna descrita mais abaixo.

A tabela contrasta o AMP com a engenharia web de 2026:

Há um único uso ainda vivo da tecnologia, e não é o sítio público: o AMP para e-mail. O Gmail ainda renderiza mensagens AMP dinâmicas, com RSVP, navegação ou envio de formulário dentro da caixa de correio. É um produto separado, com runtime diferente. Uma equipa de marketing a experimentar correio interactivo não justifica manter o plugin AMP no WordPress.

#Porque é que o AMP falhou

O objectivo era velocidade. A solução foi banir JavaScript. Esse enquadramento resolveu um problema real de 2015 e criou vários novos.

O AMP nunca foi uma linguagem à parte. Era um perfil constrangido de HTML com três peças a trabalhar em conjunto. Perceber essas peças explica o fim.

AMP HTML. Um subconjunto curado de etiquetas. Não se podia escrever um <script> próprio. Os elementos padrão eram substituídos por componentes AMP: <img> virava <amp-img>, iframes viravam <amp-iframe>, a analítica passava por <amp-analytics>, os carrosséis por <amp-carousel>, e o comportamento dinâmico era declarado com <amp-bind> e <amp-list> em vez de código imperativo. O CSS inline era permitido, mas com um tecto rígido (50 KB na especificação original, depois elevado a 75 KB). Folhas de estilo externas eram proibidas.

O runtime AMP (v0.js). Cada página AMP carregava uma única biblioteca alojada na Google. Geria o carregamento de recursos, dimensionava cada elemento antes da pintura para impedir deslocamentos de layout, e adiava o que estava abaixo da dobra. Como o runtime controlava o pipeline de renderização, as páginas AMP comportavam-se de forma previsível. Essa previsibilidade era o argumento de venda.

A cache AMP e o pré-carregamento. Esta é a peça que a maior parte das pessoas esquece. A Google não se limitava a posicionar páginas AMP: copiava-as para a CDN própria (cdn.ampproject.org) e pré-renderizava-as dentro dos resultados de pesquisa antes do toque. Por isso um resultado AMP parecia instantâneo: os bytes já estavam no edge da Google e parcialmente pintados fora do ecrã. A sensação de instante nunca foi só o formato. Foi o formato mais o prefetch da Google a partir da infraestrutura dela. Essa barganha, velocidade em troca de entregar as páginas à Google, é a semente de tudo o que correu mal.

#O compromisso

O custo foi alto:

1. Diluição da marca. Como as páginas saíam da cache da Google, o utilizador via google.com/amp/oseusitio.pt na barra de endereços, não o domínio próprio. Partilhar, copiar e o reconhecimento básico da marca partiam.
2. Assassino de conversão. O banimento de JavaScript que tornava as páginas previsíveis também as tornava inertes. Formulários de captura em vários passos, preços dinâmicos, checkouts condicionados e widgets de reservas de terceiros ou não funcionavam ou exigiam reescritas frágeis só para AMP. Num sítio de conteúdo isso era tolerável. Em qualquer funil era um imposto directo sobre receita.
3. Inferno de manutenção. O AMP quase sempre significava manter duas renderizações de cada template: a canónica em que os utilizadores reais aterravam, e a versão AMP que a Google servia. Dois caminhos de código, dois conjuntos de erros, duas passagens de QA por cada alteração.

#O problema do URL e os Signed Exchanges

A Google percebeu o dano do URL e passou anos a engenhar um remendo: Signed HTTP Exchanges (SXG), parte do esforço Web Packaging, que deixava a cache servir uma cópia assinada criptograficamente enquanto mostrava o URL real do editor. O SXG funcionava, mas era complexo, mal suportado fora do Chrome, e chegou depois de os editores já terem perdido a paciência. Tapar o problema do URL com criptografia dizia até onde o problema ia.

#A controvérsia do jardim vedado

Com o tempo o AMP pareceu menos um projecto de desempenho e mais uma alavanca. Uma queixa antitrust alargada, liderada por uma coligação de procuradores-gerais estaduais dos EUA, alegou que a Google usou o AMP para favorecer a própria bolsa de anúncios e atrasar formatos rivais. Seja qual for o mérito jurídico, a percepção pegou: um formato vendido como padrão aberto de velocidade encaminhava tráfego e receita publicitária para a empresa que controlava a cache.

#A mudança para Core Web Vitals

Em 2021 a Google introduziu os Core Web Vitals (CWV). A mensagem passou a ser: não interessa SE se usa AMP. Interessa que o sítio seja rápido.

Esta foi a sentença de morte do AMP. Se uma página responsiva padrão passa os limiares (LCP abaixo de 2,5 s, INP abaixo de 200 ms, CLS abaixo de 0,1), recebe o mesmo tratamento de ranking que o AMP um dia condicionava, sem nenhuma das restrições. Porque manter uma versão paralela restrita quando a original pode ser suficientemente rápida?

#A cronologia do declínio

#Porque é que os editores saíram na prática

O êxodo não foi um protesto coordenado. Foi a soma lenta de pequenas derrotas. Uma redacção descobria que o artigo AMP não corria o mesmo banner de consentimento que o sítio principal, por isso a conformidade de cookies precisava de uma segunda implementação. A equipa de anúncios via que um formato só AMP rendia menos do que a stack habitual. A analítica chegava via <amp-analytics> com um encadeamento de sessões ligeiramente diferente, e os números nunca batiam certo com o sítio canónico: cada relatório trimestral precisava de uma nota. A equipa de design pedia uma funcionalidade interactiva que os componentes AMP não cobriam, e a resposta era sempre a mesma: não no AMP. Cada atrito era suportável sozinho. Juntos significavam um produto paralelo inteiro para conservar um distintivo que a Google depois retirou.

#Remover o AMP em segurança

Se o WordPress ainda corre AMP, carrega-se o custo todo e nenhum do benefício antigo. A retirada é directa, mas os passos de redirecionamento e canónica são onde se perde posicionamento se se tiver pressa. Fazer por esta ordem.

#Passo 1: medir o tráfego AMP que realmente existe

Antes de tocar em qualquer coisa, abrir a analítica e a Search Console e quantificar quantas sessões e impressões ainda chegam a URL /amp/. Exportar a lista de URL AMP que ainda ganham impressões, para redirecionar os caminhos certos e vigiar regressões depois. Sem este inventário, desativar o plugin é apagar à cegas: uns caminhos passam a 404 e a Search Console avisa semanas mais tarde.

#Passo 2: confirmar primeiro que as canónicas são rápidas

Não retirar o AMP enquanto a template padrão for lenta. Isso troca uma página rápida mas restrita por uma lenta e livre. Correr as principais templates canónicas no PageSpeed Insights e confirmar que passam os Core Web Vitals no telemóvel. Corrigir a template primeiro, retirar o AMP depois. A ordem importa. Uma auditoria Core Web Vitals serve exactamente este ponto: medir LCP, INP e CLS nas canónicas com dados de campo, não só com o laboratório.

O AMP escondia alojamento lento atrás da cache da Google. Quando se passa a servir as próprias páginas, o servidor volta a ficar visível. Um alojamento partilhado que responde ao primeiro pedido em 800 ms já gastou a maior parte do orçamento de LCP antes de um único byte de HTML optimizado chegar ao browser. O origin tem de devolver um documento em cache bem abaixo de 200 ms, e isso confirma-se sob carga real, não num staging vazio.

#Passo 3: redirecionar cada URL AMP

URL AMP como /nome-do-artigo/amp/ têm de redirecionar para o original (redirecionamento 301). A variante de query string ?amp=1 precisa da sua própria regra. Esquecê-la deixa URL indexados a devolver 404 durante semanas, e esse é o maior risco de SEO de todo o processo.

Regra Nginx:

rewrite ^/(.*)/amp/?$ /$1/ permanent;

Apache (.htaccess):

RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]

WordPress (via plugin ou functions.php):

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

A regra de servidor cobre o caminho. O PHP cobre o parâmetro. As duas juntas. Testar um artigo, uma página e um arquivo antes de desativar o plugin: o 301 tem de apontar para a canónica limpa, não para um 302, não para um 404, não para uma cadeia de redirecionamentos.

#Passo 4: reparar canónicas e sitemaps

Com o AMP ligado, as páginas padrão muitas vezes apontavam o rel="canonical" para a versão AMP, ou a versão AMP auto-canonizava-se. Cada página tem agora de carregar uma canónica autorreferente para o URL limpo. Yoast e Rank Math tratam disto sozinhos quando o AMP sai, mas convém verificar uma amostra à mão. Regenerar o sitemap XML para deixar de anunciar URL AMP.

#Passo 5: monitorizar na Search Console

Depois de remover o AMP:

• Verificar o relatório de páginas por erros 404 nos antigos URL AMP
• Confirmar os redirecionamentos com Screaming Frog ou equivalente
• Vigiar o relatório de utilizabilidade móvel por problemas novos
• Dar duas a quatro semanas para a Google reprocessar

O relatório legado de AMP na Search Console foi ele próprio descontinuado quando a Google deixou de tratar o AMP como especial. Isso diz tudo sobre o estado do formato.

Lista rápida antes de desativar o plugin:

• As templates canónicas já passam LCP, INP e CLS no telemóvel com dados de campo? Se não, corrigir a template primeiro.
• Estão inventariados todos os URL /amp/ que ainda recebem impressões? Exportar antes de desativar.
• Os 301 cobrem caminho (/artigo/amp/) e parâmetro (?amp=1)?
• Cada página canónica aponta o rel="canonical" para si mesma, não para a antiga versão AMP?
• O sitemap já não anuncia URL AMP?

Cinco sim: a retirada é limpeza, não risco de posicionamento.

#Stack moderna 2026

Não é preciso AMP para ser rápido. Retirar o AMP só ajuda se o sítio nativo for genuinamente rápido, porque o AMP forçava bons hábitos por decreto e agora esses hábitos escolhem-se. A stack em que padronizamos está descrita com mais profundidade no guia para alcançar 100/100 Core Web Vitals em 2026. O resumo operacional cabe aqui.

#1. Alojamento e tempo até ao primeiro byte

Tudo o que vem a jusante assenta no tempo de resposta do servidor. Um alojamento partilhado a 800 ms no primeiro pedido já comeu o orçamento de LCP. Colocar o origin num alojamento que devolve um documento em cache bem abaixo de 200 ms, e confirmar sob carga. O AMP escondia o alojamento lento. Sem a cache da Google, o host fica exposto.

#2. Optimização de imagens (AVIF)

O AVIF entrega ficheiros claramente mais pequenos do que o WebP, com melhor qualidade. Servir AVIF com fallback WebP e srcset/sizes correctos para cada dispositivo descarregar só a resolução de que precisa. ShortPixel ou Imagify convertem no upload. Cloudflare Polish converte no edge.

<picture>
  <source srcset="imagem.avif" type="image/avif">
  <source srcset="imagem.webp" type="image/webp">
  <img src="imagem.jpg" alt="Descrição" width="1200" height="675" loading="lazy">
</picture>

#3. Interaction to Next Paint (INP)

O INP substituiu o FID em março de 2024 e é a métrica que mais sítios WordPress falham agora. Mede a rapidez com que a página responde a um toque ou clique. O culpado habitual é JavaScript de terceiros a monopolizar a thread principal: widgets de chat, pixels, gestores de etiquetas. Adiar scripts não críticos até à primeira interacção, usar requestIdleCallback, e remover plugins que injectam script a bloquear a renderização sem uso real.

#4. Cache e CDN

Não é precisa a cache AMP da Google. É precisa uma cache no edge própria. Cache de página completa servida de uma CDN perto do utilizador (Cloudflare, Bunny.net) reproduz a maior parte da vantagem de velocidade do AMP sem entregar o URL, com TTFB global claramente abaixo dos 50 ms em origens bem afinadas. Por trás, cache de objectos (Redis) para pedidos autenticados e dinâmicos continuarem rápidos.

#5. CSS crítico

Inlinar o CSS necessário ao conteúdo acima da dobra e diferir o resto, para a primeira pintura não ficar bloqueada pela folha de estilos completa. WP Rocket e FlyingPress tratam disto automaticamente.

#6. Optimização de fontes

Usar font-display: swap, pré-carregar as fontes do hero para o texto ser visível durante o carregamento, recortar as fontes aos caracteres realmente usados, e considerar uma stack de sistema para o corpo.

#7. Speculation Rules para navegação instantânea

Este é o substituto honesto do truque de prefetch do AMP. A Speculation Rules API deixa o browser pré-renderizar a próxima página provável antes do clique, com a mesma sensação de instante, a partir da origem própria, no URL próprio, sem framework.

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

#Comparação de desempenho

Valores típicos medidos em projectos com template canónica já afinada, frente a uma renderização AMP restrita da mesma propriedade. Não são uma promessa de score.

Medir com dados de campo, não só de laboratório. A pontuação do PageSpeed Insights é uma simulação num dispositivo e numa rede concretos. O que a Google usa para ranking são os dados reais dos utilizadores, agregados no relatório CrUX e visíveis no painel de Core Web Vitals da Search Console. Um sítio pode tirar 100 em laboratório e falhar INP em telemóveis reais de gama média. Depois de retirar o AMP, esperar pelo menos 28 dias antes de fechar conclusões: o CrUX trabalha com uma janela móvel de 28 dias.

#AMP contra nativo

Para um sítio público, novo ou existente, a decisão não é apertada. O único uso genuinamente vivo da tecnologia é o AMP para e-mail: o Gmail ainda renderiza correio AMP dinâmico. É um produto separado do AMP web, corre noutro runtime, e nada do que está acima o afecta. Se a única exposição restante ao AMP for uma equipa de marketing a experimentar correio interactivo, isso é irrelevante para a construção do sítio.

Manter o AMP em 2026 é pagar duas templates, diluir a marca, e ainda assim ser medido pelos mesmos LCP, INP e CLS que a página canónica. A página nativa bem feita ganha o ranking e a conversão. A página AMP bem feita só ganha a conversão se o utilizador nunca precisar de um formulário.

#AMP nas redacções .pt, não nas lojas

O resíduo de AMP que ainda aparece em propriedades WordPress portuguesas não está, na maior parte dos casos, nas lojas. Está nas redacções. Isso não é uma auditoria ao Público nem ao Expresso. É o padrão de mercado em que esses títulos se inscrevem: jornalismo nacional em WordPress (ou em CMS vizinho com endpoint AMP), historicamente dependente do carrossel Top Stories para a distribuição móvel das notícias de última hora. Entre 2016 e 2021, uma redacção que quisesse o relâmpago nas SERP tinha de servir AMP. Uma loja WooCommerce quase nunca teve esse incentivo.

Na Search Console de sítios de notícias .pt ainda se vê /amp/ no relatório de páginas. Artigos de 2018 com caminho /politica/nome-do-artigo/amp/, variantes ?amp=1, por vezes um lote “rastreado, não indexado” ao lado de outro ainda indexado. O plugin oficial, ou o modo AMP de um tema, foi instalado quando o relâmpago valia capa. Ninguém o retirou quando o relâmpago deixou de valer. A redacção mudou de director, o contrato de SEO mudou de agência, o WordPress foi actualizado dezenas de vezes, e o endpoint AMP sobreviveu porque ninguém o tinha na lista de desligamento.

Público e Expresso funcionam aqui como textura de mercado, não como clientes medidos nem como peças que tenhamos aberto. São o tipo de propriedade em que o AMP fez sentido: artigos longos, fotografia de capa, anúncios programáticos, consentimento de cookies, e uma redacção que publica dezenas de peças por dia. Nesse tipo de operação o AMP era um segundo produto. O banner de consentimento da canónica não cabia no runtime. A stack de anúncios habitual não cabia nos componentes AMP. O <amp-analytics> costurava sessões de outro modo, e o relatório trimestral da direcção vinha com um asterisco. Cada um destes atritos é o mesmo êxodo descrito acima, com sotaque de redacção portuguesa.

As lojas WooCommerce raramente embarcaram. A montra de uma loja não é um artigo: é grelha de produto, variação, carrinho, cálculo de portes, checkout, área de cliente. Tudo isso pede JavaScript próprio. O AMP proibia-o. Um tema Woo com modo AMP acabava por servir uma ficha de produto estática, sem adicionar ao carrinho de forma fiável, e a loja desligava o modo ao fim de uma sprint. Por isso o inventário AMP que ainda se encontra em GSC .pt é um artefacto de jornalismo, não um artefacto de comércio. Procurar /amp/ numa loja Woo costuma devolver zero URL com impressões. Procurar o mesmo num sítio de notícias costuma devolver uma lista.

A implicação prática é estreita. Se a propriedade é uma redacção WordPress .pt e a Search Console ainda lista /amp/, o trabalho é o protocolo desta peça: inventário, Core Web Vitals nas canónicas, 301 de caminho e de parâmetro, canónicas autorreferentes, sitemap limpo, duas a quatro semanas de vigia. Se a propriedade é uma loja, o AMP quase de certeza nunca esteve ligado de forma útil, e o tempo vai para LCP da ficha, INP do carrinho e CLS da montra, não para um plugin que a loja nunca chegou a adoptar. Tratar uma loja como se fosse uma redacção, ou uma redacção como se fosse uma loja, é o erro de diagnóstico.

Há um detalhe de conformidade que as redacções sentem e as lojas quase não: o aviso de cookies. Uma redacção portuguesa precisa do mesmo texto e do mesmo registo de consentimento na canónica e, enquanto o AMP viver, numa segunda implementação declarativa. Isso duplica trabalho jurídico e técnico. Quando o AMP sai, o aviso volta a ter um só sítio. Não é o motivo principal para retirar o plugin, mas é o motivo que o director de informação percebe mais depressa do que LCP.

Nada disto afirma que um título concreto ainda sirva AMP hoje. Afirma que o sítio onde o AMP ainda aparece, em Portugal, é o sítio onde o AMP um dia foi obrigatório: a redacção, não a loja.

#Conclusão

O ensaio AMP acabou. A web aberta ganhou. Desinstalar o plugin.

O AMP resolveu um problema real de 2016 e depois sobreviveu às condições que o justificavam. Os Core Web Vitals deram à Google uma forma neutra de recompensar velocidade. Os browsers enviaram API nativas que reproduzem a sensação de instante do AMP. O alojamento moderno tornou páginas padrão rápidas uma rotina. A troca que o AMP pedia, o controlo do URL e do código em troca de velocidade, já não compra nada que não se obtenha de outro modo.

O plano de acção é curto: medir o tráfego AMP, fazer as templates canónicas passarem os Core Web Vitals, desativar o plugin, redirecionar com 301 cada URL AMP, reparar canónicas e sitemaps, vigiar a Search Console. Os utilizadores ficam com a experiência mais rica. Os programadores ficam com um único código.

Em Portugal, começar pela Search Console e perguntar se os /amp/ que ainda restam pertencem a uma redacção. Se sim, o protocolo acima fecha o ciclo. Se a propriedade é uma loja, o tempo vai para a stack nativa, não para um formato que a montra quase nunca usou.

A auditoria Core Web Vitals e o guia completo 100/100 são o passo seguinte quando a canónica ainda não passa os limiares.