Como o Google indexa ficheiros PDF e porque deve substituí-los por HTML no WordPress

#Como o Google converte ficheiros PDF em HTML durante a indexação

No episódio 115 do podcast oficial Search Off the Record, publicado a 13 de outubro de 2026, Martin Splitt e John Mueller, da equipa Search Relations da Google, explicaram como o Google Search trata os documentos em formato PDF. Em muitas empresas e lojas online persiste a ideia de que carregar um catálogo ou um guia técnico em PDF equivale a publicar uma página web convencional. O episódio mostra onde os dois formatos se parecem e onde não.

O HTML é um formato de texto. Um motor de pesquisa analisa o código HTML de forma sequencial, reconhecendo títulos, parágrafos, listas, dados estruturados em JSON-LD e diretivas semânticas.

O Portable Document Format (PDF) foi concebido com outro propósito: garantir que um documento mantém o seu aspeto visual exato quando é impresso ou apresentado em qualquer ecrã. Splitt sublinha que o PDF é um contentor binário: se abrir um PDF num editor de texto, vê caracteres ilegíveis, enquanto um ficheiro HTML ou Markdown se lê tal como está.

O Google não abre os PDF com um visualizador. Segundo Splitt, a indexação inclui um componente chamado conversor, que atua logo depois da renderização e imediatamente antes de um documento poder entrar no índice. O Google tem conversores para vários formatos (ficheiros de texto formatado, documentos, folhas de Excel e até documentos do Lotus Notes), e um deles é o conversor de PDF. O resultado é uma versão HTML do documento, o mais fiel possível ao original, porque o resto do pipeline web trabalha quase só com HTML.

+-----------------------------------------------------------------------------------+
| Percurso de um ficheiro PDF no Google Search (segundo o episódio 115):            |
| 1. Rastreio do ficheiro (HTTP Content-Type: application/pdf)                      |
| 2. Renderização                                                                   |
| 3. Conversor de PDF: gera uma representação HTML do documento                     |
| 4. As ligações dessa representação são descobertas como em qualquer página HTML    |
| 5. Indexação e ranking com os mesmos sistemas de uma página HTML                  |
+-----------------------------------------------------------------------------------+

Por isso, nas palavras de Splitt, a indexação e o ranking de um PDF são praticamente iguais aos de qualquer outro documento, e um PDF pode aparecer nas AI Overviews e no AI Mode. O Google não regista se um documento era originalmente um PDF. A lista oficial de tipos de ficheiro indexáveis inclui o PDF da Adobe entre os formatos codificados suportados.

Mueller acrescentou uma ressalva sobre documentos muito longos: um livro inteiro num único PDF levanta o mesmo problema que um livro inteiro numa só página HTML. O motor de pesquisa tem dificuldade em perceber que frase concreta justifica que o documento apareça para uma pesquisa.

#Que ficheiros PDF o Googlebot consegue ler e quando falha o OCR

O artigo do blog do Google Search Central sobre PDF, assinado por Gary Illyes, define a regra base: o Google consegue indexar o conteúdo textual de um PDF em qualquer língua e com várias codificações de caracteres, desde que o ficheiro não esteja protegido por palavra-passe nem cifrado. Se o texto estiver incorporado como imagens, o Google pode processar essas imagens com algoritmos de OCR.

No episódio 115, Splitt aponta como pior problema as páginas rasterizadas: documentos em que cada página é, na prática, uma imagem. Todo o conteúdo textual perde-se. Mueller acrescenta os livros digitalizados e arquivados em PDF: alguns sistemas conseguem aplicar OCR, mas não se pode contar com isso.

O teste que ambos propõem é simples:

1. Abra o PDF.
2. Selecione todo o texto com Ctrl + A ou Cmd + A.
3. Cole-o num documento do Google Docs ou num ficheiro de texto.
4. Se o texto aparecer, o Google pode usá-lo. Se não aparecer, o Google também não vê o conteúdo.

Splitt acrescenta que as páginas rasterizadas são também um problema de acessibilidade: os leitores de ecrã e outras tecnologias de apoio não as conseguem ler, a menos que o gerador do PDF tenha feito um esforço deliberado para incluir o conteúdo de forma acessível.

#Até que tamanho o Googlebot descarrega um ficheiro PDF

A documentação do Googlebot fixa dois limites diferentes. Para os tipos de ficheiro suportados, o Googlebot rastreia os primeiros 2 MB. Para um PDF, obtém os primeiros 64 MB. O limite mede-se sobre o conteúdo descomprimido, não sobre o tamanho transferido. Quando é atingido, o Googlebot interrompe a descarga e envia para indexação apenas a parte já descarregada.

