Diagnóstico de Soft 404 en páginas de servicio

Páginas de servicio diagnosticadas como Soft 404 en Google Search Console

Consola de búsqueda de Google banderas Suave 404 en Informes de indexación, en las vistas Páginas o Cobertura de páginas.

En los sitios de servicios, las URL que enumera a menudo incluyen páginas de servicios eliminadas que aún se cargan, páginas con muy poco contenido, páginas que muestran una copia de marcador de posición como “no se encontró nada” y páginas de estilo de categoría o filtro que terminan vacías.

El trabajo comienza con una simple bifurcación: ¿debería existir esta URL como una página de destino real para los usuarios, o debería tratarse como eliminada?

Confirme esa intención para cada URL marcada antes de cambiar algo, porque la solución correcta depende de esa elección.

Una vez que sepa si la página debe vivir o morir, podrá comprender por qué Google calificó de error una página “200 OK”.

Por qué Google etiqueta una página “200 OK” como Soft 404

Un Soft 404 ocurre cuando su servidor dice que existe una página al devolver un código de estado 200 OK, pero Google lee la página y decide que parece faltante o inútil.

Google no necesita una respuesta del servidor “404 No encontrado” para llegar a esa conclusión.

Utiliza señales de página que a menudo aparecen en páginas de servicios rotas, como “no encontrado”, “servicio no disponible”, “no hay producto disponible” u otros mensajes que le dicen al visitante que no hay nada que hacer.

Las páginas delgadas también lo desencadenan, como una página de servicio creada a partir de una plantilla con un título y algunas líneas genéricas que coinciden con muchas otras páginas del sitio.

Otro factor desencadenante es la falta de coincidencia de intenciones: la página se carga, pero no responde lo que el buscador espera de esa consulta de servicio, por lo que Google trata la URL como un callejón sin salida.

Esas señales generalmente provienen de configuraciones técnicas específicas, por lo que el siguiente paso es rastrear el mecanismo que las produjo.

Mecanismos que crean Soft 404 en páginas de servicio (códigos de estado, redirecciones, renderizado)

Muchos Soft 404 provienen de errores en el código de estado.

Una común es una página personalizada “no encontrada” que devuelve 200 OK en lugar de 404 o 410, por lo que cada URL de servicio faltante parece una página normal para el rastreador.

Otro patrón es una página de error que se encuentra detrás de una redirección.

Por ejemplo, una URL de servicio antigua devuelve una redirección temporal y luego envía a Google a una página que parece un error y devuelve 200 OK.

Esa cadena le da a Google señales contradictorias, por lo que puede mantener la URL anterior mientras también indexa una página similar a un error y luego etiqueta el resultado como Soft 404.

Los errores de renderizado pueden crear los mismos síntomas incluso cuando el contenido del servicio existe.

Si la página depende del código del lado del cliente y ese código falla, Google puede ver una página en blanco o un mensaje de “error de aplicación” en el resultado representado.

He visto que esto sucede cuando una página se carga bien en un navegador, pero el pase de procesamiento de Google genera un error de JavaScript y nunca imprime el contenido principal en la página.

Otra causa aparece después de implementaciones en sitios con mucho JavaScript.

Google a menudo rastrea en dos pasos: primero busca el HTML y luego regresa para renderizarlo.

Si una renderización posterior intenta cargar archivos de script más antiguos que ya no existen, esos archivos faltantes interrumpen la página y Google puede posicionar la URL como Soft 404.

Estos mecanismos son importantes porque deciden qué tan urgente es la cuestión del rastreo y la visibilidad de la página de servicio.

Implicaciones para el SEO de páginas de servicios y el rastreo de sitios

Las páginas del servicio Soft 404 generalmente no permanecen indexadas, por lo que dejan de mostrarse en las búsquedas que desea que ganen.

Ellos también desperdician crawl budget porque Google sigue revisando URL rotas o de bajo valor en lugar de dedicar tiempo a tus páginas de servicios reales.

Cuando los usuarios llegan a estas páginas desde enlaces o marcadores, encuentran contenido escaso o mensajes parecidos a errores, lo que daña la confianza y aumenta las salidas.

