Errores de SEO técnico: soft 404, noindex, canonical y redirecciones

Un error 404 disfrazado de página correcta, una etiqueta noindex que sobrevivió a una migración o una regla de robots.txt demasiado amplia pueden dejar fuera de Google partes de una web sin que nadie lo note durante meses. Es la idea central de una guía que Saar Twito publicó el 3 de noviembre en freeCodeCamp, en la que repasa nueve fallos técnicos frecuentes con datos de auditorías hechas con su propia herramienta. Contrastada con la documentación de Google Search Central y con las directrices de Bing Webmaster Tools, la guía acierta en lo esencial, aunque deja fuera las Core Web Vitals y los sitemaps.

Las claves de los errores de SEO técnico más comunes en 20 segundos

Qué es: una guía de Saar Twito en freeCodeCamp sobre nueve errores técnicos.
Datos: el 18,9 % de 53 webs auditadas tenía enlaces internos rotos y el 61,8 %, títulos duplicados.
Matiz: la muestra procede de la herramienta del propio autor.
Qué hacer: revisar códigos de estado, noindex, canonical y enlaces con curl y Search Console.

Twito parte de algo que Google repite en su documentación: rastrear, indexar y mostrar una página son tres fases distintas y ninguna está garantizada. El autor lo resume así (traducción propia): «Google no garantiza ninguna de las tres fases, ni siquiera para una página que cumple todas sus reglas». También avisa de que corregir estos problemas no lleva por sí solo una web al primer puesto. Lo que hace es quitar obstáculos que le impiden competir.

Los porcentajes de la guía salen de auditorías realizadas el 25 de octubre con la herramienta del autor, que también desarrolla Greadme Page Audit. La muestra es pequeña (53 sitios y 457 páginas, con una mediana de diez páginas rastreadas por sitio), así que sirve para ilustrar con qué frecuencia aparecen estos fallos, no para medir el estado general de la web.

Códigos de estado y redirecciones: lo que el navegador no enseña

El primer fallo de la lista es el soft 404: una URL que ya no existe muestra un mensaje de «página no encontrada», pero el servidor responde con un código 200, es decir, como si todo estuviera bien. Google lo detecta cuando el contenido sugiere un error, una página vacía o un mensaje de error, y lo señala como soft 404 en Search Console. La corrección que propone Twito es devolver un 404 real o, si el contenido se ha movido, una redirección 301. La documentación de Google añade un detalle útil: sus rastreadores tratan igual todos los códigos 4xx salvo el 429, así que no hay diferencia práctica entre un 404 y un 410 en ese sentido. Bing pide lo mismo al retirar contenido y recomienda avisar del cambio mediante IndexNow.

Los enlaces internos rotos aparecieron en el 18,9 % de los sitios auditados. La solución es la obvia: actualizar el enlace hacia una página que exista o redirigir la URL antigua si el contenido cambió de sitio. Con las redirecciones en cadena (/oferta-antigua lleva a /oferta-2025 y esta a /oferta) el autor recuerda que los rastreadores de Google siguen hasta diez saltos por defecto, una cifra que coincide con la documentación oficial. Twito considera problemáticas las cadenas de cinco o más saltos, pero ese umbral es criterio suyo, no de Google. Lo sensato es que la URL antigua apunte directamente a la final.

Bing aporta dos matices que la guía no menciona. Recomienda la 301 para cambios permanentes y reserva la 302 para cambios muy cortos, de menos de dos días. Y cuando una URL se traslada, pide usar redirecciones en lugar de etiquetas canonical. Para comprobar todo esto basta con la terminal:

curl -sI https://ejemplo.com/pagina-que-no-existe
curl -sIL https://ejemplo.com/oferta-antigua
curl -sL -o /dev/null -w "%{num_redirects}" https://ejemplo.com/oferta-antigua

La primera orden muestra el código de estado real; la segunda, cada salto de la cadena, y la tercera, el número total de redirecciones.

robots.txt, noindex y canonical no sirven para lo mismo

Una línea como Disallow: /blog bloquea cualquier ruta que empiece por /blog, no solo la carpeta del blog. Twito propone acotar la regla, por ejemplo con Disallow: /blog-borradores/. Recuerda además que robots.txt controla el rastreo, no la indexación: una URL bloqueada puede seguir apareciendo en resultados, aunque sin descripción. Las directrices de Bing dicen exactamente lo mismo. En su muestra, el 7,9 % de los sitios tenía un robots.txt con errores o que no cargaba.

