Cómo Google indexa archivos PDF y por qué deberías convertirlos a HTML en WordPress

#Cómo convierte Google los archivos PDF en HTML durante la indexación

En el episodio 115 del podcast oficial Search Off the Record, publicado el 13 de octubre de 2026, Martin Splitt y John Mueller, del equipo Search Relations de Google, explicaron cómo trata Google Search los documentos en formato PDF. En muchas empresas y tiendas electrónicas persiste la creencia de que subir un catálogo o una guía técnica en PDF equivale a publicar una página web convencional. El episodio muestra dónde se parecen y dónde no.

El lenguaje HTML es un formato de texto. Un motor de búsqueda analiza el código HTML de manera secuencial, reconociendo títulos, párrafos, listas, datos estructurados en formato JSON-LD y directivas semánticas.

El formato Portable Document Format (PDF) se diseñó con otro propósito: garantizar que un documento mantenga su diseño visual exacto al imprimirse o visualizarse en cualquier pantalla. Splitt subraya que el PDF es un contenedor binario: si abres un PDF en un editor de texto, ves caracteres ilegibles, mientras que un archivo HTML o Markdown se puede leer a simple vista.

Google no abre los PDF con un visor. Según Splitt, la indexación incluye un componente llamado conversor, que actúa justo después del renderizado y justo antes de que un documento pueda entrar en el índice. Google tiene conversores para varios formatos (archivos de texto enriquecido, documentos, hojas de Excel e incluso documentos de Lotus Notes), y uno de ellos es el conversor de PDF. Su resultado es una versión HTML del documento, lo más fiel posible al original, porque el resto del pipeline web trabaja casi exclusivamente con HTML.

+-----------------------------------------------------------------------------------+
| Recorrido de un archivo PDF en Google Search (según el episodio 115):             |
| 1. Rastreo del archivo (HTTP Content-Type: application/pdf)                       |
| 2. Renderizado                                                                    |
| 3. Conversor de PDF: genera una representación HTML del documento                 |
| 4. Los enlaces de esa representación se descubren como en cualquier página HTML    |
| 5. Indexación y ranking con los mismos sistemas que una página HTML               |
+-----------------------------------------------------------------------------------+

Por eso, en palabras de Splitt, la indexación y el ranking de un PDF son prácticamente iguales a los de cualquier otro documento, y un PDF puede aparecer en AI Overviews y en AI Mode. Google no registra si un documento era originalmente un PDF. La lista oficial de tipos de archivo indexables incluye el PDF de Adobe entre los formatos codificados admitidos.

Mueller añadió un matiz sobre los documentos muy largos: un libro entero en un único PDF plantea el mismo problema que un libro entero en una sola página HTML. El buscador tiene dificultades para saber qué frase concreta justifica que el documento aparezca para una consulta.

#Qué archivos PDF puede leer Googlebot y cuándo falla el OCR

El artículo del blog de Google Search Central sobre PDF, firmado por Gary Illyes, establece la regla básica: Google puede indexar el contenido textual de un PDF en cualquier idioma y con distintas codificaciones de caracteres, siempre que el archivo no esté protegido con contraseña ni cifrado. Si el texto está incrustado como imagen, Google puede procesar esas imágenes con algoritmos de OCR.

En el episodio 115, Splitt señala como el peor problema las páginas rasterizadas: documentos en los que cada página es, en la práctica, una imagen. En ese caso se pierde todo el contenido textual. Mueller añade el caso de los libros escaneados y archivados en PDF: algunos sistemas pueden aplicar OCR, pero no se puede contar con ello.

La prueba que proponen ambos es sencilla:

1. Abre el PDF.
2. Selecciona todo el texto con Ctrl + A o Cmd + A.
3. Pégalo en un documento de Google Docs o en un archivo de texto.
4. Si el texto aparece, Google puede usarlo. Si no aparece, Google tampoco ve el contenido.

Splitt añade que las páginas rasterizadas también son un problema de accesibilidad: los lectores de pantalla y otras tecnologías de apoyo no pueden leerlas, salvo que el generador del PDF haya hecho un esfuerzo expreso por incluir el contenido de forma accesible.

#Hasta qué tamaño descarga Googlebot un archivo PDF

