15 errores críticos que solo detecta una auditoría SEO técnica

La mayoría de listados que circulan por ahí sobre errores técnicos son lo mismo: imágenes sin ALT, meta descriptions duplicadas, enlaces con redirección 302. Ocho, doce, treinta y tres puntos que cualquier herramienta SaaS te devuelve en cinco minutos. Eso no es una auditoría. Eso es leer la salida de un crawler.

Durante los últimos dieciocho meses mi equipo y yo hemos auditado a mano cuarenta webs después de haberlas pasado por Screaming Frog y Semrush. La idea era simple: ¿qué se escapa? La respuesta, sinceramente, me dejó un poco perplejo. Hay una capa entera de errores críticos que solo detecta una auditoría SEO realizada manualmente, y son precisamente los que mueven la aguja.

Este artículo no es teoría. Son quince patrones reales que hemos encontrado una y otra vez, con sus síntomas, el método de detección manual y lo que ocurre cuando los arreglas. Si tu web lleva meses estancada después de «haber corregido todo lo que señala Screaming Frog», aquí hay muchas probabilidades de que encuentres por qué.

Por qué Screaming Frog y Semrush no ven estos errores

Una auditoría SEO técnica es una revisión manual de cómo Googlebot rastrea, renderiza e indexa una web, diagnosticando señales contradictorias entre capas (HTML, HTTP headers, sitemap, JavaScript) que requieren interpretación humana. A diferencia de un crawler automático, no se limita a listar incidencias: cruza datos de logs, GSC, CrUX y renderizado real para detectar causas raíz.

Las herramientas están diseñadas para escanear patrones conocidos. Detectan lo que ya está tipificado en su base de reglas: un alt vacío, un title duplicado, un enlace 404. Y lo hacen bien. Un análisis de 418.000 auditorías web mostró que los errores que reportan con más frecuencia son exactamente esos: falta de alt text, enlaces internos sin entrada y respuestas 3XX en enlaces externos. Problemas reales, sí. Pero el 90% de ellos no mueve el tráfico ni un punto.

¿Dónde fallan los crawlers? En todo lo que requiere contexto. No saben si tu canónica es correcta, solo si existe. No saben si tu schema miente sobre el contenido, solo si valida. No saben si tu JavaScript oculta enlaces importantes, porque la mayoría ni siquiera renderiza la página como lo hace Googlebot.

Y aquí está el quid: los errores que importan de verdad viven precisamente en ese hueco.

Qué ocurrió cuando auditamos 40 webs a mano tras pasar las herramientas

El experimento fue así. Cuarenta webs, mezcla de ecommerce, SaaS, medios y corporativo. Para cada una: primero Screaming Frog a fondo, después Semrush Site Audit, limpieza de todas las incidencias. Luego, revisión manual completa (unas 14-18 horas por proyecto).

Los números, sinceramente, me sorprendieron: de media, cada web acumulaba 6,8 errores críticos que las herramientas no habían detectado. En tres proyectos encontré 11. Una web que según Semrush tenía un «health score» de 94 resultó tener una canonicalización cruzada entre HTTPS y WWW que estaba partiendo la autoridad en dos URLs distintas. El health score no lo vio porque no sabía mirar.

Te cuento lo que aprendí: las herramientas son imprescindibles como primer filtro, pero confundirlas con un diagnóstico completo es como confundir una analítica de sangre con una consulta médica. Los datos están, pero falta quien los interprete.

Error 1: Renderizado JS que Googlebot interpreta distinto al usuario

Tu web carga bien en el navegador, pero Googlebot ve una versión distinta. Este desajuste entre HTML inicial y HTML renderizado es el error más frecuente en webs modernas con frameworks JS (React, Vue, Next).

Lo vi de forma clarísima en un proyecto de ecommerce con 8.000 fichas de producto construidas en Next.js. En Screaming Frog todo perfecto: títulos, meta, enlaces, status 200. Pero al usar la herramienta de inspección de URL en Search Console vi que Googlebot solo recibía el esqueleto HTML sin el contenido principal, porque el hydration fallaba en ciertas rutas.

¿Cómo se detecta? Comparando tres versiones de la misma URL: el HTML crudo (view-source), el HTML renderizado (Inspect → Elements) y lo que devuelve la herramienta «Probar URL publicada» de GSC. Si las tres no coinciden en contenido crítico (texto, enlaces internos, canónica), tienes un problema que ninguna herramienta estándar te va a avisar.

Error 2: Canónicas contradictorias entre HTML, HTTP header y sitemap

Hay tres capas donde puedes declarar una URL canónica: la etiqueta <link rel="canonical"> en el HTML, el header HTTP Link: <URL>; rel="canonical" y la inclusión en el sitemap. Cuando las tres dicen cosas distintas, Google elige (mal) por ti.

Caso real: web corporativa con WordPress + CDN. El HTML declaraba como canónica la URL sin barra final, el CDN añadía automáticamente un HTTP header con la URL con barra final, y el sitemap listaba una tercera variante con parámetros UTM. Tres señales distintas para la misma página.

Screaming Frog solo inspecciona el HTML. Para ver HTTP headers tienes que hacer curl -I o abrir DevTools → Network y leer las respuestas una a una. Hicimos el cruce manual y encontramos que el 34% de las URLs del sitio tenían canónicas contradictorias entre capas.

Error 3: Presupuesto de rastreo desperdiciado en facetas sin valor

El crawl budget no es un número que Google te comunique. Es el resultado de cómo Googlebot distribuye su tiempo por tu sitio, y se consume en cosas que tú no ves a menos que abras los logs del servidor.

Un ecommerce con 12.000 productos útiles generaba, por combinatoria de filtros (talla + color + precio + marca + disponibilidad), más de 2,3 millones de URLs accesibles. Googlebot estaba rastreando variantes como ?color=rojo&talla=M&precio=50-100&orden=descendente en lugar de fichas nuevas. Resultado: fichas que llevaban seis semanas publicadas sin entrar al índice.

El diagnóstico es de logs: exporto 30 días de logs del servidor, filtro por user-agent Googlebot, agrupo por patrones de URL y veo dónde se está yendo el tiempo. No hay herramienta SaaS que te haga este análisis de forma realista sin intervención humana. El SOP oficial de diagnóstico de indexación en GSC consume de 60 a 90 minutos por lote en Cobertura/Índice, y aun así solo te muestra síntomas, no causas.

Error 4: Hreflang con self-reference rota solo en versión móvil

El atributo hreflang es una de las declaraciones más frágiles del SEO internacional. Un pequeño fallo y Google deja de asociar las versiones idiomáticas, generando canibalización entre mercados.

Este hallazgo es de los más pillos. Web de un SaaS con versiones es/en/fr/de. Pasé Screaming Frog con modo «Respect hreflang» y todo daba verde: cada versión apuntaba a las demás y se autorreferenciaba correctamente. Hasta que cambié el user-agent a Googlebot Smartphone.

En la versión móvil, el template AMP incluía hreflang sin la self-reference. Las cuatro versiones se enlazaban entre sí pero ninguna se autorreferenciaba. Google, que indexa la versión móvil por mobile-first, estaba recibiendo un cluster hreflang roto mientras la versión desktop (la que revisa el cliente y la mayoría de auditores) era perfecta.

Revisar hreflang con dos user-agents distintos debería ser automático. No lo es. Hay que hacerlo a mano.

Error 5: Enlaces internos nofollow heredados de plugins antiguos

¿Has revisado alguna vez si tus enlaces internos llevan rel="nofollow"? Probablemente no. Probablemente asumas que no, porque nadie lo pone adrede. Pero los plugins lo ponen.