El noindex accidental puede llegar por dos vías: la etiqueta <meta name="robots" content="noindex"> o la cabecera HTTP X-Robots-Tag. Afectaba al 2,4 % de las páginas revisadas (11 de 457) y, de las doce bloqueadas, dos lo estaban solo por la cabecera, algo que no se ve mirando el código fuente. La documentación de Google advierte de que, para que noindex surta efecto, la página no puede estar bloqueada en robots.txt, porque el rastreador no llegaría a leer la directiva. Conviene revisar el CMS, el plugin de SEO y la configuración de cabeceras del alojamiento. En Bing, noindex excluye la URL también de Copilot y de los resultados de su API de grounding.

Con la etiqueta canonical, Twito subraya que no es obligatoria, y Google lo confirma: si no se indica ninguna, el buscador elige la versión que considere mejor. Aun así, el autor recomienda una canonical autorreferenciada en las páginas principales, práctica que Google también aconseja. El 27,1 % de las páginas auditadas no tenía canonical y el 64,2 % de los sitios tenía al menos una página sin ella. El error grave es otro: una canonical mal apuntada, como un artículo que señala a la portada. Google la trata como una señal fuerte, no como una orden, y la combina con redirecciones y sitemaps. En seocretos ya se repasaron las señales de canonicalización que usa Google.

JavaScript, metadatos y rendimiento: lo que conviene revisar después

Dos fallos de la guía tienen que ver con JavaScript. El 8,3 % de 278 auditorías de páginas sueltas usaba enlaces que no lo son, como un <span onclick>. Google solo rastrea con fiabilidad los elementos <a> con atributo href. Además, el 17,7 % de 277 páginas mostraba contenido que solo aparecía tras ejecutar scripts. Google renderiza JavaScript en una fase posterior y no todos los rastreadores lo ejecutan, así que Twito recomienda servir desde el servidor el contenido importante y comprobarlo con curl, con la herramienta de inspección de URLs de Search Console o con la prueba de resultados enriquecidos. Bing coincide y pide no esconder contenido crítico tras el renderizado en el cliente. El tamaño también cuenta: Google acota el rastreo efectivo a 2 MB por archivo.

Los metadatos dejaban las cifras más altas: el 13,2 % de los sitios tenía páginas sin título, el 61,8 % títulos duplicados y el 49,1 % páginas sin meta description. Aquí Bing va más lejos que Google en sus directrices, ya que afirma que los títulos y descripciones ausentes, duplicados o demasiado cortos pueden reducir la fiabilidad de la indexación y la posibilidad de aparecer como fuente en respuestas generadas.

La guía no entra en rendimiento y lo deja para otro artículo. La documentación de Google fija como objetivos de las Core Web Vitals un LCP (Largest Contentful Paint, el tiempo que tarda en pintarse el elemento principal) de hasta 2,5 segundos, un INP (Interaction to Next Paint, la rapidez con la que la página responde a una interacción) inferior a 200 milisegundos y un CLS (Cumulative Layout Shift, la estabilidad visual) por debajo de 0,1. El INP sustituyó a FID en marzo de 2024, así que cualquier auditoría que siga midiendo FID está desfasada. Google recomienda alcanzar buenos valores, pero los presenta como una parte de la experiencia de página, no como un factor que por sí solo decida posiciones.

Para una revisión mínima, el orden práctico sería este:

Pedir una URL inexistente y confirmar que devuelve 404.
Revisar el informe de indexación de Search Console y el de Bing Webmaster Tools en busca de soft 404 y páginas excluidas por noindex.
Leer el robots.txt regla a regla y comprobar qué rutas cubre cada una.
Rastrear el sitio para localizar enlaces rotos, cadenas de redirecciones y canonical que apuntan a otra página.
Comparar el HTML sin renderizar con lo que ve el usuario y medir INP con datos de campo.

Preguntas frecuentes

¿Bloquear una URL en robots.txt la saca de Google?

No. robots.txt controla el rastreo, no la indexación, y una URL bloqueada puede aparecer sin descripción. Para excluirla hay que usar noindex y permitir que se rastree.

¿Es obligatoria la etiqueta canonical?

No. Google elige una versión si no se indica ninguna, aunque recomienda una canonical autorreferenciada. Lo que sí perjudica es una canonical que apunta a una página equivocada.

¿Cuántas redirecciones sigue Googlebot?

Por defecto, hasta diez saltos según la documentación de Google. Aun así, lo recomendable es que la URL antigua lleve directamente a la final.

¿Qué valor de INP considera bueno Google?

Menos de 200 milisegundos. Google lo acompaña de un LCP de hasta 2,5 segundos y un CLS inferior a 0,1.

Fuentes: