Auditoría SEO técnica: qué incluye y qué informe exigir antes de invertir en contenido

Seis capas de revisión y una sola lista priorizada

¿Qué incluye una auditoría SEO técnica? Seis capas, en el orden en que un buscador encuentra una página: rastreo, elegibilidad para el índice, renderizado de JavaScript, señales como títulos, enlaces internos y datos estructurados, rendimiento en visitas reales y, por último, URL duplicadas y versiones de idioma. Debe recibir una lista de tareas priorizada, no la exportación del rastreador: cada fila nombra el problema, muestra la prueba, indica la plantilla o el patrón de URL afectado, estima impacto y esfuerzo, asigna responsable y explica cómo se verificará el arreglo. Un informe que no encaje en esa tabla le devuelve el análisis a usted.

El orden importa: cada capa depende de la anterior, y una página con código de estado erróneo no gana nada con un título mejor. Por eso la auditoría va antes de ampliar el contenido: los artículos nuevos heredan los fallos de descubrimiento del sitio que los arrastra.

Rastreo y elegibilidad para el índice, lo primero

La primera pasada comprueba si las URL que deben posicionar pueden alcanzarse y mantenerse en el índice: códigos de estado, cadenas de redirecciones, reglas de robots.txt, sitemaps XML y enlaces internos, incluida la profundidad de las páginas importantes y cuáles no reciben ningún enlace.

Una página rastreable puede quedar fuera por una etiqueta noindex, una canónica que apunta a otra dirección o un 404 leve, cuando la página dice que no hay nada pero el servidor responde con éxito. El informe de indexación de Search Console muestra estos motivos con URL de ejemplo, pero como esas listas tienen tope, sirven para detectar patrones, no como inventario completo.

Imagine una tienda con 1.200 productos cuyos filtros generan muchas más combinaciones rastreables que productos: el hallazgo útil no es «demasiadas URL», sino qué combinaciones merecen rastreo, cuáles deben quedar fuera y qué páginas deben enlazar a las categorías que venden.

Renderizado de páginas construidas con JavaScript

Google procesa las páginas con JavaScript en tres fases: rastreo, renderizado e indexación. Las páginas con código de éxito esperan en una cola de renderizado que, según Google, puede durar segundos o bastante más. Por eso la auditoría compara, plantilla por plantilla, el HTML que envía el servidor con el HTML tras ejecutar los scripts, y señala lo que solo existe después.

Varias comprobaciones vienen de la guía de Google sobre SEO para JavaScript: solo encuentra enlaces que son elementos a con atributo href, así que un menú por clics puede ocultar secciones enteras. Si el HTML original lleva noindex, Google puede saltarse el renderizado y un script que lo retire después ya no sirve. Los scripts no deben reescribir la canónica, y una aplicación de una sola página necesita buen manejo de errores.

La prueba en esta capa es una captura, no una opinión: el HTML renderizado y la imagen de una prueba en directo de inspección de URLs o de la prueba de resultados enriquecidos, guardados junto al hallazgo. Un «posibles problemas de renderizado» sin esa captura significa que nadie comprobó nada.

Señales de página y Core Web Vitals con datos reales

Las señales de página son las partes del HTML que la describen: título, meta descripción, encabezados, textos de enlace y datos estructurados. Se evalúa la coherencia, no el volumen: el precio y la disponibilidad del marcado de producto deben coincidir con la página visible, y los títulos que genera una plantilla no deben repetirse. Añadir tipos de schema es poco prioritario mientras el marcado existente contradiga la página.

El rendimiento exige una distinción entre datos de campo, de usuarios reales como el Chrome UX Report que alimenta PageSpeed Insights y el informe Core Web Vitals de Search Console, y datos de laboratorio, de cargas simuladas en Lighthouse o Chrome DevTools; web.dev aclara que el laboratorio no sustituye al campo, y que sin usuarios reales no se mide Interaction to Next Paint.

Un hallazgo sólido de rendimiento parte de los datos de campo de un grupo de páginas similares, nombra la métrica que falla en móvil o escritorio y solo después recurre al laboratorio para localizar la causa, como el elemento que determina el Largest Contentful Paint.

URL duplicadas, propiedad de la canónica y versiones de idioma

Los sitios generan duplicados sin proponérselo: parámetros de seguimiento, órdenes de clasificación, barras finales, variantes de protocolo. Google trata las redirecciones y rel=canonical como señales fuertes y la inclusión en el sitemap como una señal débil, indica que se suman cuando coinciden y desaconseja usar robots.txt o noindex para elegir la canónica dentro de un sitio.