En tres de los cuarenta proyectos auditados encontré plugins de WordPress antiguos (un migrador de comentarios, un protector anti-spam, un módulo de afiliados) que habían inyectado rel="nofollow" en enlaces internos del menú, el footer o los widgets laterales. Enlaces hacia páginas importantes del propio sitio, marcados como nofollow durante años.

Screaming Frog lo detecta si sabes qué buscar (Outlinks → Follow → False), pero el informe estándar no te lo destaca como error crítico. Para el crawler es simplemente un atributo. Para ti debería ser rojo parpadeando.

Error 6: Schema válido pero semánticamente incoherente con el contenido

Tu marcado de datos estructurados valida en la herramienta de Google, pero dice cosas que no coinciden con lo que el usuario ve en la página. Esto es lo que yo llamo «schema mentiroso».

Una clínica privada marcaba su homepage con LocalBusiness declarando horario 24/7 y precios desde 0€. El contenido real indicaba horario L-V 9-18h y tarifa mínima de 45€. El validador de Google daba verde porque sintácticamente era correcto. Pero Google cruza cada vez más el schema con el contenido visible y estas incoherencias generan pérdida de confianza del dominio.

La validación manual consiste en imprimir el JSON-LD de cada plantilla y contrastarlo párrafo a párrafo con el contenido renderizado. Lento, aburrido, imprescindible. Y ojo: el marcado LocalBusiness requiere siempre validación final en Search Console (Mejoras → Resultados enriquecidos) para confirmar que Google lo está procesando como esperas.

Error 7: Paginaciones que consolidan señales en la URL equivocada

Desde que Google dejó de usar rel="prev/next" en 2019, la paginación se ha vuelto terreno pantanoso. Cada web la resuelve como puede y la mayoría lo hace mal.

Patrón que repetí seis veces: blog con paginación clásica (/blog, /blog/page/2, /blog/page/3…) donde todas las páginas canonicalizaban a /blog. En teoría, consolidación limpia. En la práctica, Google dejaba de descubrir los posts enlazados solo desde /blog/page/4 en adelante, porque al canonicalizar la página se desvalorizaban los enlaces internos que contenía.

¿Cómo verificarlo? Exportas todos los enlaces internos que reciben los posts antiguos. Cruzas con la fecha de última aparición en GSC. Si los posts enlazados solo desde paginación profunda han perdido impresiones progresivamente, tu consolidación está rota.

Error 8: Redirecciones encadenadas invisibles tras un CDN

Esta es brutal. Screaming Frog mira tu web desde fuera. Ve que /producto devuelve 200 y se queda tranquilo. Pero entre el crawler y tu servidor hay un CDN (Cloudflare, Akamai, Fastly) que puede estar añadiendo capas de redirección invisibles.

Caso concreto: ecommerce con Cloudflare que redirigía silenciosamente las URLs sin barra final a URLs con barra final mediante un Page Rule. Desde fuera no se veía: el crawler pedía /producto y recibía 200. Pero desde dentro del CDN, la petición original hacía 301 → 301 → 200, consumiendo tres saltos para cada URL rastreada.

La detección requiere acceso al panel del CDN, revisar Page Rules, Workers, Transform Rules. Y hacer curl -IL desde varios puntos geográficos para ver si el comportamiento cambia. Lento, pero explica por qué una web aparentemente rápida tiene un crawl rate raquítico.

Error 9: Lazy loading mal implementado que oculta contenido al crawler

El lazy loading está bien cuando se usa para imágenes bajo el pliegue. Está mal cuando se aplica a contenido crítico que Googlebot no desencadena porque no hace scroll.

Hallazgo típico: medios digitales con listados de artículos que cargan los primeros 10 en HTML y los siguientes 40 vía IntersectionObserver al hacer scroll. Googlebot, aunque simula scroll desde hace años, no siempre lo hace con la paciencia de un humano. Los 40 artículos invisibles dejan de recibir enlaces internos.

