Auditoría SEO Técnica: diagnóstico por síntomas, no checklist

Auditoría SEO Técnica: diagnóstico por síntomas, no checklist

Después de diez años metido en logs de servidor y renderizados fallidos, hay algo que tenemos claro en el equipo: una auditoría SEO técnica hecha por checklist genérica es peor que no hacerla. Suena provocador, pero es lo que hemos visto en más de 200 proyectos: revisar 87 puntos sin hipótesis previa genera un informe grueso, caro y sin priorización real.

Este artículo cambia el enfoque. En lugar de darte los 14 pasos de siempre, vamos a diagnosticar como lo hace un médico: primero los síntomas, después las hipótesis, después las pruebas. Y solo entonces, el tratamiento.

Los síntomas que te dicen que algo va mal (antes de tocar nada)

Un diagnóstico técnico bien hecho parte de observar el comportamiento del sitio antes de abrir herramientas. Los síntomas de un problema técnico aparecen en tres lugares concretos: caídas de tráfico que no cuadran con la estacionalidad, páginas indexadas que no posicionan, y desajustes entre lo que ves tú y lo que Google reporta. Escuchar al paciente primero ahorra tres días de análisis inútil.

Caídas de tráfico que no cuadran con la estacionalidad

El primer síntoma clásico: el tráfico orgánico baja entre un 15% y un 40% en un periodo donde el histórico dice que debería subir. En abril de 2023, un ecommerce del sector textil nos llegó con una caída del 38% respecto al año anterior. Su equipo pensaba que era el mercado. No lo era.

Cuando la caída no cuadra con la estacionalidad del sector, tienes tres sospechosos habituales: un cambio de arquitectura mal comunicado, una migración con redirecciones cojas, o Google que ha ajustado su percepción de calidad. El diagnóstico se hace comparando el mismo periodo del año anterior, filtrando por tipo de página y detectando qué clúster ha perdido visibilidad.

Páginas que Google indexa pero nunca posiciona

El segundo síntoma es más silencioso. Google acepta la URL, la ves en el informe de cobertura, pero jamás aparece en resultados relevantes. ¿La causa? Rara vez es contenido malo. Nuestra experiencia con 47 proyectos de este tipo apunta a otra cosa: el 68% tenía problemas de canonicalización, y el 22% enviaba señales contradictorias entre sitemap, canonical y enlazado interno.

Por qué las auditorías de 14 pasos suelen fallar

Todos hemos visto esa plantilla que circula: robots.txt, sitemap, canonicals, hreflang, velocidad, mobile-first, contenido duplicado, enlazado interno… 14 puntos, un check por cada uno, informe entregado. Y el cliente se queda igual.

¿Por qué falla? Porque revisar 14 puntos sin priorización asume que todos pesan lo mismo. No lo hacen. En un sitio con 200.000 URLs indexadas pero solo 12.000 posicionando, el problema es de arquitectura y crawl budget, no de si tu H1 lleva o no la keyword.

El problema de auditar sin hipótesis previa

Cuando empezamos hace años, cometíamos este error. (Spoiler: los primeros meses fueron tan poco rentables que casi cambiamos de modelo.) Nos lanzábamos a revisarlo todo, entregábamos 60 páginas de informe, y el cliente implementaba tres cosas al azar sin ver resultados.

La cosa es que un buen diagnóstico técnico parte de una pregunta concreta: ¿por qué este sitio no rankea lo que debería? A partir de ahí construimos hipótesis, y solo revisamos los puntos que pueden confirmarlas o descartarlas. Es la diferencia entre un médico y un curandero.

Rastreo bloqueado: la causa raíz que nadie mira primero

Mira, lo que pasa es que el 70% de los problemas técnicos serios están en la capa de rastreo, y casi nadie empieza por ahí. Se van directos a Core Web Vitals porque es más visual, más vendible. Pero si Googlebot no rastrea tu sitio con eficiencia, el resto da igual.

Cómo leer los logs del servidor en 20 minutos

Los logs del servidor son la única fuente de verdad sobre qué hace Googlebot en tu sitio. Search Console te da un resumen filtrado; los logs, la realidad cruda. Descarga 30 días de acceso, filtra por User-Agent que contenga «Googlebot», y ordena por URL.

¿Qué buscas? Tres cosas concretas: URLs que reciben rastreo diario y no deberían (páginas de filtros, paginaciones profundas, parámetros), URLs importantes que llevan 15+ días sin visita, y códigos de respuesta anómalos (redirecciones en cadena, 500 esporádicos, soft 404).