No episódio, Splitt admitiu que não se lembrava do número exato para PDF e explicou porque é que a Google prefere não o fixar: o limite pode ser alterado e, se os editores começassem a publicar PDF muito maiores, a Google poderia aumentá-lo para não perder informação útil. A documentação é a fonte em vigor; o número pode mudar.

Na prática, o limite afeta poucos documentos. Um catálogo com fotografias em alta resolução pode aproximar-se dele, e nesse caso o texto das últimas páginas pode ficar fora do índice.

#Porque é que as ligações em PDF transmitem PageRank e as imagens não posicionam

#Comportamento das ligações de texto

Como o conversor gera uma versão HTML, as ligações do PDF mantêm-se. O blog do Google Search Central confirma-o: as ligações em ficheiros PDF são tratadas de forma semelhante às ligações HTML, podem transmitir PageRank e outros sinais de indexação, e o Google pode segui-las depois de rastrear o PDF.

• Transmissão de autoridade: as ligações dentro de um PDF podem transmitir PageRank às páginas de destino.
• Descoberta de novos caminhos: o Googlebot pode seguir os destinos detetados depois de rastrear o ficheiro.
• Sem nofollow: segundo o mesmo artigo, não é possível usar ligações nofollow dentro de um documento PDF.

Estas ligações têm uma desvantagem para quem mede resultados. Numa página web, os cliques são captados pelo Google Tag Manager ou pelo script de análise da página. Esse script não corre dentro de um PDF aberto no visualizador do navegador, por isso o que o leitor faz dentro do documento fica fora da sua análise.

#O problema das imagens incorporadas em PDF

Numa página web feita em WordPress ou Astro, cada fotografia é servida como um recurso independente, com URL próprio, atributo alt, dimensões explícitas e formatos modernos como AVIF ou WebP. Isso permite ao Google Imagens classificar cada imagem separadamente.

Num PDF, as imagens fazem parte do próprio ficheiro. Splitt explicou que o Google costuma passar os URL das imagens ao pipeline da pesquisa de imagens, e uma imagem dentro de um PDF não tem URL. A leitura dele é que o Google sabe que existe uma imagem, mas não a consegue processar como uma imagem normal para o Google Imagens, embora isso possa mudar. O artigo de 2011 era mais taxativo: as imagens dos ficheiros PDF não são indexadas e, para que o sejam, é preciso criar páginas HTML para elas.

Se a sua empresa publica infografias, diagramas de arquitetura ou comparações visuais apenas dentro de um PDF, não conte com tráfego vindo do Google Imagens.

#Porque é que o Google demora a ver as alterações de um PDF atualizado

Mueller explicou no episódio 115 que a frequência de rastreio dos PDF se parece com a das imagens. Os sistemas da Google não voltam a descarregar um PDF de poucos em poucos minutos, porque assumem que o ficheiro provavelmente não vai mudar durante muito tempo, e não querem descarregar muitos ficheiros grandes de um servidor, o que poderia causar problemas.

Splitt apontou outra diferença: um documento HTML edita-se facilmente num CMS, enquanto um PDF gerado não se altera sem uma ferramenta como o Adobe Acrobat Pro; o habitual é guardar o ficheiro de origem e gerar o PDF de novo.

Se alterar um catálogo de preços, um manual técnico ou um regulamento carregando uma nova versão com o mesmo nome e no mesmo URL, o excerto que o Google mostra e as respostas das AI Overviews podem continuar a basear-se na versão antiga durante bastante tempo. O Google não publica um prazo, por isso não há um número fiável para indicar.

#Como fazer o Google indexar mais cedo um documento PDF atualizado

A recomendação de Mueller é usar um novo nome de ficheiro. Quando o Google encontra uma ligação para esse URL novo, reconhece-o como um documento novo e rastreia-o e indexa-o. A isso juntamos, como prática nossa e não como indicação do Google, um redirecionamento 301 a partir do caminho antigo:

Estratégia de versões para evitar conteúdo desatualizado no índice:
Versão antiga:  https://oseudominio.pt/catalogos/especificacoes-tecnicas-2025.pdf
Nova versão:    https://oseudominio.pt/catalogos/especificacoes-tecnicas-2026-v2.pdf

Configuração do servidor:
Resposta HTTP 301 permanente do caminho antigo para a nova versão.
Ligações internas atualizadas para o novo URL.