Si el sitio produce muchas de estas URL, el sitio en general puede verse abarrotado de páginas de bajo valor, lo que hace que priorizar las correcciones sea importante.

Esa priorización comienza con una elección de acción clara para cada URL.

Elija 404/410, 301 o restauración de contenido; luego validar y monitorear

Comience por decidir qué representa la URL del servicio hoy.

Si la página de servicio se elimina, está fuera de alcance o no desea que se vuelva a indexar nunca más, devuelva el estado de error correcto.

Utilice 404 cuando la página no exista y utilice 410 cuando desaparece para siempre y desea una señal de eliminación más fuerte.

No mantenga una plantilla de “servicio no disponible” en una página 200 OK, porque eso mantiene vivo el patrón Soft 404.

Si la página de servicio tiene un reemplazo cercano, use una redirección 301 a la mejor coincidencia, como la página de servicio actualizada o una categoría de servicio principal que cubra la misma intención.

Haga esto solo cuando el destino ayude a un usuario que deseaba el servicio anterior.

Evite el redireccionamiento masivo de URL de servicios antiguos a la página de inicio, ya que Google a menudo lo trata como una señal Soft 404 y los usuarios lo encuentran confuso.

Si la página existe como una página de destino real, restáurela como tal.

Agregue contenido único que coincida con la intención del servicio y elimine frases que imiten una copia de error, como “no encontrado” o “sin resultados”, cuando la página debe posicionarse.

Confirme que Google puede representar el contenido principal sin fallas del lado del cliente verificando el HTML renderizado en Inspección de URL.

Si su sitio depende de paquetes de JavaScript que cambian durante la implementación, reduzca el riesgo de sesgo de versión manteniendo disponibles los activos críticos antiguos el tiempo suficiente para el procesamiento posterior de Google, o utilizando funciones de plataforma que eviten solicitudes de fragmentos rotos después de los lanzamientos.

Después de enviar los cambios, inspeccione algunas URL afectadas en Consola de búsqueda y solicitar validación.

Google puede tardar días o semanas en volver a comprobarlo y algunos sitios experimentan retrasos más prolongados según la velocidad de rastreo.

Ejecute un rastreo del sitio con una herramienta, como rana gritando, que informa códigos de estado y confirma que las páginas eliminadas devuelven 404 o 410, las redirecciones se resuelven en un solo paso y las páginas de servicio en vivo devuelven 200 con contenido significativo.

Mantenga una cadencia de auditoría regular de una vez al mes para que las nuevas páginas de servicio delgadas, los filtros vacíos y las plantillas rotas no recreen el mismo patrón Soft 404.

Preguntas frecuentes

¿Qué debo comprobar antes de reescribir una página de servicio Soft 404?

Comience con Search Console, el estado HTTP activo y la página representada. Si la página es una página de servicio real, confirme que tenga una copia única, una oferta clara, enlaces internos y suficientes detalles locales o específicos del servicio antes de asumir que la longitud del contenido es el único problema.

¿Cuándo se debe redirigir un Soft 404 en lugar de restaurarlo?

Rediríjala cuando la URL anterior tenga enlaces útiles o visibilidad de búsqueda y haya una página de reemplazo cercana. Si no hay un reemplazo relevante, un 404 o 410 es más limpio que obligar a los usuarios y a Google a ir a una página no relacionada.

¿Cuánto tiempo debo esperar después de arreglar un Soft 404?

Solicite la validación en Search Console después de la solución y luego observe los patrones de rastreo e indexación durante varias semanas. Las páginas de servicios importantes pueden recuperarse más rápido si están vinculadas internamente desde páginas sólidas de navegación, ubicación o centros de servicios.

¿Quién debería poseer las correcciones Soft 404 en un equipo de marketing?

El SEO debería diagnosticar el patrón, pero es posible que el desarrollo deba manejar códigos de estado, redireccionamientos, plantillas y renderizado. Los equipos de contenido deben ser dueños del contenido de la página cuando Google trata una página de servicio delgada como una página faltante.