La documentación de Googlebot fija dos límites distintos. Para los tipos de archivo admitidos, Googlebot rastrea los primeros 2 MB. Para un PDF, descarga los primeros 64 MB. El límite se mide sobre el contenido descomprimido, no sobre el tamaño transferido. Cuando se alcanza, Googlebot detiene la descarga y envía a indexación solo la parte ya descargada.

En el episodio, Splitt admitió que no recordaba la cifra exacta para PDF y explicó por qué Google prefiere no fijarla en piedra: el límite se puede cambiar y, si los editores empezaran a publicar PDF mucho mayores, Google podría ampliarlo para no perder información útil. La documentación es la fuente vigente; la cifra puede cambiar.

En la práctica, el límite afecta a pocos documentos. Un catálogo con fotografías en alta resolución sí puede acercarse a él, y en ese caso el texto de las últimas páginas puede quedar fuera del índice.

#Por qué los enlaces en PDF transmiten PageRank pero las imágenes no posicionan

#Comportamiento de los enlaces de texto

Como el conversor genera una versión HTML, los enlaces del PDF se conservan. El blog de Google Search Central lo confirma: los enlaces en archivos PDF se tratan de forma parecida a los enlaces HTML, pueden transmitir PageRank y otras señales de indexación, y Google puede seguirlos después de rastrear el PDF.

• Traspaso de autoridad: los enlaces dentro de un PDF pueden transmitir PageRank a las páginas de destino.
• Descubrimiento de nuevas rutas: Googlebot puede seguir los destinos detectados después de rastrear el archivo.
• Sin nofollow: según el mismo artículo, no es posible usar enlaces nofollow dentro de un documento PDF.

Estos enlaces tienen una desventaja para quien mide resultados. En una página web, los clics se capturan con Google Tag Manager o con el script de analítica de la página. Ese script no se ejecuta dentro de un PDF abierto en el visor del navegador, así que lo que hace el lector dentro del documento queda fuera de tu analítica.

#El problema de las imágenes incrustadas en PDF

En una página web basada en WordPress o Astro, cada fotografía se sirve como un recurso independiente con su propia URL, atributo alt, dimensiones explícitas y formatos modernos como AVIF o WebP. Eso permite que Google Imágenes clasifique cada imagen por separado.

En un documento PDF, las imágenes forman parte del propio archivo. Splitt explicó que Google suele pasar las URL de las imágenes al pipeline de búsqueda de imágenes, y que una imagen dentro de un PDF no tiene URL. Su interpretación es que Google sabe que hay una imagen, pero no puede procesarla como una imagen normal para Google Imágenes, aunque eso podría cambiar. El artículo de 2011 era más tajante: las imágenes de los PDF no se indexan, y para que se indexen hay que crear páginas HTML para ellas.

Si tu empresa publica infografías, diagramas de arquitectura o comparativas visuales solo dentro de un PDF, no cuentes con que generen tráfico desde Google Imágenes.

#Por qué Google tarda en ver los cambios de un PDF actualizado

Mueller explicó en el episodio 115 que la frecuencia de rastreo de los PDF se parece a la de las imágenes. Los sistemas de Google no vuelven a descargar un PDF cada pocos minutos, porque asumen que el archivo probablemente no cambiará en mucho tiempo, y no quieren descargar muchos archivos grandes de un servidor, lo que podría causar problemas.

Splitt añadió otra diferencia: un documento HTML se edita fácilmente desde un CMS, mientras que un PDF generado no se puede editar sin una herramienta como Adobe Acrobat Pro; lo habitual es conservar el archivo original y volver a generar el PDF.

Si modificas un catálogo de precios, un manual técnico o una normativa subiendo una nueva versión con el mismo nombre y en la misma URL, el fragmento que muestra Google y las respuestas de AI Overviews pueden seguir basándose en la versión antigua durante bastante tiempo. Google no publica un plazo, así que no hay una cifra fiable que dar.

#Cómo conseguir que Google indexe antes un documento PDF actualizado

La recomendación de Mueller es usar un nombre de archivo nuevo. Cuando Google encuentra un enlace a esa URL nueva, la reconoce como un documento nuevo y la rastrea e indexa. A eso añadimos, como práctica propia y no como indicación de Google, una redirección 301 desde la ruta antigua:

Estrategia de versionado para evitar contenido obsoleto en el índice:
Versión antigua:  https://midominio.es/catalogos/especificaciones-tecnicas-2025.pdf
Nueva versión:    https://midominio.es/catalogos/especificaciones-tecnicas-2026-v2.pdf

