Auditoría de contenidos SEO: inventario, datos y decisiones

Para un sitio con años de historial, la pregunta que más tiempo consume no es qué escribir a continuación, sino qué hacer con las páginas que ya existen. Una auditoría de contenidos SEO es el proceso de inventariar cada URL indexable de un sitio, cruzar ese inventario con lo que Google Search Console y Google Analytics 4 (GA4) reportan sobre cada una, y usar esos datos para decidir, fila por fila, si una página se conserva, se actualiza, se fusiona con otra o se elimina. No es una lista subjetiva de "contenido flojo": es una tabla que convierte una sospecha en una decisión respaldada por números.

El resultado de una auditoría bien construida no es un informe para archivar, sino una tabla de trabajo: una fila por URL, con las columnas justas para decidir sin abrir quince pestañas cada vez que alguien pregunta "¿qué hacemos con esta página?". Este artículo cubre cómo montar esa tabla desde cero —el crawl, el cruce de datos y la puntuación— hasta llegar a las cuatro decisiones posibles. Qué hacer exactamente con una página concreta una vez que sabes que necesita un refresco o que debe desaparecer es un problema distinto, y ya tiene su propio desarrollo en otros artículos de este blog.

Por qué hace falta un proceso y no una revisión ad hoc

Cualquiera que navegue un sitio puede señalar una página que "parece vieja". El problema es que esa intuición no escala más allá de veinte o treinta URLs, y no distingue entre una página que ha perdido tráfico porque quedó desactualizada y otra que nunca tuvo tráfico porque nunca debió publicarse. Un sitio de doscientas o dos mil páginas no se puede juzgar mirándolo: hace falta una tabla que junte, por URL, lo que hay publicado con lo que ese contenido realmente produce.

Los momentos típicos en los que una auditoría deja de ser opcional son una migración de dominio o de plataforma, una caída de tráfico agregada que no se explica por una sola página, o la preparación de un rediseño de la arquitectura de información. En sitios grandes conviene tratarla también como un proceso recurrente en lugar de un proyecto que se hace una sola vez y se olvida.

El inventario: un crawl completo antes de mirar ninguna métrica

El primer paso no es abrir Search Console, es rastrear el sitio como lo haría un motor de búsqueda. Un crawler —Screaming Frog, Sitebulb, o un script propio— debe recorrer el sitio y registrar, por cada URL encontrada, el código de estado HTTP, si es indexable o lleva noindex, la URL canónica que declara, el título, el H1, un recuento de palabras del contenido visible y la fecha de última modificación si el sistema la expone.

Es importante rastrear desde dos puntos de partida distintos: el sitemap XML y el propio grafo de enlaces internos, siguiendo enlaces desde la home hacia abajo. Un sitemap desactualizado puede omitir páginas que sí reciben enlaces internos, y al revés: puede listar páginas huérfanas que ningún enlace interno alcanza. Las discrepancias entre ambos rastreos —páginas en el sitemap sin enlaces entrantes, o páginas enlazadas que no aparecen en el sitemap— son en sí mismas una señal que vale la pena anotar en la tabla.

Antes de tratar cada URL rastreada como una fila definitiva, resuelve las cadenas de redirección y los canónicos cruzados: si la URL A redirige a la URL B, o declara B como canónica, la fila que importa es B, y A debería anotarse como una redirección existente, no como una página nueva que evaluar.

Incorporar el rendimiento en buscadores desde Search Console

Con el inventario listo, el siguiente cruce es el informe de rendimiento de Search Console, extraído a nivel de página —no de consulta—, para cada URL del inventario. Las columnas que importan son clics, impresiones, posición media y CTR, sobre la ventana más larga que la herramienta permita conservar, para poder comparar un periodo reciente contra uno anterior y ver tendencia, no solo una foto fija.

