Auditoría SEO técnica: el checklist que mueve la aguja

La auditoría técnica típica termina en una hoja con doscientos avisos ordenados por severidad según la herramienta, que nadie del equipo de desarrollo va a ejecutar porque no hay forma de saber cuáles de los doscientos cambian algo. El problema no es la herramienta: es que se ha auditado sin un orden de dependencias.

Hay un orden, y es bastante estricto, porque cada capa solo tiene sentido si la anterior está resuelta.

El orden importa más que la herramienta

Optimizar el rendimiento de una página que está bloqueada por robots.txt es trabajo tirado. Ordenar la auditoría por esta escalera evita ese desperdicio y, de paso, produce un informe con prioridades defendibles.

Esta misma escalera sirve de lista de descarte cuando el tráfico ya ha caído y hay que encontrar la causa; el orden completo, incluyendo las causas que no son técnicas, está en la guía de diagnóstico de caídas de tráfico.

Capa 1: que puedan llegar e indexarte

Cinco comprobaciones, en este orden:

1. robots.txt y reglas del CDN. Revisa las dos cosas. La mayoría de bloqueos accidentales no están en el fichero, están en una regla de cortafuegos o en una limitación de tasa que devuelve 429 a los rastreadores. En el fichero se ve; en el CDN hay que ir a mirar.
2. Etiquetas noindex supervivientes. El clásico eterno: el noindex del entorno de pruebas que sube a producción con el despliegue. Cuesta un minuto comprobarlo y explica más caídas de tráfico que cualquier actualización de algoritmo.
3. Canónicas coherentes. Que cada página apunte a sí misma salvo que haya un motivo, que no haya cadenas de canónica a canónica y que la versión canónica sea indexable. Una canónica que apunta a una página con noindex es una forma silenciosa de desindexar una sección entera.
4. Sitemap sano. Solo URL indexables, con código 200, sin redirecciones, y con lastmod verdadero. Un lastmod que miente enseña a los rastreadores a ignorarlo, y recuperar esa confianza cuesta meses.
5. Códigos de estado y redirecciones. Cadenas de más de un salto, bucles, y sobre todo páginas que devuelven 200 diciendo «no encontrado» en el texto. Esas últimas son las peores porque ninguna herramienta las marca sola.

Estas cinco comprobaciones resuelven los motivos técnicos del informe de indexación. Los dos que no son técnicos —«Descubierta» y «Rastreada: actualmente sin indexar»— no se arreglan aquí y tienen su propio diagnóstico en la guía de páginas que Google no indexa.

Contrasta el resultado con el informe de páginas de Search Console. Si tu rastreador ve 4.000 URL y Google tiene 900 indexadas, ahí está el diagnóstico antes de mirar ninguna otra capa.

Capa 2: que vean el contenido sin ejecutar JavaScript

Esta capa ha pasado de ser un detalle a ser decisiva, y el motivo no es Google: es que una parte creciente de las visitas nace en un asistente, y buena parte de los rastreadores de IA no renderizan JavaScript.

La comprobación es de treinta segundos: pide el HTML de tu página como lo pediría un bot, sin ejecutar nada, y búscalo. ¿Está el <h1>? ¿Está el texto del artículo? ¿Está la descripción? ¿Está el enlace canónico? Si la respuesta a alguna es que no, para ese rastreador tu página está en blanco.

El caso más habitual es una aplicación de una sola página donde todo el contenido viaja en un JSON y se pinta en el cliente. No hace falta rehacerla: basta con emitir desde el servidor lo que tiene que ser legible —title, descripción, canónica, datos estructurados y una versión textual del contenido visible— y dejar que el JavaScript se encargue de la interactividad. Es el mismo principio que describe la parte técnica de la guía de GEO.

Dos comprobaciones más en esta capa: que los enlaces internos sean etiquetas <a href> de verdad —un div con un manejador de clic no es un enlace para nadie que no ejecute JavaScript— y que la paginación y los filtros no dependan exclusivamente del JavaScript para llegar al contenido profundo.

Capa 3: Core Web Vitals, con los umbrales reales

La parte que casi nadie cuenta es cómo se evalúan: sobre usuarios reales de Chrome, en el percentil 75 y en una ventana de 28 días. De ahí salen las dos consecuencias prácticas que más confusión evitan.

La primera: un informe de laboratorio en verde no significa nada si los datos de campo están en rojo. El laboratorio mide un ordenador potente con buena conexión; el campo mide a tu público con su móvil de hace tres años en el metro. Audita siempre con datos de campo y usa el laboratorio solo para diagnosticar la causa.

La segunda: si arreglas algo hoy, el dato tarda hasta cuatro semanas en reflejarlo del todo, porque la ventana es móvil. Quien despliega un arreglo el lunes y da marcha atrás el jueves porque «no ha servido de nada» está tirando trabajo bueno.

INP es la métrica que más suspensos nuevos ha producido desde que sustituyó a FID en marzo de 2024, y el motivo es estructural: FID medía el retraso de la primera interacción y INP mide la respuesta durante toda la visita. Los sitios cargados de etiquetas de terceros y de JavaScript que sigue trabajando después de pintar la página pasaban el primero y suspenden el segundo.

Capa 4: datos estructurados que no mienten

El marcado sirve para decirle a la máquina qué es cada cosa en lugar de esperar a que lo deduzca. Conviene tener la expectativa calibrada —no compra citas en los asistentes, y hay un estudio que lo midió—, pero sigue decidiendo el aspecto de tu resultado: el detalle está en la guía de datos estructurados.

• Organization en todo el sitio, con el nombre, el logotipo y los perfiles oficiales. Es lo que consolida quién eres como entidad.
• Article en contenido editorial, con fecha de publicación, fecha de actualización y autor real.
• BreadcrumbList para dar jerarquía explícita.
• FAQPage solo donde el usuario vea de verdad esas preguntas en la página. Marcar preguntas invisibles es motivo de acción manual, no un atajo.
• Product, JobPosting, Event… según el tipo de sitio, y siempre con datos que coincidan con lo que se ve.

La regla que resume la capa entera: el marcado describe la página, no la mejora. En cuanto dice algo que la página no dice, deja de ser una ventaja y pasa a ser un riesgo.

Capa 5: arquitectura y enlazado interno

Tres comprobaciones que descubren más problemas de los que parece:

1. Profundidad de clic. Cuántos clics hay desde la portada hasta cada página importante. Más de tres es una señal de que algo relevante está enterrado.
2. Páginas huérfanas. URL que están en el sitemap y no recibe ningún enlace interno. Se crean solas cada vez que alguien publica algo y no lo enlaza desde ninguna parte.
3. Canibalización. Varias páginas compitiendo por la misma intención, que es un problema de contenido con síntomas técnicos. Se detecta cruzando consultas de Search Console con URL, y el método está en la guía de keyword research con IA. Cuando la causa de fondo es el reparto de enlaces internos, se corrige antes en la arquitectura de enlazado que reescribiendo el texto.

Qué parte de esto se delega en un modelo

La detección sigue siendo de las herramientas y el criterio sigue siendo tuyo. Lo que se delega bien es lo de en medio:

• Clasificar y priorizar avisos. Dale el CSV del rastreo y pide que agrupe los avisos por causa raíz y los ordene por impacto estimado, con una justificación de una línea por grupo. Un informe de doscientos avisos se convierte en ocho problemas.
• Redactar las incidencias. Convertir cada problema en un ticket con contexto, ejemplo reproducible y criterio de aceptación es escritura estructurada, no análisis.
• Generar y revisar JSON-LD. Producir el marcado de una plantilla a partir del HTML real y comprobar que cada campo tiene reflejo visible en la página.
• Explicar el porqué al equipo de negocio. Traducir «INP de 480 ms en el percentil 75» a por qué se pierden pedidos.

Lo que no se delega: decidir qué se arregla primero con el presupuesto que hay. Y conviene desconfiar de cualquier cifra que el modelo aporte por su cuenta —umbrales, porcentajes de mejora, volúmenes—, por el motivo que explica la guía de alucinaciones: rellenar huecos con material plausible es exactamente lo que hace.

Cómo entregar el informe para que se ejecute

Un informe técnico que nadie ejecuta no es un informe, es un documento. Cuatro reglas que cambian la tasa de ejecución más que cualquier hallazgo:

1. Ocho problemas, no doscientos avisos. Agrupa por causa raíz: cuarenta páginas con el mismo título repetido son un problema de plantilla, no cuarenta incidencias.
2. Cada problema con su coste y su efecto esperado. «Dos horas de front, arregla el CLS de la plantilla de producto» se prioriza; «mejorar CLS» se pospone indefinidamente.
3. Una comprobación de verificación por problema. Qué hay que mirar para saber que está resuelto, y cuándo se podrá mirar —recordando la ventana de 28 días de los datos de campo—.
4. Una línea base guardada. Páginas indexadas, Core Web Vitals de campo, impresiones y errores de rastreo el día de la auditoría. Sin esa foto, dentro de tres meses nadie podrá decir si sirvió de algo, que es la conversación que decide si habrá presupuesto la próxima vez. La medición de la parte de IA está en cómo medir el tráfico que llega desde la IA.