Configuración en el servidor:
Respuesta HTTP 301 permanente desde la ruta antigua hacia la nueva versión.
Enlaces internos actualizados a la nueva URL.

Splitt completó el consejo con la caché HTTP: si sabes que un catálogo cambia cada trimestre, puedes mantenerlo en caché durante un par de meses; si un archivo cambia con frecuencia, la caché larga pierde sentido.

#Cómo controlar el título y los metadatos de un PDF en Google

Un PDF no tiene etiqueta title de HTML. Según el blog de Google Search Central, Google usa dos elementos principales para elegir el título que muestra en los resultados: el título guardado en los metadatos del archivo y el texto ancla de los enlaces que apuntan al PDF. Para dar una señal clara, Google recomienda cuidar ambos.

Splitt añadió en el episodio 115 que conviene rellenar los metadatos del PDF: quién es el autor, una descripción del contenido y, si es posible, un enlace al lugar del que procede el documento. Mueller propuso un paso más práctico: incluir en la cabecera del propio PDF un enlace normal a la página de inicio del sitio. Cuando Google convierte el PDF en HTML, ese enlace se conserva, y quien llegue al PDF desde la búsqueda tendrá un camino de vuelta a tu web.

En la práctica, en un flujo de WordPress esto significa:

1. Antes de subir el PDF, revisa en el programa que lo genera el campo de título del documento, el autor y la descripción.
2. Enlaza el PDF desde una página HTML con un texto ancla descriptivo, no con “descargar” o “aquí”.
3. Pon en la primera página del PDF un enlace visible a la página HTML de la que forma parte.

#Cómo configurar la cabecera HTTP Link rel canonical para documentos PDF

Cuando una organización ofrece un informe tanto como artículo web como en PDF descargable, surge un riesgo de duplicidad. Mueller describió en el episodio un problema adicional: un PDF es un bloque binario. Si otra web descarga tu PDF y lo publica, el buscador ve dos archivos idénticos byte a byte, y la canonicalización resulta más difícil que con páginas HTML parecidas.

En una página HTML, la versión preferida se declara con la etiqueta link rel="canonical" dentro de head. Un PDF no tiene esa sección. La documentación de Google sobre URL duplicadas indica que, si puedes cambiar la configuración del servidor, puedes usar la cabecera de respuesta HTTP Link con rel="canonical", tal como la define el RFC 5988, incluso para documentos no HTML como los PDF. Google precisa que este método solo se aplica a los resultados de la búsqueda web.

La misma página da dos advertencias que afectan a los PDF. No conviene usar noindex para impedir que una página se elija como canónica dentro del mismo sitio, porque la bloquea por completo en la búsqueda. Y no se deben indicar URL canónicas distintas para la misma página con técnicas diferentes. Por eso, para un PDF hay que elegir una de dos opciones:

• Canonical: el PDF sigue siendo accesible y las señales se consolidan en la página HTML.
• Noindex: el PDF desaparece de los resultados (ver la sección siguiente).

#Configuración en servidores Nginx

location ~* \.pdf$ {
    # Enlace canónico hacia la versión HTML principal
    add_header Link '<https://midominio.es/documentacion-tecnica/>; rel="canonical"';
}

#Configuración en servidores Apache (.htaccess)

Con el módulo mod_headers habilitado:

<FilesMatch "\.pdf$">
    Header set Link '<https://midominio.es/documentacion-tecnica/>; rel="canonical"'
</FilesMatch>

#Configuración en Cloudflare Pages y redes de entrega de contenidos

En Cloudflare Pages y plataformas de alojamiento estático parecidas, la regla va en el archivo _headers:

/documentos/*.pdf
  Link: <https://midominio.es/documentacion-tecnica/>; rel="canonical"

Una regla por patrón de archivos apunta todos los PDF a la misma página. Si cada PDF tiene su propia página HTML, necesitas una regla por archivo o por carpeta.

#Cómo quitar un PDF de los resultados de Google

Según el blog de Google Search Central, la forma más sencilla de impedir que un PDF aparezca en los resultados es enviar la cabecera HTTP X-Robots-Tag: noindex con el archivo. Si el PDF ya está indexado, irá desapareciendo con el tiempo; para una retirada más rápida, el mismo artículo remite a la herramienta de retirada de URL de Search Console.

La documentación de la etiqueta meta robots muestra este caso para todos los PDF de un sitio, con noindex, nofollow:

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

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

Si quieres que Google siga usando los enlaces del PDF para descubrir páginas, basta con noindex: la misma documentación explica que, si no se especifica nofollow, Google puede usar los enlaces de la página para descubrir las páginas enlazadas.

Hay otras dos vías, con efectos distintos:

• Contraseña: Splitt recuerda que un PDF protegido con contraseña no lo pueden leer los buscadores. Sirve para documentos que no deben ser públicos.
• robots.txt: impide que Google descargue el PDF. Pero la documentación de URL duplicadas advierte que Google puede indexar URL bloqueadas en robots.txt sin su contenido. Si el objetivo es que el archivo no aparezca, la cabecera noindex es la herramienta correcta, y Google solo la ve si puede descargar el archivo.

#Cómo gestiona WordPress los PDF subidos a la biblioteca de medios

Cuando subes un PDF a la biblioteca de medios, WordPress guarda el archivo en wp-content/uploads y crea un adjunto en la base de datos. Ese archivo lo sirve directamente el servidor web (Nginx, Apache) o la CDN, sin cargar WordPress. Este detalle decide dónde se configuran las cabeceras.

El hook send_headers se dispara desde WP::send_headers() cuando WordPress procesa una petición. Una petición directa a /wp-content/uploads/2026/10/catalogo.pdf nunca llega a WordPress, así que un código en functions.php que intente añadir una cabecera canonical a ese PDF no se ejecuta. La cabecera solo se puede añadir desde PHP si un plugin entrega el archivo a través de WordPress, y esa configuración tiene su propio coste. Para archivos estáticos, la cabecera se configura en el servidor o en la CDN, como en la sección anterior.

El adjunto genera además su propia URL en WordPress: la página de adjunto. El aviso de desarrollo de WordPress 6.4 cambió su comportamiento:

• En las instalaciones nuevas, las páginas de adjuntos están desactivadas y redirigen a la URL del archivo.
• La opción wp_attachment_pages_enabled controla este comportamiento: vale 0 en las instalaciones nuevas y se fija en 1 al actualizar un sitio existente, para que las páginas de adjuntos sigan funcionando como antes.

En un sitio que viene de una versión anterior a la 6.4, cada PDF subido puede tener, además del archivo, una página de adjunto delgada e indexable. Comprueba el valor de la opción con WP-CLI (wp option get wp_attachment_pages_enabled) antes de decidir si necesitas cambiarla.

#Riesgos de los plugins de exportación automática a PDF en WordPress

En el ecosistema de WordPress es habitual usar plugins que añaden un botón de descarga en PDF a cada entrada. Estas extensiones se apoyan en bibliotecas PHP como Dompdf, TCPDF o mPDF para convertir el HTML del artículo en un archivo PDF bajo demanda.

Mueller recordó en el episodio 115 un caso de los primeros CMS, posiblemente Joomla, que ofrecía ver cada página como PDF. Como Google no vuelve a rastrear esos archivos a menudo, el sitio acababa con el contenido antiguo indexado como PDF y el nuevo como página HTML: las dos versiones competían entre sí y además estaban desincronizadas. Su conclusión: si el contenido es fresco y dinámico y necesitas ofrecer un PDF, evita que ese PDF sea indexable.

Desde la perspectiva de ingeniería y SEO, esta práctica introduce tres problemas:

1. Duplicados en el rastreo: cada entrada gana una segunda URL con el mismo texto. Los rastreadores dedican tiempo a procesar copias en lugar de contenido nuevo.
2. Carga en el servidor: generar un PDF a partir de HTML con estilos en PHP es una operación costosa, y si un rastreador solicita muchas descargas a la vez, la carga recae en PHP-FPM.
3. Pérdida de la experiencia de usuario y de conversión: si la versión PDF se posiciona por encima de la página HTML, el visitante llega a un documento estático sin formularios de contacto, navegación ni llamadas a la acción.

Splitt añadió que la mayoría de navegadores, en móvil y en escritorio, ya permiten guardar una página como PDF, por lo que normalmente el propietario del sitio no tiene que ofrecer esa función. Basta con una hoja de estilos CSS para impresión:

@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) ")";
  }
}

Con esta regla, el usuario que quiere guardar el artículo usa la función de imprimir del navegador (Ctrl + P o Cmd + P) y obtiene un PDF limpio generado en su propio dispositivo, sin consumir CPU de tu servidor.

#Por qué el archivo llms.txt no debe publicarse como PDF

La propuesta llms.txt, publicada por Jeremy Howard en septiembre de 2024, define un archivo Markdown en la ruta /llms.txt con información breve, orientaciones y enlaces a archivos Markdown más detallados, pensado para ofrecer contenido fácil de procesar para los modelos de lenguaje.

El episodio 115 empieza precisamente con esta pregunta. Mueller pregunta si tiene sentido guardar el llms.txt como PDF, y Splitt responde que no: la idea de llms.txt era poner el contenido a disposición de los modelos de lenguaje en la forma más simple posible, y el PDF no es la forma más simple de contenido en la web. Que Google pueda procesar PDF no significa que los demás puedan o quieran hacerlo.

El archivo llms.txt debe mantenerse como un archivo de texto en Markdown en la raíz del sitio (https://midominio.es/llms.txt), enlazando a páginas o archivos Markdown legibles sin conversión.

#Cuándo tiene sentido publicar un PDF en tu web

El episodio 115 no es un alegato contra el PDF. Splitt enumera los casos en los que lo recomienda: cuando el contenido tiene requisitos de formato específicos, cuando debe verse de una forma muy concreta al imprimirse, o cuando necesitas formularios interactivos. Su ejemplo es un alojamiento que publica en PDF el formulario de registro de huéspedes porque así lo procesa más fácilmente.

Para los menús de restaurante, Mueller fue pragmático: un menú en PDF es mejor que no tener menú en la web; entre un PDF y una página normal, prefiere la página, porque permite ampliar mejor, se adapta al móvil y carga algo más rápido. Si el texto del PDF se puede seleccionar y copiar, Google puede usarlo en la búsqueda.

Sobre los sistemas de IA, Mueller añadió que en Google los PDF funcionan, que los ha visto citados también en otros sistemas de IA, y que publicar en PDF no destruye la visibilidad en esos sistemas. Pero si el mismo contenido puede estar en HTML, todo resulta un poco más fácil.

Splitt también señaló dos problemas de uso en móvil: un PDF tiene que descargarse por completo antes de mostrarse, mientras que una página HTML empieza a mostrar contenido cuanto antes, y muchos PDF no reajustan el texto al ampliar.

#Comparativa técnica entre HTML semántico y documentos PDF estáticos

Salvo para documentos cuya finalidad principal sea la impresión, un formulario o un formato fijo, el contenido que debe posicionar y actualizarse rinde mejor como página HTML.

#Plan de migración de documentos PDF a HTML en WordPress

Si tu empresa acumula decenas o cientos de archivos PDF con información técnica, fichas de producto o manuales, un plan ordenado de migración a páginas HTML pone ese contenido en el formato que Google rastrea con más frecuencia y que los usuarios leen mejor en el móvil.

1. Inventario técnico: usa una herramienta de rastreo para listar todos los archivos .pdf del servidor y comprueba su tráfico orgánico actual en Google Search Console.
2. Prueba de texto: aplica a cada PDF la prueba de copiar y pegar. Los documentos rasterizados son los primeros candidatos a pasar a HTML, porque hoy Google no ve su contenido.
3. Reorganización de contenidos:
   • Traslada la información de mayor valor a nuevas páginas en WordPress o Astro con bloques semánticos.
   • Configura redirecciones permanentes 301 desde las URL de los PDF antiguos hacia las nuevas páginas HTML.
4. Canónicas para archivos imprescindibles: en los documentos que deban seguir existiendo como descarga (formularios, plantillas para rellenar), añade la cabecera HTTP Link: <url>; rel="canonical" hacia la página web que explica el documento, o X-Robots-Tag: noindex si no deben aparecer en Google. Nunca ambas a la vez.
5. Metadatos y enlace de vuelta: rellena título, autor y descripción de los PDF que se quedan, y añade en la primera página un enlace a tu web.
6. Páginas de adjuntos: comprueba wp_attachment_pages_enabled si el sitio se instaló antes de WordPress 6.4.
7. Desinstalación de generadores automáticos: desactiva los plugins de creación masiva de PDF y ofrece una hoja de estilos de impresión.
8. Enlazado interno coherente: conecta las nuevas páginas con los pilares principales de tu arquitectura web, siguiendo las pautas de nuestra auditoría de seguridad WordPress y de los proyectos de integración WooCommerce ERP.