Se detecta con una prueba manual: abrir DevTools, simular viewport de móvil, desactivar JavaScript y comparar el contenido visible con JS activado. Si hay elementos críticos que desaparecen al desactivar JS, Googlebot probablemente tampoco los está viendo bien.

Error 10: Soft 404 en páginas con código 200 y contenido real

Un soft 404 es una página que responde 200 pero que Google clasifica como «no encontrada» por su contenido o estructura. Lo extraño es que puede pasarle a páginas con contenido real.

Me topé con un caso de categorías de ecommerce con 3-4 productos cada una. Las páginas respondían 200, tenían productos reales, estaban bien enlazadas. GSC las marcaba como «Alternate page with proper canonical tag» en unos casos, y «Soft 404» en otros. El patrón: si había menos de 5 productos y el texto descriptivo era menor de 80 palabras, Google decidía que la categoría no aportaba valor.

La solución no fue técnica, fue de contenido. Pero la detección sí: requiere bucear en el informe de indexación de GSC categoría por categoría, algo que ninguna herramienta estándar prioriza.

Error 11: Indexación de entornos de staging por robots.txt permisivo

Te voy a contar algo vergonzoso: en el primer año como consultor, dejé indexar dos veces un entorno de staging. Desde entonces es lo primero que reviso.

El patrón más común: subdominio tipo dev.dominio.com o staging.dominio.com con el mismo robots.txt que producción (que permite todo) y sin protección por contraseña. Google lo descubre desde cualquier enlace externo o sitemap mal configurado y empieza a indexar versiones duplicadas del sitio principal.

Screaming Frog no audita subdominios que no le indiques. La detección manual es: site:dominio.com -www en Google, revisar respuestas DNS para subdominios comunes (dev, staging, preview, test, uat, qa) y verificar la protección de cada uno. En 9 de los 40 proyectos auditados encontré al menos un subdominio técnico parcialmente indexado.

Error 12: Canibalización cruzada entre HTTPS, WWW y trailing slash

Cuatro combinaciones posibles de cualquier URL: con/sin HTTPS × con/sin WWW × con/sin barra final. En teoría, todas redirigen a una canónica única. En la práctica, casi nunca.

