Cómo posicionar un PDF en Google

Un PDF se indexa en Google exactamente igual que una página HTML: Googlebot lo rastrea, extrae su contenido y lo evalúa como un documento más. El problema casi nunca es que Google "no vea" los PDF —los procesa desde hace más de dos décadas—, sino que la mayoría de los PDF publicados carecen de las señales mínimas que sí lleva una página web bien construida: un título en los metadatos, una capa de texto real, enlaces que le den contexto y una versión canónica clara cuando el mismo contenido vive en dos direcciones distintas.

Este artículo cubre esas cuatro piezas —título y metadatos, capa de texto, enlaces y canonical vía cabecera HTTP— y termina con el criterio para decidir cuándo un PDF es la forma correcta de publicar algo y cuándo conviene convertirlo en una página HTML normal.

Cómo rastrea e indexa Google un archivo PDF

El proceso empieza igual que con cualquier URL: Googlebot necesita descubrir el archivo mediante un enlace, una entrada en el sitemap o un envío manual desde Search Console. A partir de ahí descarga el binario completo —no solo la primera página— y lo pasa por un extractor interno que separa el texto, los enlaces y los metadatos incrustados, igual que hace con el HTML de una página normal.

La diferencia está en qué se extrae y de dónde. Google no "mira" el PDF como una imagen: lee la capa de texto que el propio archivo lleva incrustada. Si esa capa existe y está bien formada, el documento entra al índice con normalidad, puede competir por palabras clave, aparecer en fragmentos destacados y acumular su propia autoridad de enlace como cualquier otra URL del sitio.

• El rastreo requiere una URL descubrible: un enlace interno o externo, una entrada en el sitemap, o un envío manual en Search Console.
• Googlebot descarga el archivo entero; el límite práctico está en el peso del archivo, no en el número de páginas que contenga.
• El texto se extrae de la capa de texto del propio PDF, no de una captura visual del documento.
• Los enlaces internos y externos que aparecen dentro del PDF se procesan igual que en una página HTML.

El título y los metadatos del documento, no solo el nombre del archivo

Cada PDF lleva un conjunto de metadatos propio —título, autor, asunto, palabras clave— definido en el estándar del formato, independiente del nombre del archivo. Cuando el campo "Título" de esas propiedades está relleno, Google suele mostrarlo como el título del resultado en la SERP. Cuando está vacío, el motor recurre a alternativas peores: el nombre literal del archivo (informe_v3_final.pdf) o la primera línea de texto visible, que rara vez funciona como un titular pensado para el clic.

Rellenar ese metadato no depende de retocar el PDF a mano cada vez: se puede fijar en el editor de origen antes de exportar, o reescribir después en lote con una herramienta de línea de comandos, sin volver a abrir el documento en un editor visual.

El campo "Palabras clave" de las propiedades es distinto y no funciona como señal de posicionamiento: rellenarlo con variantes de tu keyword objetivo no sustituye un buen título ni un buen texto del documento.

• Adobe Acrobat: Archivo > Propiedades > pestaña Descripción, campo Título.
• LibreOffice o Word: propiedades del documento antes de exportar a PDF; el título se traslada al metadato final.
• Línea de comandos: exiftool -Title="Texto del título" archivo.pdf reescribe el metadato sin reabrir el documento.
• Un nombre de archivo descriptivo (guia-declaracion-renta-2024.pdf) ayuda a la legibilidad de la URL, pero no sustituye al metadato Título cuando este existe.

La capa de texto: por qué un PDF escaneado no posiciona

Hay dos tipos de PDF que se ven idénticos en pantalla y se comportan de forma opuesta para un rastreador. Uno se exporta desde un editor de texto —Word, Google Docs, InDesign, LaTeX— y lleva de fábrica una capa de texto real y seleccionable. El otro nace de escanear o fotografiar papel: visualmente es un documento, pero técnicamente es una imagen sin una sola palabra que un extractor pueda leer.

Si publicas el segundo tipo tal cual, Google no tiene texto que indexar más allá de los metadatos que hayas rellenado a mano. La solución es aplicar reconocimiento óptico de caracteres antes de publicar: Adobe Acrobat lo ofrece como función "Reconocer texto", y en línea de comandos ocrmypdf hace lo mismo gratis, añadiendo una capa de texto invisible sobre la imagen original sin alterar su aspecto visual.

Existe un tercer caso más difícil de detectar: capa de texto presente pero mal codificada, típicamente por una fuente subconjuntada de forma incorrecta al exportar. El documento se ve bien, pero al copiar aparecen símbolos sueltos, y un extractor automático lee exactamente esa misma basura.

• Prueba rápida: selecciona y copia un párrafo del PDF; si no se puede marcar el texto con el cursor, tampoco hay texto que indexar.
• ocrmypdf archivo_escaneado.pdf archivo_con_texto.pdf añade una capa de texto invisible sin modificar el aspecto visual de la página.
• Un PDF exportado desde un editor de texto casi siempre trae la capa de texto correcta de fábrica; uno escaneado, casi nunca.
• Si al copiar el texto aparecen símbolos sueltos o espacios rotos, la fuente está mal codificada y el extractor de Google leerá lo mismo: basura.

Enlaces hacia el PDF y enlaces dentro del PDF

El PDF necesita enlaces en ambas direcciones para posicionar bien. Los que apuntan hacia él importan tanto como en cualquier otra URL: el texto ancla y el contexto de la página que enlaza le dan a Google pistas sobre el tema del documento, igual que el texto alrededor de una imagen ayuda a entender de qué trata. Un PDF enlazado solo desde un listado plano de "Descargas" llega al índice con mucho menos contexto que uno enlazado desde el cuerpo de un artículo que lo describe.

En la dirección contraria, los hipervínculos dentro del propio PDF también se rastrean, con una condición técnica importante: tienen que ser anotaciones de tipo enlace real, igual que un href en HTML, no simplemente texto que parece una URL. Escribir "visita ejemplo.com" como texto plano, sin convertirlo en enlace clicable, no se sigue como tal aunque el lector lo reconozca.

La consecuencia práctica es tratar la URL del PDF como un nodo más de la arquitectura interna, no como un anexo aislado. Enlazarlo desde varias páginas relevantes, con anclas variadas y naturales, funciona igual que reforzar cualquier otra URL del dominio.

• Enlaza al PDF desde texto explicativo dentro de una página HTML, no solo desde un listado plano de "Descargas".
• Un hipervínculo real (anotación de tipo enlace) dentro del PDF se rastrea igual que un enlace en HTML.
• Un texto que simplemente parece una URL, sin ser un enlace clicable de verdad, no se sigue como tal.
• Trata la URL del PDF como un nodo más de tu estructura interna, reforzado desde varias páginas, no como un anexo aparte.

El canonical de un PDF vía cabecera HTTP

Un PDF no tiene una sección <head> donde insertar <link rel="canonical">, así que cuando el mismo archivo es accesible desde varias direcciones —con parámetros de seguimiento, replicado en otra ruta, o coexistiendo con una página HTML que cubre el mismo contenido— la señal canónica tiene que enviarse fuera del archivo: en la cabecera de la respuesta HTTP.

La sintaxis es la misma que Google documenta para cualquier recurso no HTML: la cabecera Link, con rel="canonical" apuntando a la URL que quieres indexar, configurada a nivel de servidor —nunca dentro del propio PDF.

Configurarlo en el servidor no garantiza que la cabecera llegue realmente al rastreador; conviene comprobarlo con curl -I sobre la URL del PDF y confirmar que Link aparece tal cual en la respuesta. Un mecanismo relacionado pero distinto es X-Robots-Tag: noindex, útil cuando el objetivo no es fusionar señales sino excluir directamente el PDF del índice.

• Sintaxis: Link: <https://tudominio.com/ruta/archivo-canonico.pdf>; rel="canonical", enviada en la respuesta HTTP, no dentro del archivo.
• Apache: se añade condicionando por tipo de archivo en la configuración del servidor o en el .htaccess.
• Nginx: se añade con add_header en el bloque location que sirve los PDF.
• X-Robots-Tag: noindex es el equivalente, para archivos no HTML, de la metaetiqueta robots.

Cuándo conviene publicar en HTML en lugar de PDF

El PDF tiene un uso legítimo y no siempre conviene sustituirlo: formularios oficiales, fichas técnicas para imprimir o guardar, documentos que deben verse idénticos en cualquier dispositivo porque su formato importa tanto como su contenido. Para ese material, publicar en PDF sigue siendo la decisión correcta.

El problema aparece cuando se usa PDF para contenido editorial que compite por posicionar: guías, artículos, comparativas. Ahí el formato juega en contra por varias razones acumuladas. No hay forma de incluir marcado de datos estructurados dentro de un PDF, así que cualquier resultado enriquecido —migas de pan, valoraciones— queda descartado de partida. La visualización en móvil depende además del visor del navegador o del sistema operativo, que varía de un dispositivo a otro y rara vez lee tan cómodo como una página responsive.

También se pierde control editorial y de analítica: actualizar un PDF implica sobrescribir el archivo o publicar uno nuevo, lo que puede romper el historial de señales si cambia la URL; y medir qué parte del documento lee realmente el usuario, trivial en HTML con las herramientas habituales, no tiene equivalente cómodo dentro de un PDF.

Cuando el mismo contenido vale tanto para lectura online como para descarga, la solución no es elegir uno u otro: se publican los dos, con una página HTML como versión principal y el PDF enlazado desde ella, resolviendo con el canonical o el noindex cuál de las dos compite en la SERP.

• Formularios oficiales, fichas técnicas o documentos que el usuario quiere descargar y conservar tal cual → PDF tiene sentido.
• Contenido editorial que se actualiza, se enlaza internamente y compite por fragmentos destacados → HTML.
• El marcado de datos estructurados no puede incluirse dentro de un PDF; si necesitas resultados enriquecidos, la respuesta tiene que vivir en una página HTML.
• Cuando el contenido vale tanto para leer online como para descargar, publica ambos formatos y decide con el canonical cuál es la versión principal.

Errores operativos que sabotean la indexación sin que se note

Fuera de las cuatro piezas centrales hay detalles operativos que bloquean la indexación sin que se note. El más común es un robots.txt que excluye la extensión .pdf o toda una carpeta de descargas: algunos plugins y CDN bloquean tipos de archivo pesados por defecto, y el PDF queda fuera del rastreo sin que nadie lo haya decidido para ese documento en concreto.

El segundo detalle es qué hacer cuando un PDF deja de existir: si lleva tiempo publicado es razonable que haya acumulado enlaces externos que ya no controlas, y sustituirlo sin más deja esos enlaces apuntando a un 404. Una redirección 301 hacia el reemplazo, o hacia la página HTML más cercana en contenido, conserva ese valor en vez de tirarlo.

• Revisa que robots.txt no bloquee la carpeta o la extensión .pdf; algunos CDN y plugins la excluyen por defecto para ahorrar ancho de banda.
• Incluye en el sitemap.xml los PDF que sí quieres indexados; omite los que sirven solo como descarga interna sin valor de búsqueda propio.
• Si retiras o sustituyes un PDF, aplica una redirección 301 hacia el reemplazo en vez de dejar un 404: el archivo puede llevar años acumulando enlaces externos.
• La Inspección de URL en Search Console procesa PDF igual que HTML: úsala para confirmar qué texto ha extraído Google y si la indexación se completó.