Ser dueño de la canónica implica dos decisiones: qué URL representa al grupo de duplicados y qué parte del sistema emite esa señal, sea un campo del CMS, una función de plantilla, una regla de redirección o el generador del sitemap. La inspección de URLs muestra la canónica declarada junto a la elegida por Google; si difieren, el informe debe nombrar la señal que se impone.

Las versiones de idioma piden su propia revisión: cada una declara una canónica en su propio idioma, y los conjuntos hreflang deben estar completos en todas las direcciones. Piense en un sitio en cinco idiomas donde una función compartida imprime la canónica inglesa en todas las versiones: el informe debe nombrar esa función una vez, no cada página afectada.

Fallos de plantilla frente a fallos de una sola página

La mayoría de los fallos técnicos nace en las plantillas: una ficha de producto sin canónica o una categoría que convierte cada filtro en enlace repite el fallo en todas las URL construidas con ella. Existen fallos puntuales, como un bucle de redirecciones o un noindex puesto a mano, pero rara vez explican un patrón de todo el sitio.

Eso cambia el muestreo. En lugar de ordenar avisos por cantidad, el auditor enumera las plantillas, toma varias URL representativas de cada una (antigua, reciente y atípica) y las analiza. Ese agrupamiento ya aparece en el informe de Search Console sobre Core Web Vitals. El rastreo completo mide después hasta dónde llega cada fallo.

También cambia la lectura del informe. Supongamos que una clínica tiene cuarenta páginas de servicios con la misma plantilla y una herramienta arroja doscientos avisos de títulos que se reducen a dos campos: como causa raíz, es una tarea de desarrollo y una comprobación; como doscientas filas, parece un mes de trabajo y se aplaza.

La fila que todo hallazgo debe completar

El formato del informe es donde más difieren las auditorías, y puede acordarse antes de empezar: incluya las columnas en la solicitud inicial o pida una fila de ejemplo anonimizada. Un hallazgo sin prueba no se revisa, uno sin responsable no se planifica y uno sin verificación nunca se cierra.

La prioridad combina el impacto del fallo, el valor de las páginas que toca y el esfuerzo que exige corregirlo. Una canónica ausente en un listado filtrado y la misma ausencia en la plantilla de categoría principal son prioridades distintas, aunque la herramienta les asigne igual gravedad.

Aceptación de la auditoría antes de firmarla

Aceptar una auditoría es confirmar que está completa y es correcta, no que es larga. Antes de empezar, pacte una muestra fija de URL: portada, páginas comerciales principales, un par de artículos, una dirección antigua redirigida, una página de utilidad como la búsqueda interna y una página que ya sabe que falla. El informe debe dar un veredicto sobre cada una, incluido «sin incidencias» cuando sea honesto.

Después llegan las verificaciones puntuales: reproduzca tres o cuatro hallazgos con su desarrollador mediante la prueba en directo, el HTML renderizado, las cabeceras de respuesta o los datos de campo. Si la prueba no se reproduce, el resto del informe merece la misma duda, y todas las plantillas deben figurar en él, aunque sea como revisadas y sin fallos.

Cuando salgan las primeras correcciones, Search Console aporta pruebas con fecha: «Validar corrección», en el informe de indexación, vuelve a comprobar las URL con el problema conocido y puede tardar días o más. Es opcional, porque Google también detecta arreglos al rastrear con normalidad, pero deja constancia. Un nuevo rastreo de los patrones afectados cierra el ciclo.

Cuándo basta una revisión acotada y qué accesos dar

Una auditoría completa tiene sentido tras una migración, un rediseño, un cambio de CMS o de renderizado, una importación grande de contenido, un idioma nuevo o una caída inexplicable de páginas indexadas. Tras un lanzamiento pequeño suele bastar una revisión acotada: rastrear de nuevo las plantillas afectadas, comparar su HTML renderizado con la versión anterior y confirmar códigos de estado, canónicas y datos estructurados en esas URL.

En cualquier caso, el auditor necesita accesos, o los hallazgos serán conjeturas desde fuera: permisos de Search Console para inspeccionar URL y exportar informes, analítica, registros del servidor si existen, sitemaps, entorno de pruebas, lista de plantillas, familias de URL que generan ingresos y fechas de los últimos lanzamientos. Cada elemento que falte reduce lo que la auditoría puede demostrar.