El error más caro en SEO: auditar mal
Hace seis meses, un e-commerce español con 12.000 productos contrató una auditoría SEO. El informe tenía 47 páginas. Listaba 312 errores. Incluía capturas de Screaming Frog, gráficos de PageSpeed y una matriz de priorización con colores rojo, amarillo y verde. El problema: el equipo implementó los 312 errores en orden de aparición, dedicó tres meses de desarrollo a corregir warnings de baja prioridad y no tocó el único problema que realmente importaba: 4.200 páginas de producto con canonicals apuntando a URLs con parámetros de sesión que generaban contenido duplicado masivo. El tráfico orgánico siguió cayendo.
Esta historia se repite en empresas de todos los tamaños. La auditoría SEO no falla por falta de herramientas o por desconocimiento técnico. Falla por ausencia de metodología. Ejecutar Screaming Frog y exportar un CSV con errores no es una auditoría; es un inventario. La diferencia entre ambas cosas es exactamente lo que separa a los sitios que mejoran tras una auditoría de los que siguen estancados.
Una auditoría SEO técnica real sigue un proceso de cinco fases donde cada fase alimenta a la siguiente. No se trata de encontrar todos los errores posibles, sino de encontrar los errores que importan, entender su impacto en el negocio y priorizar las correcciones en función de un criterio que ninguna herramienta puede automatizar: el juicio sobre qué afecta más al rendimiento orgánico del sitio.
En esta guía vamos a recorrer ese proceso fase por fase, con las herramientas específicas que necesitas en cada etapa, los datos que debes extraer y cómo convertir hallazgos técnicos en un plan de acción que tu equipo de desarrollo pueda ejecutar en orden de impacto.
Por qué necesitas una auditoría SEO técnica (y cuándo hacerla)
La razón más habitual para posponer una auditoría es que “el sitio funciona bien”. Y en muchos casos es cierto: las páginas cargan, Google las indexa y el tráfico orgánico no ha caído drásticamente. Pero la salud técnica de un sitio no es binaria. No se pasa de “funciona” a “no funciona” de un día para otro. Se deteriora de forma progresiva, en silencio, hasta que un cambio algorítmico o una acumulación de deuda técnica provoca un desplome que parece repentino pero llevaba meses gestándose.
Los síntomas que justifican una auditoría técnica inmediata son concretos. Si en Google Search Console tienes más de un 15% de tus URLs en estado “Discovered - currently not indexed,” tienes un problema de crawl budget o de calidad percibida. Si tus Core Web Vitals en datos de campo (CrUX) muestran más del 25% de experiencias “pobres” en LCP o INP, estás perdiendo posiciones frente a competidores que sí las optimizan. Si después de una migración de CMS o un rediseño has notado una caída de tráfico superior al 10% que no se ha recuperado en 4 semanas, hay errores técnicos en la migración que no se detectaron.
Según datos de Ahrefs publicados en 2025, el 66% de los sitios web tienen al menos un problema técnico que impide la indexación correcta de parte de su contenido. El estudio analizó más de 100.000 dominios y encontró que los problemas más frecuentes son: páginas con tiempo de respuesta superior a 1 segundo (42%), cadenas de redirecciones con más de 2 saltos (38%), y páginas sin enlace interno apuntando a ellas —las llamadas páginas huérfanas— (27%).
Pero más allá de los números, la auditoría cumple una función que ningún monitoreo automatizado puede sustituir: ofrece una fotografía completa del estado técnico del sitio en un momento dado, con las relaciones entre problemas visibilizadas. Un error de canonical aislado es menor. Ese mismo error de canonical multiplicado por 4.000 páginas de producto y combinado con un sitemap que incluye las URLs no canónicas y un enlazado interno que apunta a la versión sin trailing slash es un problema arquitectónico que solo se ve cuando cruzas los datos de las cinco fases de la auditoría.
La frecuencia recomendada es trimestral para sitios con publicación activa y semestral para sitios más estáticos. Después de cualquier migración, la auditoría debe realizarse en la primera semana, no cuando aparezcan los síntomas.
Las herramientas mínimas que necesitas para auditar tu web
Antes de entrar en las fases de la auditoría, un punto crítico: no necesitas todas las herramientas del mercado. Necesitas las herramientas justas para cada fase, y saber exactamente qué dato extraer de cada una. La parálisis por exceso de herramientas es tan perjudicial como la falta de ellas.
El stack mínimo viable para una auditoría técnica completa consta de tres capas. La primera capa es gratuita y cubre el 60% del diagnóstico: Google Search Console proporciona los datos reales de indexación, cobertura, rendimiento en búsqueda y Core Web Vitals desde el campo. No hay sustituto para estos datos porque provienen directamente de Google. PageSpeed Insights complementa con un análisis de rendimiento página por página, tanto con datos de laboratorio (Lighthouse) como datos de campo (Chrome User Experience Report).
La segunda capa es el crawler, y aquí la herramienta estándar de facto es Screaming Frog SEO Spider. Su versión gratuita permite rastrear hasta 500 URLs y es suficiente para sitios pequeños. La versión de pago (209 libras/año) elimina esa limitación y añade funcionalidades críticas como la integración con Google Analytics, la extracción personalizada y la validación de datos estructurados. Alternativas como Sitebulb ofrecen reportes más visuales pero con menos control granular.
La tercera capa es opcional pero valiosa para sitios complejos: una plataforma de análisis que integre datos de rastreo con datos de posicionamiento. Semrush Site Audit, Ahrefs Site Audit o Moz Pro ofrecen esta combinación. Su ventaja no está en el rastreo en sí (Screaming Frog es superior para auditoría manual) sino en el monitoreo continuo y las alertas automáticas entre auditorías.
Un error frecuente es usar solo herramientas de monitoreo continuo y prescindir del crawler manual. Las plataformas all-in-one rastrean a una profundidad y frecuencia limitadas por diseño. Para una auditoría técnica real, el rastreo controlado con Screaming Frog —configurando user-agent, velocidad, reglas de exclusión y extracción personalizada— es insustituible.
Para una comparativa detallada de estas herramientas, consulta nuestro recurso sobre herramientas de auditoría SEO.
Fase 1: Rastreo completo del sitio (crawling)
El rastreo es la base sobre la que se construye toda la auditoría. Sin un crawl completo y bien configurado, cualquier análisis posterior parte de datos incompletos. La fase de rastreo no es simplemente “darle a Start en Screaming Frog”; requiere una configuración previa que determina la calidad de los resultados.
Antes de iniciar el rastreo, configura el user-agent como Googlebot Desktop (para detectar posibles problemas de cloaking o contenido condicional), establece una velocidad de rastreo que no sobrecargue el servidor (2-5 URLs por segundo para servidores compartidos, 10-20 para dedicados) y define las reglas de exclusión para URLs que no aportan valor al análisis (parámetros de tracking UTM, URLs de staging, archivos estáticos).
El rastreo debe producir un inventario completo de URLs con su código de respuesta HTTP, título y meta description, cabeceras HTTP relevantes (canonical, hreflang, X-Robots-Tag), profundidad de rastreo (clics desde la página principal), tamaño del HTML y tiempo de respuesta del servidor (TTFB). Estos datos en bruto son el material con el que trabajarás en las fases posteriores.
El crawl revela directamente errores 4xx y 5xx, redirecciones (301, 302) y cadenas de redirecciones, páginas con respuestas lentas (TTFB superior a 500 ms), URLs duplicadas con contenido idéntico o casi idéntico, y la profundidad real del sitio. Según Moz, el 90% de los problemas de rastreabilidad se detectan en esta primera fase si el crawl está correctamente configurado.
Si tienes acceso a los logs del servidor, cruza las URLs rastreadas por Screaming Frog con las URLs que Googlebot ha visitado realmente en los últimos 90 días. Este cruce revela dos tipos de problemas: páginas que Screaming Frog encuentra pero Googlebot no visita (posibles problemas de priorización) y páginas que Googlebot visita repetidamente sin que aparezcan en la navegación principal (posible trampa de crawl por URLs parametrizadas).
El resultado de esta fase debe ser un archivo estructurado (Excel o CSV) con todas las URLs, sus códigos de respuesta y las métricas clave. Este archivo es la base de datos de toda la auditoría y se referenciará en cada fase posterior.
Fase 2: Análisis de indexación y cobertura
Una vez completado el rastreo, la segunda fase cruza los datos del crawl con los datos de Google Search Console para entender qué ve Google realmente de tu sitio. La diferencia entre lo que tu crawler encuentra y lo que Google tiene indexado es, con frecuencia, donde se esconden los problemas más graves.
El informe de Cobertura de Google Search Console (ahora llamado “Páginas”) clasifica tus URLs en cuatro estados: válidas indexadas, válidas no indexadas, con errores y excluidas. Cada estado tiene subtipos que indican la razón específica. Los más relevantes para la auditoría son “Discovered - currently not indexed” (Google conoce la URL pero no la ha rastreado), “Crawled - currently not indexed” (Google la rastreó pero decidió no indexarla) y “Duplicate without user-selected canonical” (Google detectó duplicados y eligió su propio canonical).
Compara el total de URLs rastreadas por Screaming Frog con el total de URLs indexadas según GSC. Si hay una diferencia superior al 20%, investiga las URLs que están en tu crawl pero no en el índice. Filtra por tipo: ¿son páginas de producto? ¿Páginas de categoría? ¿Posts de blog? El patrón indica si el problema es de crawl budget, de calidad de contenido o de señales técnicas contradictorias.
Esta fase es donde los problemas de canonicals se hacen visibles. Exporta de Screaming Frog todas las URLs con su canonical declarado y compara: ¿la URL canónica coincide con la URL real? ¿Hay páginas con canonical autorreferencial apuntando a una URL con parámetros? ¿Hay canonicals apuntando a páginas que devuelven 404? Cada una de estas discrepancias genera confusión para Googlebot y diluye la autoridad de la página correcta.
Descarga tu sitemap XML y compara sus URLs con las del crawl y las del índice de Google. Un sitemap bien mantenido solo debe incluir URLs que devuelven 200, tienen canonical autorreferencial y quieres que Google indexe. Las discrepancias más comunes son: URLs en el sitemap que devuelven 301 (deben actualizarse al destino final), URLs en el sitemap con canonical apuntando a otra página, y URLs indexadas que no aparecen en el sitemap (posibles páginas huérfanas que Google encontró por otros medios).
El resultado de esta fase es un diagnóstico claro del gap entre el sitio que tienes y el sitio que Google conoce, con las causas identificadas para cada discrepancia.
Fase 3: Evaluación de Core Web Vitals y rendimiento
La tercera fase se centra en cómo experimenta el usuario (y Google) la velocidad y estabilidad del sitio. Los Core Web Vitals son señales de ranking confirmadas desde 2021, y los datos muestran que su impacto va más allá del posicionamiento: según Web.dev, mejorar el LCP de 4 segundos a menos de 2,5 segundos puede incrementar las conversiones en un 15-25%.
Los datos de campo (Chrome User Experience Report, accesibles vía GSC y PageSpeed Insights) reflejan la experiencia real de usuarios con conexiones y dispositivos reales. Los datos de laboratorio (Lighthouse) son simulaciones en condiciones controladas. Para la auditoría, los datos de campo son los que Google usa para ranking; los de laboratorio son útiles para diagnosticar causas específicas. Muchas auditorías ignoran esta distinción y trabajan solo con datos de laboratorio, lo que puede llevar a priorizaciones equivocadas.
Analiza las páginas con peor LCP en datos de campo. Las causas más comunes de un LCP lento son imágenes hero sin optimizar (formato, tamaño, lazy loading incorrecto del elemento LCP), fuentes web que bloquean el renderizado (falta de font-display: swap o preload), CSS y JavaScript que bloquean el renderizado, y tiempo de respuesta del servidor lento por consultas a base de datos sin cachear.
El INP reemplazó al FID en marzo de 2024 y mide la latencia de todas las interacciones del usuario, no solo la primera. Los problemas de INP suelen originarse en JavaScript pesado que bloquea el hilo principal: event handlers con lógica compleja, hydration de frameworks JavaScript en el cliente, y scripts de terceros (analytics, chat widgets, publicidad) que compiten por el hilo principal.
El CLS mide cuánto se mueve el contenido visible mientras la página carga. Las causas más frecuentes son imágenes y vídeos sin dimensiones explícitas (width/height en HTML), anuncios o banners que se insertan dinámicamente desplazando el contenido, fuentes web que provocan un reflow cuando sustituyen a la fuente del sistema, y contenido inyectado por JavaScript encima del viewport.
No todas las páginas merecen el mismo nivel de optimización. Prioriza las páginas con más tráfico orgánico, más conversiones o mayor potencial de posicionamiento. Una página de producto con 10.000 visitas mensuales y un LCP de 5 segundos tiene más urgencia que una página de política de privacidad con un LCP de 4 segundos.
Fase 4: Arquitectura, enlaces internos y estructura de URLs
La cuarta fase evalúa la estructura del sitio como sistema interconectado. Mientras las fases anteriores analizan páginas individuales o grupos de páginas, esta fase se centra en las relaciones entre ellas: cómo fluye el enlazado interno, cómo se distribuye la autoridad y si la estructura de URLs es consistente.
Utilizando los datos del crawl de la Fase 1, analiza la distribución de profundidad de tus páginas. La regla general es que ninguna página estratégica debería estar a más de 3 clics de la portada. En la práctica, los e-commerces con múltiples niveles de categorías suelen tener productos a 5-6 clics de profundidad, lo que reduce la probabilidad de que Googlebot los rastree con frecuencia y de que acumulen PageRank interno.
Identifica las páginas que no reciben ningún enlace interno. Estas páginas solo pueden ser descubiertas por Google a través del sitemap o de enlaces externos, lo que las hace vulnerables a problemas de indexación. Screaming Frog permite filtrar las páginas con cero inlinks internos. Cruza esta lista con el rendimiento en GSC: si una página huérfana tiene impresiones o clics, está siendo encontrada por otros medios pero sería más efectiva con enlazado interno.
Analiza qué páginas reciben más enlaces internos y si esa distribución se alinea con tus prioridades de negocio. Es habitual encontrar que las páginas legales (aviso legal, política de privacidad) reciben más enlaces internos que las páginas de servicio o producto porque aparecen en el footer de todo el sitio. Esto no es un problema en sí, pero indica que las páginas estratégicas necesitan enlazado interno adicional desde el contenido relevante.
La verificación de consistencia de URLs (que John Mueller de Google describió como “el mayor factor de SEO técnico”) requiere comprobar que la misma URL aparece de forma idéntica en cuatro ubicaciones: enlaces internos, canonical declarado, sitemap XML y datos estructurados. Las discrepancias más frecuentes son trailing slash inconsistente (con y sin /), protocolo inconsistente (http vs https en enlaces internos residuales), y parámetros añadidos por el CMS o herramientas de analytics.
Las URLs óptimas para SEO son cortas, contienen las palabras clave del contenido, usan guiones como separadores y mantienen una jerarquía lógica que refleja la arquitectura del sitio.
Cómo generar el informe final con errores priorizados
La fase final es donde la auditoría se convierte en un documento accionable. Un informe que lista 300 errores sin priorización es inútil. Un informe que identifica los 15 problemas que más impactan al tráfico orgánico y los ordena por relación esfuerzo/impacto es lo que permite a un equipo de desarrollo actuar con eficacia.
Matriz de priorización: cada hallazgo de la auditoría debe clasificarse en dos ejes: impacto en SEO (alto, medio, bajo) y esfuerzo de implementación (alto, medio, bajo). Los problemas de alto impacto y bajo esfuerzo se implementan primero. Los de alto impacto y alto esfuerzo se planifican para el próximo sprint de desarrollo. Los de bajo impacto, independientemente del esfuerzo, se documentan pero no se priorizan.
Criterios de impacto: el impacto no se mide por la gravedad teórica del error sino por su efecto real en el tráfico y las conversiones. Un error de canonical que afecta a 4.000 páginas de producto con tráfico orgánico activo tiene más impacto que 200 errores 404 en URLs que nunca recibieron tráfico. Para determinar el impacto, cruza los hallazgos técnicos con los datos de rendimiento de GSC y Google Analytics: ¿las páginas afectadas generan tráfico? ¿Tienen potencial de posicionamiento para keywords relevantes?
Estructura del informe: un informe de auditoría efectivo tiene cinco secciones. El resumen ejecutivo (1 página) con los 3-5 hallazgos más críticos y su impacto estimado en tráfico. El diagnóstico detallado organizado por las fases de la auditoría, con capturas y datos que respalden cada hallazgo. La matriz de priorización con todos los errores clasificados. El plan de acción con las tareas concretas, el responsable y el plazo estimado. Y los KPIs de seguimiento: las métricas que se medirán 30, 60 y 90 días después de implementar las correcciones.
Comunicar a equipos no técnicos: si el informe va dirigido a dirección o marketing, traduce los hallazgos técnicos a impacto de negocio. “4.200 páginas con canonical incorrecto” no comunica urgencia. “4.200 páginas de producto que compiten entre sí en Google, diluyendo el tráfico orgánico de la categoría que genera el 40% de los ingresos” sí lo hace. Según Moz, las auditorías que traducen hallazgos a impacto de negocio tienen un 3x más probabilidad de que sus recomendaciones se implementen.
Seguimiento post-auditoría: la auditoría no termina con el informe. Establece un calendario de verificación para confirmar que las correcciones implementadas han tenido el efecto esperado. Tras las correcciones de canonicals, verifica en GSC que las URLs duplicadas reducen progresivamente. Tras las mejoras de rendimiento, comprueba en CrUX que los Core Web Vitals mejoran en datos de campo (no solo en laboratorio). Tras los cambios de arquitectura, monitoriza la distribución de profundidad en el siguiente crawl completo.
La diferencia entre una auditoría que genera resultados y una que se queda en un PDF archivado no está en la sofisticación del análisis. Está en la claridad del plan de acción y en el seguimiento disciplinado de su implementación. Una auditoría mediocre bien ejecutada supera siempre a una auditoría brillante que nadie implementa.