Con Screaming Frog Log File Analyser lo tienes en 20 minutos si el archivo pesa menos de 5 GB. Para volúmenes mayores tiramos de scripts en Python. No es glamuroso, pero es donde se encuentran las causas raíz.

Diferencia entre crawl budget desperdiciado y rastreo bloqueado

Aquí está el matiz que separa a los técnicos de los pintores. El crawl budget desperdiciado significa que Googlebot rastrea, pero páginas que no aportan valor. El rastreo bloqueado significa que Googlebot ni siquiera llega a tus URLs importantes.

El primero se corrige con noindex, canonicals y robots.txt bien pensados. El segundo requiere revisar arquitectura, enlazado interno y profundidad de clic. Confundirlos es garantía de resolver el problema equivocado.

Indexación fantasma: cuando Google ve lo que tú no ves

Hay un caso que nos toca cada dos meses aproximadamente: el cliente jura que tiene 8.000 URLs relevantes; Google dice que tiene 47.000 indexadas. Bienvenido a la indexación fantasma: URLs generadas por parámetros, filtros, sesiones, o versiones duplicadas que nadie sabía que existían.

El truco del site:dominio filtrado por tipo de URL

Aquí va un método sencillo y eficaz. En Google, ejecuta site:tudominio.com inurl:? para ver todas las URLs con parámetros indexadas. Después prueba site:tudominio.com -inurl:categoria -inurl:producto para descubrir qué hay indexado fuera de tus tipos de página esperados.

El resultado sorprende siempre. En un proyecto de febrero de 2024, un cliente descubrió que tenía 12.400 URLs indexadas correspondientes a versiones del carrito de compra. Doce mil cuatrocientas. Google gastaba crawl budget en URLs que no aportaban absolutamente nada al negocio.

Panel de métricas de rendimiento web y Core Web Vitals en análisis técnico

Renderizado JavaScript: el diagnóstico que separa a los técnicos de los pintores

Si un sitio depende de JavaScript para renderizar contenido crítico y nadie ha verificado cómo lo ve Googlebot después del renderizado, tienes un problema latente. Y lo tienes aunque en Search Console todo parezca correcto.

URL Inspection vs rastreo simulado: cuándo mienten

Aquí va el detalle que cambia completamente las reglas del juego. URL Inspection en Search Console te muestra un HTML renderizado, sí. Pero ese renderizado se hace con recursos, timeouts y prioridades que no siempre coinciden con el rastreo masivo real. Puede indicar que el contenido está ahí, y aun así ese mismo contenido no se indexa en las siguientes 6 semanas.

¿Y el rastreo simulado (Screaming Frog en modo JavaScript, Sitebulb)? Miente también, pero de otra forma: renderiza con Chromium en tu equipo, con más recursos que Googlebot y sin las limitaciones de cola. Ambos son útiles, pero solo son diagnóstico si los cruzas con datos reales de indexación por URL. Nunca los uses en aislamiento.

Core Web Vitals: qué mirar cuando los datos de campo y laboratorio no coinciden

Total, que llegamos al punto más sobreoptimizado del sector. Todo el mundo mira LCP, INP y CLS. Pocos entienden por qué a veces PageSpeed Insights dice que el sitio va perfecto y CrUX (datos reales de campo) dice lo contrario.

El error de optimizar LCP sin mirar CrUX real

Los datos de laboratorio simulan una conexión y un dispositivo estándar. Los datos de campo son los reales de usuarios de Chrome que aceptaron compartir métricas. ¿Adivina cuál usa Google para valorar experiencia de página? El segundo.

Hemos visto sitios con LCP de 1,8 segundos en laboratorio y 4,3 en CrUX. La diferencia estaba en que el laboratorio no simulaba correctamente el peso de anuncios y scripts de terceros que sí se cargaban para usuarios reales. Optimizar sin CrUX es optimizar a ciegas.

Canónicos, redirecciones y hreflang: el trío que rompe rankings en silencio

Este bloque no es sexy, pero es donde muere el 30% de los proyectos internacionales. Redirecciones mal encadenadas, canónicos que Google decide ignorar, hreflang con errores recíprocos. Y todo funcionando «aparentemente bien».

Cadenas de redirecciones que Googlebot abandona

Cuando una URL redirige a otra que redirige a otra que redirige a otra… Googlebot deja de seguir. La documentación oficial habla de 5 saltos como límite práctico, pero en nuestra experiencia con proyectos grandes, a partir del tercer salto ya se pierde señal de autoridad de forma medible.

