Qué es un soft 404 y por qué tu web puede tener uno sin que lo sepas

Un soft 404 es una página que no existe pero responde 200. Lo tuvimos en tresojotas.com hasta octubre de 2026, junto con un HTML casi vacío para los rastreadores. Qué es, cómo lo detectas y cómo lo arreglamos.

Un soft 404 es una página que no existe pero que responde como si existiera: el servidor devuelve un código 200 ('todo bien') y muestra un mensaje de error, una página vacía o, peor, la portada de la web. Para una persona es un detalle. Para Google es una contradicción: le dices que la página existe y a la vez que no hay nada que mostrar. Lo tuvimos en tresojotas.com hasta el 27 de octubre de 2026, y venía acompañado de dos fallos primos que casi nadie revisa: un HTML casi vacío para los rastreadores y varias secciones que le decían a Google que eran la portada. Te contamos cómo los encontramos, qué los causaba y cómo los arreglamos, para que puedas comprobar los tuyos en diez minutos.

Lo encontramos revisando nuestra web en vivo como lo haría un robot, no como lo hace un visitante. En el navegador todo estaba bien. Pero al pedir con curl una dirección inventada (tresojotas.com/esto-no-existe), el servidor contestaba 200 y entregaba la portada entera. La causa es la regla que lleva casi cualquier web hecha como aplicación de una sola página (React, Vue y parecidos): 'si el archivo no existe, sirve index.html y que la aplicación decida qué mostrar'. La aplicación mostraba su página de 'no encontrado', sí, pero el código de respuesta ya había salido: 200. Según la documentación de Google, cuando una respuesta 2xx trae una página vacía o un mensaje de error, Search Console la marca como soft 404; y las URL que responden 4xx se quitan del índice. Es decir: le estábamos pidiendo a Google que considerara para indexar cada dirección rota, cada enlace viejo de la época de WordPress y cada ruta que alguien escribiera mal.

El primo menos conocido estaba en las carpetas. Nuestras rutas /blog, /en, /studio, /en/blog y /en/work devolvían la portada en español con una etiqueta canonical apuntando a la raíz. Pasaba por una regla de Apache: como existe una carpeta blog/ con los artículos dentro, el servidor trataba /blog como carpeta, no encontraba un índice y caía en el mismo comodín de antes. En inglés era peor: la portada de /en le decía a Google 'mi dirección oficial es tresojotas.com', en español. Nada de esto se ve desde un navegador, porque la aplicación arranca, lee la URL y pinta la sección correcta. Solo se ve en el HTML que llega antes de que se ejecute el JavaScript, que es lo único que leen muchos rastreadores.

  1. Un 404 de verdad para lo que no existe La última regla del .htaccess cambió de 'todo lo demás va a index.html' a 'todo lo que no sea un archivo real responde 404'. La página de error la genera el build (dist/404.html) con el menú del sitio y una etiqueta noindex, así que una persona que llega por un enlace roto ve una página útil, y Google ve lo que corresponde: aquí no hay nada. Lo comprobamos cada semana con una dirección inventada: tiene que dar 404.
  2. Un HTML por ruta, con el contenido de verdad Ya prerenderizábamos (un archivo HTML por cada ruta, con su título y su descripción), pero el cuerpo llegaba casi vacío: unas 200 palabras por página, el cascarón de la aplicación. Ahora el script de prerender empaqueta con esbuild los mismos datos que usa la web (los casos y los artículos) y escribe el texto completo en cada HTML. Medido hoy sobre la web en vivo, sin ejecutar JavaScript: la ficha de Polish llega con cerca de 800 palabras, el artículo sobre migrar desde WordPress sin perder SEO con unas 1.200, y los listados de trabajos y blog con todos sus enlaces.
  3. Cada sección sirve su propio HTML Una regla nueva comprueba primero si existe blog.html antes de tratar /blog como carpeta. Así /blog, /en y /studio entregan su propia página, con su propio título y su canonical correcta. De paso, la versión en inglés dejó de declararse copia de la española.
  4. Comprobar como un robot, no como un visitante El navegador miente por omisión: ejecuta el JavaScript y lo arregla todo. Para ver lo que ve un rastreador hay que pedir la página sin ejecutarlo (con curl, o con 'ver código fuente' en el navegador) y buscar tu texto. Es uno de los chequeos de Radiografía, nuestra auditoría gratuita: 'contenido visible para robots'.

Por qué importa más ahora que hace dos años: los asistentes de IA. Googlebot ejecuta JavaScript desde hace años, así que una aplicación de una sola página termina indexada aunque tarde más. Los rastreadores de ChatGPT, Claude y Perplexity, no. Vercel y MERJ analizaron en diciembre de 2024 el tráfico de rastreadores de IA en su red: GPTBot hizo 569 millones de peticiones en un mes y Claude 370 millones; descargan los archivos JavaScript (ChatGPT en el 11,5% de sus peticiones, Claude en casi el 24%) pero no los ejecutan. Googlebot y el rastreador de Gemini sí renderizan. Para un asistente de IA, tu web es exactamente el HTML que llega en la primera petición. Si ese HTML trae 200 palabras de cascarón, eso es todo lo que sabrá de ti cuando alguien le pregunte.

¿Y los resultados? Pasaron pocas semanas, poco para hablar de posiciones, y no vamos a inventarlas. Lo que sí podemos decir es qué cambió el mismo día: una URL inventada responde 404, cada ruta entrega su propio HTML con su contenido completo, y la auditoría de Radiografía sobre nuestra portada da hoy 100 sobre 100. Lo que esperamos ver en Search Console en los próximos meses es menos páginas en 'soft 404' y en 'rastreada, actualmente sin indexar', y más rastreo gastado en lo que importa.

Tres comprobaciones para tu web, en el orden en que más duelen. Primero, pide una dirección inventada de tu dominio y mira el código de respuesta (en la terminal, curl -sI tudominio.com/no-existe, o cualquier comprobador de cabeceras online): tiene que ser 404 o 410, no 200. Segundo, abre el código fuente de tu página principal y de una ficha de producto o servicio, y busca una frase de tu texto: si no está, tus páginas dependen del JavaScript y los asistentes de IA no las leen. Tercero, en Search Console, informe de Indexación de páginas, mira si aparece 'soft 404' en cantidades que no esperabas. Si tu web es una aplicación de una sola página hecha hace un par de años, hay bastantes probabilidades de que falle al menos una de las tres. Nosotros fallábamos dos, y hacemos webs.

Resumido: un soft 404 es decirle a Google 'existe' cuando no existe, y se arregla en el servidor, con un 404 real y una página de error útil. El HTML vacío es su primo silencioso, y hoy pesa más por los asistentes de IA que por Google. Las dos cosas se comprueban en diez minutos sin tocar nada. Si prefieres que lo miremos nosotros, pasa tu dominio por Radiografía o cuéntanos qué web tienes.