El punto donde más auditorías fallan es la clave de cruce. Si el sitio tiene versiones con y sin "www", con y sin barra final, o si en algún momento existió una propiedad separada para móvil, los datos pueden estar repartidos entre propiedades distintas de Search Console y no aparecer todos bajo la misma URL. Normaliza cada URL —protocolo, dominio, barra final, minúsculas— antes de usarla como clave, o el cruce producirá filas duplicadas o vacías que no reflejan la realidad.

Una fila con impresiones pero cero clics durante varios meses es una señal distinta de una fila sin impresiones en absoluto: la primera sugiere que la página aparece en resultados pero no convence lo suficiente para el clic, mientras que la segunda sugiere que apenas se muestra, lo que apunta a un problema de indexación o relevancia, no de redacción del snippet.

Incorporar el comportamiento desde GA4

El tercer bloque de datos viene de GA4, a nivel de página de aterrizaje: sesiones, tasa de interacción o tiempo medio de interacción, y los eventos clave que el sitio tenga definidos como conversión, si los hay. Estos datos añaden algo que Search Console no mide: qué pasa después del clic. Una página puede tener una posición y un CTR aceptables y, aun así, una tasa de interacción baja que indique que el contenido no responde a la intención real de quien buscó.

Dos advertencias específicas de GA4 conviene tener presentes. La primera es la retención de datos: por defecto GA4 conserva los datos de eventos durante un periodo limitado, así que si la auditoría necesita comparar contra un histórico más largo, hace falta haber exportado los datos a BigQuery con antelación; no se puede recuperar retroactivamente lo que ya se purgó. La segunda es que en sitios con mucho tráfico algunos informes de la interfaz pueden aplicar umbrales de agregación que conviene contrastar contra la API si un número resulta inconsistente con lo que reporta Search Console para la misma URL.

El cruce con el inventario y con Search Console usa la misma disciplina de normalización: la ruta de la página de aterrizaje en GA4 rara vez incluye el dominio completo, y puede llevar parámetros de consulta que Search Console ya agrega sin ellos. Decide un formato de URL normalizado —por ejemplo, ruta sin parámetros ni barra final— y aplícalo a las tres fuentes antes de unirlas, no después.

El cruce final: una tabla, no tres hojas sueltas

El objetivo de todo lo anterior es una sola tabla con una fila por URL normalizada, donde cada columna viene de una fuente distinta. Mantener el crawl, Search Console y GA4 en pestañas separadas —y comparar mentalmente— es exactamente el trabajo manual que la auditoría existe para eliminar. Un BUSCARV (VLOOKUP), un JOIN en SQL o un merge programado en un script son formas válidas de construir esta tabla; lo que no es válido es unir por la URL sin normalizar primero, porque una sola inconsistencia de mayúsculas o de barra final puede convertir una fila real en dos filas vacías.

Cuantos más datos tenga cada fila, mejor puede sostenerse la decisión final. Como mínimo, cada fila debería incluir:

• URL normalizada y URL canónica declarada
• Código de estado, indexabilidad y presencia de noindex
• Recuento de palabras y fecha de última actualización
• Enlaces internos entrantes según el crawl
• Clics, impresiones, posición media y CTR de Search Console
• Sesiones y tasa de interacción desde GA4
• Conversiones o eventos clave, si el sitio los define
• Backlinks externos, si se dispone de una herramienta que los reporte

No todas las columnas pesan igual en la decisión, pero tenerlas juntas permite hacer preguntas cruzadas —posición media buena con CTR bajo, o muchos enlaces internos con cero impresiones— difíciles de detectar mirando cada fuente por separado.

Puntuar sin fingir una precisión que los datos no tienen

Una puntuación numérica ayuda a ordenar cientos de filas, pero conviene no tratarla como una medición exacta: es una regla de decisión repetible, no una ciencia. Un enfoque que funciona razonablemente bien es comparar cada URL contra su propio historial —por ejemplo, clics e impresiones de los últimos noventa días frente a los noventa anteriores— en lugar de comparar URLs de temas distintos entre sí, porque una página informativa y una página transaccional no son comparables en volumen absoluto aunque ambas cumplan bien su función.

La tendencia importa más que el nivel. Una página con pocas visitas pero estable está en una situación distinta de una página con más visitas pero en caída sostenida durante varios trimestres. Combinar la dirección de la tendencia con la posición media y con la relevancia del tema para el negocio da una puntuación suficientemente útil sin necesitar una fórmula elaborada.

Vale la pena aislar como segmento propio las filas con impresiones pero cero clics sostenidos: no encajan bien ni en "funciona" ni en "no funciona", porque el problema no es de fondo sino de presentación en el resultado de búsqueda, y la corrección —título, meta descripción, datos estructurados— es distinta de la que necesita una página sin impresiones.

De la puntuación a la decisión: conservar, actualizar, fusionar o eliminar

Con la tabla puntuada, cada fila cae razonablemente bien en una de cuatro categorías. Qué hacer exactamente con cada página concreta pertenece a otros artículos de este blog dedicados al refresco y a la eliminación de contenido; aquí la auditoría solo necesita asignar la categoría correcta a cada fila.

La frontera entre "actualizar" y "fusionar" es la que más juicio exige: si dos páginas cubren temas distintos pero relacionados y ambas funcionan razonablemente, lo correcto suele ser actualizarlas por separado y enlazarlas entre sí; si cubren esencialmente la misma intención y se canibalizan en las mismas consultas, fusionarlas con una redirección 301 hacia la versión que se conserve suele recuperar más posición combinada que mantener ambas compitiendo entre sí.

• Conservar: tendencia estable o positiva, tema todavía relevante, sin solapamiento con otra URL del sitio.
• Actualizar: tendencia en caída pero el tema sigue siendo relevante, información desactualizada, o contenido más delgado que el de las páginas que hoy ocupan las primeras posiciones.
• Fusionar: dos o más URLs compiten por la misma intención de búsqueda, dividiendo enlaces internos y autoridad entre ellas, algo que suele verse en Search Console como consultas casi idénticas repartidas entre varias páginas.
• Eliminar o desindexar: impresiones nulas o casi nulas de forma sostenida, tema ya no relevante para el sitio, contenido delgado sin mejora razonable, sin enlaces internos ni externos que lo sostengan.

Errores frecuentes al construir la auditoría

La mayoría de las auditorías que no llegan a producir decisiones útiles fallan antes de la puntuación, en la fase de construcción de la tabla. Los errores más comunes son estructurales, no de criterio:

• Rastrear solo desde el sitemap XML y no desde los enlaces internos, lo que oculta páginas huérfanas y páginas listadas que ya nadie enlaza.
• Cruzar por URL sin normalizar mayúsculas, barra final o parámetros, lo que crea filas duplicadas o vacías que distorsionan la puntuación.
• Pedir datos de Search Console sobre una ventana demasiado corta, lo que oculta contenido estacional que parece muerto fuera de temporada y no lo está.
• Usar el recuento de palabras como sinónimo de calidad, cuando una página corta pero completa puede rendir mejor que una larga y diluida.
• Hacer la auditoría una sola vez y no repetirla, con lo que la tabla queda desactualizada en meses y las decisiones que se tomaron dejan de reflejar la realidad.
• No asignar un responsable a cada fila, de modo que la categoría quede anotada en la tabla pero nadie ejecute la actualización, la fusión o la eliminación.

Ninguno de estos errores es difícil de evitar, pero todos son fáciles de cometer bajo presión de tiempo, porque construir bien el inventario y el cruce de datos suele llevar más horas que puntuar las filas o decidir qué hacer con cada una. Una auditoría que se repite cuesta cada vez menos, porque el inventario y los scripts de cruce ya existen y solo hay que volver a ejecutarlos con datos frescos.