PDF y SEO: cómo posicionar un PDF en Google (y cuándo usar HTML)

Publicar tu guía o tu informe solo como PDF parece ordenado: un archivo, un enlace, nadie te lo edita. Para Google es distinto: ese documento no tiene etiqueta head, ni H2, ni datos estructurados, y no puedes enlazar sus secciones. Aun así, se puede posicionar un PDF en Google.

Aquí verás qué lee Google de un PDF, cuándo compite bien y cómo decidir entre PDF y HTML.

Qué lee Google de un PDF (y por qué es un formato de segunda)

Google agrupa los formatos en dos familias. Los flat file types son texto plano o con marcado ligero: HTML, TXT, XML, CSV, SVG o TeX. Los encoded file types son, en palabras de la documentación oficial, "binary files or complex containers that require a specific parser to extract the human-readable text": ahí vive el PDF, junto a DOCX, PPTX, XLSX, EPUB o RTF. Ambos se indexan; cambia cómo se extrae el texto, según la guía de tipos de archivo indexables.

El tipo lo decide el servidor: manda la cabecera Content-Type, y Google advierte que puede reparsear el archivo si falta o es incorrecta. Servir un PDF como application/octet-stream en vez de application/pdf, tienes un problema de lectura evitable.

Google no publica ninguna jerarquía de formatos ni dice que el PDF posicione menos: documenta qué puede leer y cómo declarar la canónica. Cuando un PDF rinde peor, la causa es técnica, no un castigo.

Tu primera auditoría: el operador filetype:

El operador filetype: limita los resultados a una extensión y comprueba el índice al instante.

filetype:pdf site:tudominio.com

Busca lo que esperabas y no aparece (bloqueo, documento sin texto, falta de enlaces) y lo viejo o duplicado que sí aparece: candidato a unificar.

Cuándo sí puedes posicionar un PDF en Google

El criterio no es un truco: un PDF compite bien cuando la gente busca un documento, no una explicación. Si quiere el archivo (ficha técnica, normativa, catálogo, plantilla), el PDF es la respuesta.

Casos donde funciona

• Documentos con demanda y nombre propio: reglamentos, bases de licitación, planes de estudio, manuales, menús.
• Contenido que se descarga, se imprime, se firma o se archiva: el HTML no reemplaza al archivo.
• Datos únicos y citables que atraen enlaces por sí solos, como los contenidos que generan backlinks naturales.

Los límites que no se pueden saltar

• Sin etiqueta head: no hay title, meta description, canonical por etiqueta ni datos estructurados; las propiedades internas del PDF no son la capa de metadatos que Google documenta, así que su título no funciona como title SEO.
• Sin jerarquía de encabezados: no hay índice ni H2 y H3 visibles, salvo que el archivo esté etiquetado.
• Sin enlaces a secciones: solo puedes enlazar el archivo completo.
• Sin rich results: nada de datos estructurados de producto, FAQ o artículo, como explican las guías de datos estructurados y de rich snippets.
• Mantenimiento caro: cada corrección crea un archivo nuevo y multiplica contenido duplicado; renombrar rompe la URL (necesitas una redirección 301).
• Lectura y accesibilidad: zoom, móvil y lectores de pantalla; un PDF largo en el teléfono es peor que una página bien construida, (accesibilidad web).

Checklist: cómo preparar un PDF que Google pueda leer

Si el documento va como PDF, estos seis pasos sí importan:

1. Texto real, no una foto de texto. Un PDF escaneado son imágenes y el parser no tiene qué extraer: aplica OCR, la técnica PDF7 del W3C en las técnicas PDF de accesibilidad.
2. Una URL por documento, limpia y estable. Mejor /guias/seguridad-laboral.pdf que /download?file=123; el criterio de URLs amigables aplica igual.
3. Enlázalo desde HTML con ancla descriptiva. "Descargar aquí" no dice nada; "guía de seguridad laboral 2026 (PDF)" sí ( texto ancla).
4. Declara la canónica con cabecera HTTP si hay varias versiones: rel="canonical" solo funciona en HTML. Para archivos, Google documenta la cabecera Link, soportada solo para resultados de búsqueda web:

Link: <https://www.example.com/guias/seguridad-laboral.pdf>; rel="canonical"

Con el mismo contenido en PDF y HTML, la cabecera del PDF apuntando a la URL HTML es la jugada correcta (consolidación de URLs duplicadas).

5. Refuerza la señal desde el sitemap. Es más débil, pero está documentada como método válido de canonicalización; útil con cientos de documentos y sitemaps XML.
6. Etiqueta el documento. Un PDF etiquetado expone encabezados y orden de lectura (PDF9) y sus imágenes llevan texto alternativo: lo único que le da a Google una estructura parecida a una página.

Para versiones idiomáticas del mismo PDF, Google documenta hreflang por cabeceras HTTP porque el archivo no tiene head donde declararlo: mira versiones localizadas.

HTML o PDF: cómo decidir (y qué hacer si publicas los dos)

La regla práctica: el HTML es la página que posiciona y se actualiza; el PDF es el entregable que se descarga desde ella. El error caro es contenido distinto en cada formato, porque compites contigo mismo; lo sano es un PDF que replica una página viva (qué es HTML y por qué importa).

Qué dice Google si publicas los dos

En la serie #AskGooglebot la respuesta fue que publicar el mismo contenido en HTML y PDF está bien: ambos "can be shown independently in the search results", y si Google los ve como duplicados puede mostrar la versión HTML ( Search Engine Roundtable). No hay penalización: hay canonicalización, y se resuelve con la cabecera.

Por qué el HTML también gana en las respuestas de IA

La guía de Microsoft para aparecer en respuestas de IA (octubre de 2025) pide no depender del PDF para información crítica: le faltan las señales estructuradas (encabezados, metadatos) que sí aporta el HTML, y los asistentes parten el contenido en piezas. Si tu información clave solo vive en un PDF, tienes menos superficie para que un sistema la cite; vale igual para Bing y Copilot.

Dos usos donde el PDF es la respuesta correcta

• Documentos que existen legalmente como archivo (bases, certificados, normativa) y plantillas rellenables.
• Un dato único y citable (una tabla, un estudio propio) que se comparte por correo y genera menciones.

Cómo auditar y medir tus PDFs

Cuatro pasos y ninguna herramienta de pago:

1. filetype:pdf site:tudominio.com muestra cuántos documentos tiene Google en el índice.
2. En Search Console, el informe de Rendimiento con filtro de páginas por regex \.pdf$ aísla clics, impresiones, CTR y posición de los documentos ( filtros avanzados; si es nuevo para ti, empieza por Google Search Console).
3. El informe de Enlaces dice qué documentos reciben enlaces: de ahí sale qué merece pasar a HTML.
4. Revisa el robots.txt: un Disallow heredado deja tus documentos fuera del índice sin que nadie lo note.

Qué arreglar primero

• Con enlaces y sin tráfico: pásalo a HTML; la intención de la gente es leer, no descargar.
• Con clics y buena posición: déjalo y mejora sus enlaces internos.
• Escaneado sin OCR: reconócelo y republica el archivo, o publica el contenido como HTML.
• Tres versiones del mismo informe: una canónica con cabecera, 301 en las otras y una URL en el sitemap.

Errores comunes al publicar PDFs

1. Bloquear los PDF con Disallow "porque son descargas": salen del índice y del informe.
2. Solo PDF escaneado, sin OCR: cero texto que leer y cero superficie para la IA.
3. Un archivo de 40 MB como única versión: mala experiencia en móvil y rastreo más caro.
4. Contenido distinto en HTML y PDF: canibalización entre tus propias versiones.
5. URLs tipo /documento1234.pdf: nadie las recuerda ni las enlaza.
6. Renombrar el archivo en cada actualización: pierdes el historial de enlaces sin una 301.
7. Prometer que el PDF sube igual que una página: ningún dato oficial lo sostiene; un PDF posiciona porque la gente busca ese documento.

Un PDF no es contenido de segunda para las personas: para una ficha técnica o una normativa, el archivo es la respuesta. El problema es pedirle a un formato sin head el trabajo de una página: pasa a HTML lo que la gente viene a leer, deja en PDF lo que viene a descargar y, si publicas ambos, dilo con la cabecera rel="canonical".