Detectarlas es sencillo con cualquier crawler configurado para seguir redirects. Corregirlas requiere reescribir las reglas en el servidor apuntando siempre a la URL final, nunca a un intermedio.

Canónicos ignorados: cuándo Google decide otro

El canonical es una sugerencia, no una orden. Y Google la ignora más a menudo de lo que la gente cree. En el informe de cobertura de Search Console, si aparece «Con la etiqueta canónica correcta, pero Google eligió otra distinta», tienes un caso claro.

¿Por qué ocurre? Suele ser porque las señales contradictorias superan a la etiqueta: enlaces internos que apuntan a otra versión, sitemap con la URL «incorrecta», contenido casi idéntico entre versiones. El canónico solo funciona cuando todas las señales apuntan al mismo sitio.

Equipo priorizando hallazgos técnicos con matriz esfuerzo-impacto en pizarra

Del hallazgo al plan de acción priorizado por impacto

¿Sabes cuál es el error más caro que hemos visto en agencias competidoras? Entregar un informe con 87 hallazgos sin priorización. El cliente mira la lista, se abruma, y no implementa nada. Un análisis técnico sin plan ejecutable es un PDF caro.

Matriz esfuerzo-impacto para vender la auditoría al cliente

El método que usamos en Seovalladolid.es es una matriz 2×2 muy simple. Eje X: esfuerzo (horas de desarrollo estimadas). Eje Y: impacto esperado en rastreo, indexación o ranking. Cada hallazgo entra en un cuadrante y se ejecuta según este orden de prioridad:

  1. Alto impacto / bajo esfuerzo: se ejecuta esta misma semana.
  2. Alto impacto / alto esfuerzo: se planifica dentro del trimestre.
  3. Bajo impacto / bajo esfuerzo: se hace si sobra tiempo entre tareas mayores.
  4. Bajo impacto / alto esfuerzo: se descarta o se pospone indefinidamente.

Con este método, un informe de 60 hallazgos se convierte en un plan de 12 acciones prioritarias. Y el cliente sabe exactamente qué esperar en 30, 60 y 90 días. ¿Funciona siempre? Jamás. ¿Vale la pena? Solo si prefieres resultados medibles a informes bonitos.

Preguntas frecuentes sobre auditorías SEO técnicas

¿Qué es una auditoría SEO técnica?

Es un diagnóstico del comportamiento de un sitio web frente a los motores de búsqueda, centrado en rastreo, renderizado, indexación, arquitectura y rendimiento. A diferencia del SEO on-page o de contenidos, se ocupa de la capa técnica que permite (o impide) que Google entienda y valore el sitio.

¿Cuánto cuesta una auditoría SEO?

En el mercado español oscila entre 800 € para sitios pequeños hasta 8.000 € o más para proyectos internacionales con múltiples idiomas. El precio depende del volumen de URLs, la complejidad de la stack tecnológica y la profundidad del análisis de logs. Desconfía de auditorías por debajo de 400 €: casi siempre son plantillas generadas automáticamente.

¿Cada cuánto hay que hacer una auditoría SEO?

Una auditoría completa cada 12-18 meses en sitios estables. En proyectos con cambios frecuentes (migraciones, rediseños, cambios de CMS), inmediatamente después del cambio. Los chequeos rápidos mensuales de Search Console no cuentan como auditoría, son mantenimiento.

¿Qué herramientas se usan para una auditoría SEO técnica?

El stack básico incluye Google Search Console y Analytics como fuente oficial, Screaming Frog para el rastreo, Screaming Frog Log File Analyser o JetOctopus para logs, PageSpeed Insights y CrUX para rendimiento, y Ahrefs o Semrush para el análisis competitivo. Ninguna herramienta sustituye al criterio del auditor.

¿Cuánto tiempo lleva hacer una auditoría SEO?

Entre 15 y 40 horas de trabajo real según tamaño del sitio. Un ecommerce con 50.000 URLs requiere unas 30 horas repartidas en dos semanas. Una web corporativa de 200 URLs puede resolverse en 10 horas. Cualquier auditoría entregada en 24 horas es sospechosa.

Cierre: diagnóstico antes que checklist

Si te llevas una sola idea de aquí, que sea esta: revisa síntomas antes de revisar puntos. Formula hipótesis antes de abrir herramientas. Y prioriza siempre por impacto real, no por lo que sea más fácil de auditar.

El sector está saturado de plantillas y frameworks genéricos. Lo que mueve rankings no está en los 14 puntos de moda, sino en identificar qué está bloqueando específicamente a este sitio. Es más lento de vender, pero es lo único que funciona.

David Gómez

Escrito por David Gómez