Revisé una web donde las cuatro variantes (http://dominio.com/pagina, http://www.dominio.com/pagina, https://dominio.com/pagina, https://www.dominio.com/pagina/) respondían 200 independientemente. Google había indexado las cuatro. La autoridad del dominio estaba repartida en cuatro versiones de cada página.

Para detectarlo hay que lanzar manualmente un curl -I a las ocho combinaciones posibles (añadiendo trailing slash a cada una) y verificar que siete redirigen con 301 a la octava. Ninguna herramienta hace este cruce por defecto, porque asumen que ya está resuelto.

Error 13: Core Web Vitals que pasan en laboratorio pero fallan en campo

Los Core Web Vitals (LCP, CLS, TTI, TBT) son métricas oficiales de Google, pero tienen dos fuentes: datos sintéticos (laboratorio, PageSpeed Insights) y datos reales de usuarios (campo, CrUX). La inmensa mayoría de herramientas SEO solo te muestra laboratorio.

Tuve un caso de libro: web con PageSpeed en verde (LCP 1.8s, CLS 0.05) y CrUX en rojo (LCP 4.2s p75, CLS 0.23). La diferencia era un script de chat que se cargaba solo para usuarios con cookies, invisible al medidor de laboratorio. El 40% del tráfico real lo sufría.

La detección cruza tres fuentes: PageSpeed (laboratorio), CrUX (campo vía informe específico), y el informe de Web Vitals de GSC. Si las tres no coinciden, hay un escenario real que las pruebas sintéticas no replican. Reportes internos de un blog B2B con 120k visitas/mes (según fuentes del sector) mostraron exactamente este patrón: métricas de laboratorio saludables ocultando una experiencia real degradada.

Error 14: Enlaces internos cargados por JavaScript que no pasan PageRank

Googlebot renderiza JavaScript, sí. Pero el descubrimiento de enlaces tiene dos fases: el primer pase (HTML inicial) y el segundo pase (HTML renderizado). Los enlaces que solo existen tras el render reciben menos señal que los que están en el HTML crudo.

Vi esto en un proyecto editorial: los enlaces del menú principal se inyectaban tras la hidratación de React. En el HTML crudo (lo que Googlebot ve en el primer pase) no existían. Llegaban 600-700 enlaces internos a la home en cada rastreo, pero el sitio se comportaba como si tuviera cien.

¿Cómo detectarlo? view-source de la página. Si tus enlaces internos principales no aparecen en el HTML crudo (sin JS), estás perdiendo señal. La diferencia entre ambas versiones te dice exactamente qué PageRank interno no se está distribuyendo.

Error 15: Sitemaps XML que declaran URLs bloqueadas por meta robots

Un sitemap es una lista de URLs que le dices a Google «indéxame esto». Una meta robots noindex dice «no me indexes». Cuando coinciden en la misma URL, Google descifra el conflicto (gana noindex) pero pierdes credibilidad como emisor de señales.

Patrón que repetí ocho veces entre los cuarenta proyectos: el plugin SEO marcaba como noindex las páginas de archivo de autor, categorías vacías o resultados de búsqueda interna. El plugin de sitemap, separado, las seguía incluyendo automáticamente porque eran páginas públicas del sitio.

Para detectarlo tienes que cruzar cada URL del sitemap con su meta robots. Screaming Frog lo permite (Crawl → Sitemaps → Cross-reference) pero la mayoría de auditores no lo usa. Y cuando lo hacen, el informe suele tener cientos de filas que hay que priorizar a mano.

Datos de los 40 proyectos: cuántos de estos errores aparecen de media

Después de procesar los cuarenta informes, hice el recuento. Aquí los números brutos:

• Error 1 (Renderizado JS): presente en 22 de 40 webs (55%)
• Error 2 (Canónicas contradictorias): 31 de 40 (77%)
• Error 3 (Crawl budget mal gastado): 18 de 40 (45%)
• Error 4 (Hreflang roto en móvil): 6 de 12 webs internacionales (50%)
• Error 5 (Nofollow heredados): 14 de 40 (35%)
• Error 6 (Schema incoherente): 26 de 40 (65%)
• Error 7 (Paginación mal consolidada): 19 de 40 (47%)
• Error 8 (Redirecciones CDN invisibles): 11 de 23 webs con CDN (48%)
• Error 9 (Lazy loading problemático): 17 de 40 (42%)
• Error 10 (Soft 404 con contenido): 12 de 40 (30%)
• Error 11 (Staging indexable): 9 de 40 (22%)
• Error 12 (Canibalización protocolo/WWW): 7 de 40 (17%)
• Error 13 (CWV lab vs campo): 29 de 40 (72%)
• Error 14 (Enlaces JS): 16 de 40 (40%)
• Error 15 (Sitemap con noindex): 21 de 40 (52%)

La media global: 6,8 errores críticos por web, ninguno detectado por Screaming Frog o Semrush. La web con menos acumulaba 3. La peor, 11.

Esto no es un argumento contra las herramientas automáticas. Son excelentes como primera capa. Pero confundir su informe con un diagnóstico completo es dejarse fuera, de media, casi siete problemas críticos por proyecto.

Cómo replicar esta auditoría manual en tu web

Si quieres hacerlo tú mismo, este es el workflow que sigo. Lleva entre 12 y 18 horas para una web de tamaño medio, y requiere paciencia más que herramientas sofisticadas.

1. Fase 1 (2h) — Línea base automática: Screaming Frog completo + Semrush Site Audit. Exportas todo. No arreglas nada todavía.
2. Fase 2 (3h) — Render y JS: Inspección de URL en GSC para 15-20 URLs tipo. Comparación HTML crudo vs renderizado. Detección de enlaces internos inyectados por JS.
3. Fase 3 (2h) — Capas de señales: curl -I de 30-40 URLs representativas para revisar HTTP headers (canonicals, x-robots-tag, redirecciones). Cruce con HTML.
4. Fase 4 (2h) — Logs y crawl budget: 30 días de logs, filtro Googlebot, agrupación por patrones. Identificación de URLs improductivas rastreadas masivamente.
5. Fase 5 (2h) — Indexación y canonicalización: revisión completa del informe de Cobertura en GSC (60-90 minutos por lote según volumen), cruce con sitemap y robots.txt.
6. Fase 6 (1h) — Schema manual: validación de coherencia entre JSON-LD y contenido visible en las 3-5 plantillas principales.
7. Fase 7 (2h) — Variantes de dominio: pruebas manuales de las 8 combinaciones HTTPS/WWW/trailing slash. Subdominios técnicos. CDN.
8. Fase 8 (1-2h) — Core Web Vitals: cruce PageSpeed + CrUX + GSC Web Vitals. Identificación de discrepancias lab/campo.
9. Fase 9 (1h) — Priorización: matriz impacto vs esfuerzo. Reporting.

No hace falta que seas un ingeniero para hacer esto. Hace falta paciencia, curiosidad y no fiarte de que la herramienta lo ha visto todo. Si el proceso te supera o prefieres contrastar tu diagnóstico con alguien que ya ha pasado cuarenta webs por este mismo filtro, ofrecemos los servicios de auditoría SEO técnica sobre estos 15 puntos con el workflow exacto que acabo de describir, aplicado proyecto a proyecto.

Preguntas frecuentes

¿Qué se revisa en una auditoría SEO técnica?

Una auditoría SEO técnica revisa cómo Googlebot rastrea, renderiza e indexa tu web, detectando problemas en capas invisibles a herramientas automáticas: renderizado JavaScript, coherencia de canónicas entre HTML/HTTP/sitemap, presupuesto de rastreo, arquitectura de enlazado interno real, datos estructurados, Core Web Vitals en campo, hreflang, paginación e indexación cruzada entre variantes de dominio.

¿Cuáles son los errores SEO más graves?

Los más graves son los que afectan a la indexación o la distribución de señales: canonicalización rota entre capas, contenido crítico no renderizado para Googlebot, canibalización entre variantes HTTPS/WWW/trailing slash y crawl budget desperdiciado en URLs sin valor. Problemas típicos como alt text o meta descriptions duplicadas tienen impacto marginal comparado.

¿Cada cuánto conviene hacer una auditoría técnica completa?

Una revisión técnica completa, cada 12-18 meses en condiciones normales. Tras una migración, rediseño, cambio de CMS o caída sostenida de tráfico (3+ meses), inmediatamente. Entre revisiones, un chequeo ligero trimestral con herramientas automáticas es suficiente para cazar regresiones evidentes.

¿Qué errores técnicos no detectan las herramientas automáticas?

No detectan errores que requieren interpretación contextual: señales contradictorias entre HTML y HTTP headers, discrepancias entre HTML crudo y renderizado por JS, canonicalización cruzada entre variantes de protocolo, schema sintácticamente válido pero semánticamente incoherente con el contenido, crawl budget mal distribuido en logs y diferencias entre Core Web Vitals de laboratorio y de campo.

¿Cuánto tarda en notarse la corrección de un error SEO técnico?

Depende del tipo: correcciones de indexación (canonicals, noindex) se reflejan en 1-4 semanas tras el recrawl. Cambios en arquitectura de enlazado interno o crawl budget, 4-12 semanas. Mejoras en Core Web Vitals de campo, 28 días como mínimo (el informe CrUX tiene ese lag). Redirecciones 302/303/307 que se convierten a 301 correctamente pueden tardar hasta 6 meses en transferir toda la señal, ya que las temporales no acumulan autoridad como las permanentes.