Splitt completou o conselho com a cache HTTP: se sabe que um catálogo muda todos os trimestres, pode mantê-lo em cache durante alguns meses; se um ficheiro muda com frequência, a cache longa deixa de fazer sentido.

#Como controlar o título e os metadados de um PDF no Google

Um PDF não tem etiqueta HTML title. Segundo o blog do Google Search Central, o Google usa dois elementos principais para escolher o título apresentado nos resultados: o título guardado nos metadados do ficheiro e o texto âncora das ligações que apontam para o PDF. Para dar um sinal claro, o Google recomenda atualizar ambos.

Splitt acrescentou no episódio 115 que vale a pena preencher os metadados do PDF: quem é o autor, uma descrição do conteúdo e, se possível, uma ligação para o local de onde o documento provém. Mueller propôs um passo mais prático: colocar no cabeçalho do próprio PDF uma ligação normal para a página inicial do site. Quando o Google converte o PDF em HTML, essa ligação mantém-se, e quem chegar ao PDF a partir da pesquisa tem um caminho de volta ao seu site.

Num fluxo de trabalho com WordPress, isto significa:

1. Antes de carregar o PDF, verifique no programa que o gera os campos de título do documento, autor e descrição.
2. Ligue o PDF a partir de uma página HTML com texto âncora descritivo, e não com “descarregar” ou “aqui”.
3. Coloque na primeira página do PDF uma ligação visível para a página HTML a que pertence.

#Como configurar o cabeçalho HTTP Link rel canonical para documentos PDF

Quando uma organização disponibiliza um relatório como artigo web e como PDF descarregável, surge um risco de duplicação. Mueller descreveu no episódio um problema adicional: um PDF é um bloco binário. Se outro site descarregar o seu PDF e o publicar, o motor de pesquisa vê dois ficheiros idênticos byte a byte, e a canonicalização torna-se mais difícil do que com páginas HTML parecidas.

Numa página HTML, a versão preferida declara-se com a etiqueta link rel="canonical" dentro de head. Um PDF não tem essa secção. A documentação do Google sobre URL duplicados indica que, se puder alterar a configuração do servidor, pode usar o cabeçalho de resposta HTTP Link com rel="canonical", tal como definido no RFC 5988, incluindo para documentos que não são HTML, como os ficheiros PDF. O Google esclarece que este método só se aplica aos resultados da pesquisa web.

A mesma página deixa dois avisos que afetam os PDF. O Google não recomenda usar noindex para impedir que uma página seja escolhida como canónica dentro do mesmo site, porque a bloqueia por completo na pesquisa. E não se devem indicar URL canónicos diferentes para a mesma página com técnicas diferentes. Assim, para um PDF escolhe-se uma de duas opções:

• Canonical: o PDF continua acessível e os sinais consolidam-se na página HTML.
• Noindex: o PDF desaparece dos resultados (ver a secção seguinte).

#Configuração em servidores Nginx

location ~* \.pdf$ {
    # Ligação canónica para a versão HTML principal
    add_header Link '<https://oseudominio.pt/documentacao-tecnica/>; rel="canonical"';
}

#Configuração em servidores Apache (.htaccess)

Com o módulo mod_headers ativo:

<FilesMatch "\.pdf$">
    Header set Link '<https://oseudominio.pt/documentacao-tecnica/>; rel="canonical"'
</FilesMatch>

#Configuração no Cloudflare Pages e em redes de distribuição de conteúdos

No Cloudflare Pages e em plataformas de alojamento estático semelhantes, a regra vai no ficheiro _headers:

/documentos/*.pdf
  Link: <https://oseudominio.pt/documentacao-tecnica/>; rel="canonical"

Uma regra por padrão de ficheiros aponta todos os PDF para a mesma página. Se cada PDF tiver a sua própria página HTML, precisa de uma regra por ficheiro ou por pasta.

#Como remover um PDF dos resultados do Google

Segundo o blog do Google Search Central, a forma mais simples de impedir que um PDF apareça nos resultados é enviar o cabeçalho HTTP X-Robots-Tag: noindex com o ficheiro. Se o PDF já estiver indexado, vai desaparecendo com o tempo; para uma remoção mais rápida, o mesmo artigo remete para a ferramenta de remoção de URL da Search Console.

A documentação da meta etiqueta robots mostra este caso para todos os PDF de um site, com noindex, nofollow:

<Files ~ "\.pdf$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

Se quiser que o Google continue a usar as ligações do PDF para descobrir páginas, basta noindex: a mesma documentação explica que, sem a regra nofollow, o Google pode usar as ligações da página para descobrir as páginas ligadas.

Há outras duas vias, com efeitos diferentes:

• Palavra-passe: Splitt lembra que os motores de pesquisa não conseguem ler um PDF protegido por palavra-passe. Serve para documentos que não devem ser públicos.
• robots.txt: impede o Google de descarregar o PDF. Mas a documentação sobre URL duplicados avisa que o Google pode indexar URL bloqueados no robots.txt sem o respetivo conteúdo. Se o objetivo é que o ficheiro não apareça, o cabeçalho noindex é a ferramenta certa, e o Google só o vê se conseguir descarregar o ficheiro.

#Como o WordPress gere os PDF carregados na biblioteca multimédia

Quando carrega um PDF na biblioteca multimédia, o WordPress guarda o ficheiro em wp-content/uploads e cria um anexo na base de dados. Esse ficheiro é servido diretamente pelo servidor web (Nginx, Apache) ou pela CDN, sem carregar o WordPress. Este pormenor decide onde se configuram os cabeçalhos.

O hook send_headers é disparado em WP::send_headers() quando o WordPress processa um pedido. Um pedido direto a /wp-content/uploads/2026/10/catalogo.pdf nunca chega ao WordPress, por isso um código em functions.php que tente acrescentar um cabeçalho canonical a esse PDF não é executado. O cabeçalho só pode ser acrescentado a partir de PHP se um plugin entregar o ficheiro através do WordPress, e essa configuração tem o seu próprio custo. Para ficheiros estáticos, o cabeçalho configura-se no servidor ou na CDN, como na secção anterior.

O anexo gera também o seu próprio URL no WordPress: a página de anexo. A nota de desenvolvimento do WordPress 6.4 mudou o seu comportamento:

• Nas instalações novas, as páginas de anexos estão desativadas e redirecionam para o URL do ficheiro.
• A opção wp_attachment_pages_enabled controla este comportamento: vale 0 nas instalações novas e passa a 1 quando um site existente é atualizado, para que as páginas de anexos continuem a funcionar como antes.

Num site atualizado a partir de uma versão anterior à 6.4, cada PDF carregado pode ter, além do próprio ficheiro, uma página de anexo fraca e indexável. Verifique o valor da opção com o WP-CLI (wp option get wp_attachment_pages_enabled) antes de decidir se precisa de o alterar.

#Riscos dos plugins de exportação automática para PDF no WordPress

No ecossistema WordPress é comum usar plugins que acrescentam um botão de descarga em PDF a cada artigo. Estas extensões recorrem a bibliotecas PHP como Dompdf, TCPDF ou mPDF para converter o HTML do artigo num ficheiro PDF a pedido.

Mueller recordou no episódio 115 um caso dos primeiros CMS, possivelmente o Joomla, que permitia ver cada página como PDF. Como o Google não volta a rastrear esses ficheiros com frequência, o site podia acabar com o conteúdo antigo indexado como PDF e o novo como página HTML: as duas versões concorriam entre si e ainda estavam dessincronizadas. A conclusão dele: se o conteúdo é recente e dinâmico e precisa de oferecer um PDF, evite que esse PDF seja indexável.

Do ponto de vista de engenharia e de SEO, esta prática cria três problemas:

1. Duplicados no rastreio: cada artigo ganha um segundo URL com o mesmo texto. Os rastreadores gastam tempo a processar cópias em vez de conteúdo novo.
2. Carga no servidor: gerar um PDF a partir de HTML com estilos em PHP é uma operação pesada, e se um rastreador pedir muitas descargas em simultâneo, a carga recai sobre o PHP-FPM.
3. Perda de experiência de utilizador e de conversões: se a versão PDF ficar acima da página HTML nos resultados, o visitante chega a um documento estático sem formulários de contacto, navegação ou apelos à ação.

Splitt acrescentou que a maioria dos navegadores, em telemóvel e em computador, já permite guardar uma página como PDF, pelo que normalmente o dono do site não precisa de oferecer essa funcionalidade. Basta uma folha de estilos para impressão:

@media print {
  header, footer, nav, aside, .sidebar, .comments, .cookie-banner {
    display: none !important;
  }
  body {
    font-size: 12pt;
    color: #000;
    background: #fff;
  }
  a[href^="http"]:after {
    content: " (" attr(href) ")";
  }
}

Com esta regra, o utilizador que quer guardar o artigo usa a função de imprimir do navegador (Ctrl + P ou Cmd + P) e obtém um PDF limpo gerado no próprio dispositivo, sem gastar CPU do seu servidor.

#Porque é que o ficheiro llms.txt não deve ser publicado como PDF

A proposta llms.txt, publicada por Jeremy Howard em setembro de 2024, define um ficheiro Markdown no caminho /llms.txt com informação breve, orientações e ligações para ficheiros Markdown mais detalhados, pensado para oferecer conteúdo fácil de processar pelos modelos de linguagem.

O episódio 115 começa precisamente com esta pergunta. Mueller pergunta se faz sentido guardar o llms.txt como PDF, e Splitt responde que não: a ideia do llms.txt era disponibilizar o conteúdo aos modelos de linguagem da forma mais simples possível, e o PDF não é a forma mais simples de conteúdo na web. O facto de o Google conseguir processar PDF não significa que os outros consigam ou queiram.

O ficheiro llms.txt deve manter-se como um ficheiro de texto em Markdown na raiz do site (https://oseudominio.pt/llms.txt), com ligações para páginas ou ficheiros Markdown legíveis sem conversão.

#Quando faz sentido publicar um PDF no seu site

O episódio 115 não é uma acusação contra o PDF. Splitt enumera os casos em que o recomenda: quando o conteúdo tem requisitos de formatação específicos, quando tem de ter um aspeto muito concreto na impressão, ou quando precisa de formulários interativos. O exemplo dele é um alojamento que publica em PDF o formulário de registo dos hóspedes porque assim o processa com mais facilidade.

Sobre as ementas de restaurante, Mueller foi pragmático: uma ementa em PDF é melhor do que não ter ementa no site; entre um PDF e uma página normal, prefere a página, porque permite ampliar melhor, adapta-se ao telemóvel e carrega um pouco mais depressa. Se o texto do PDF puder ser selecionado e copiado, o Google pode usá-lo na pesquisa.

Sobre os sistemas de IA, Mueller acrescentou que na Google os PDF funcionam, que os viu citados também noutros sistemas de IA e que publicar em PDF não destrói a visibilidade nesses sistemas. Mas se o mesmo conteúdo puder estar em HTML, tudo fica um pouco mais fácil.

Splitt apontou ainda dois problemas de utilização em telemóvel: um PDF tem de ser descarregado por completo antes de ser apresentado, enquanto uma página HTML começa a mostrar conteúdo o mais depressa possível, e muitos PDF não reajustam o texto quando se amplia.

#Comparação técnica entre HTML semântico e ficheiros PDF estáticos

Exceto para documentos cuja finalidade principal seja a impressão, um formulário ou um formato fixo, o conteúdo que tem de posicionar e manter-se atualizado funciona melhor como página HTML.

#Plano de migração de documentos PDF para HTML no WordPress

Se a sua empresa acumula dezenas ou centenas de ficheiros PDF com informação técnica, fichas de produto ou manuais, uma migração ordenada para páginas HTML coloca esse conteúdo no formato que o Google rastreia com mais frequência e que os utilizadores leem melhor no telemóvel.

1. Inventário técnico: use uma ferramenta de rastreio para listar todos os ficheiros .pdf do servidor e verifique o tráfego orgânico atual no Google Search Console.
2. Teste de texto: aplique a cada PDF o teste de copiar e colar. Os documentos rasterizados são os primeiros candidatos a passar para HTML, porque hoje o Google não vê o seu conteúdo.
3. Reorganização de conteúdos:
   • Transfira a informação de maior valor para novas páginas em WordPress ou Astro, construídas com blocos semânticos.
   • Configure redirecionamentos permanentes 301 dos URL dos PDF antigos para as novas páginas HTML.
4. Canónicos para ficheiros indispensáveis: nos documentos que tenham de continuar disponíveis para descarga (formulários, modelos para preencher), acrescente o cabeçalho HTTP Link: <url>; rel="canonical" a apontar para a página web que explica o documento, ou X-Robots-Tag: noindex se não devem aparecer no Google. Nunca os dois ao mesmo tempo.
5. Metadados e ligação de volta: preencha título, autor e descrição dos PDF que ficam e acrescente na primeira página uma ligação para o seu site.
6. Páginas de anexos: verifique wp_attachment_pages_enabled se o site foi instalado antes do WordPress 6.4.
7. Desinstalação de geradores automáticos: desative os plugins de criação massiva de PDF e ofereça uma folha de estilos para impressão.
8. Ligações internas coerentes: ligue as novas páginas aos pilares principais da arquitetura do site, seguindo as recomendações da nossa auditoria de segurança WordPress e dos projetos de integração WooCommerce ERP.