El asunto dice «New reason preventing your pages from being indexed: Not found (404)» (nueva razón que impide indexar sus páginas: no encontrada [404]), y llegó de Google. Puede que usted sea el dueño del sitio, o la persona en una pequeña agencia que lo cuida a él y a algunos otros. De cualquier forma, la pregunta es la misma: ¿está roto el sitio, está perdiendo clientes, y alguien tiene que dejar todo lo demás? Un correo de Google Search Console suele ser una indicación para revisar un informe, no una prueba de que su sitio fue penalizado. Algunos de estos correos sí necesitan acción el mismo día, y son fáciles de distinguir una vez que sabe qué buscar. Otros se resuelven solos mientras Google vuelve a rastrear su sitio, y unos cuantos señalan cosas que nadie de su lado puede arreglar. Saber cuál es cuál le puede ahorrar una llamada urgente a un desarrollador, o evitar que se quede sentado sobre el único correo que de verdad importa.
Puntos clave
Una acción manual (Manual Action) es cuando Google aplica una medida por incumplir sus políticas de spam. Los correos de indexación de páginas, Core Web Vitals, HTTPS y datos estructurados son avisos de informe con consecuencias menores y distintas.
Un problema de seguridad (Security Issue), una acción manual y un nuevo propietario que usted no reconoce necesitan acción hoy mismo, antes que cualquier otra cosa en su lista.
Google dice que un 404 correcto para una página que no debería existir debería desaparecer del informe después de un mes aproximadamente, y que una validación suele tardar hasta unas dos semanas.
¿Debería existir esta URL y aparecer en Google? Si la respuesta es no, y devuelve un 404 real o una redirección intencional, regístrelo y déjelo así.
Sepa en un minuto si su correo es serio
La Ayuda de Google Search Console dice que envía mensajes a los propietarios cuando ocurre un evento importante en su sitio. «Important» (importante) abarca un rango amplio. Incluye un sitio hackeado, y también incluye que Google detecte una nueva categoría de páginas que no está indexando, lo cual muchas veces es exactamente lo que usted quería.
La forma más rápida de juzgar un correo es por su tipo. Compare lo que llegó a su bandeja de entrada con una fila de abajo, y luego lea la sección para ese nivel de urgencia.
| Tipo de correo | Qué le está diciendo Google | Urgencia | Dónde mirar primero |
|---|---|---|---|
| Problemas de seguridad (Security issues) | Google detectó hackeo, malware, phishing, software no deseado o daño similar en el sitio | Actuar hoy | Informe de problemas de seguridad |
| Acción manual (Manual action) | El equipo de Google aplicó una medida por política de spam al sitio | Actuar hoy | Informe de acciones manuales |
| Nuevo propietario agregado (New owner added) | Cambió la propiedad del recurso | Actuar hoy si no reconoce al propietario | Configuración, luego Usuarios y permisos |
| Nueva razón que impide indexar sus páginas (New reason preventing your pages from being indexed) | Google clasificó algunas URL de muestra bajo una razón recién detectada para no indexarlas | Depende de la razón y de las páginas | Informe de indexación de páginas, detalle del problema |
| Problemas de HTTPS (HTTPS issues) | Páginas indexadas en HTTP sin una versión HTTPS funcional e indexable | Esta semana si es en todo el sitio | Informe de HTTPS |
| Se detectaron problemas de Core Web Vitals (Core Web Vitals issues detected) | Datos reales de visitantes de Chrome ubican a un grupo de URL en Deficiente o Necesita mejora | Prográmelo | Informe de Core Web Vitals |
| Problemas de datos estructurados o resultados enriquecidos (Structured data or rich result issues) | Google encontró elementos inválidos o advertencias en marcado como migas de pan o fichas de producto | Programe los errores, vigile las advertencias | El informe del resultado enriquecido correspondiente |
| Resumen de rendimiento (Performance summary) | Clics, impresiones, búsquedas y páginas principales durante un periodo | Léalo cuando tenga tiempo | Informe de Rendimiento |
Solo las dos primeras filas son hallazgos de cumplimiento o de seguridad. El propio resumen de informes de Google trata el resto como informes sobre cómo Búsqueda ve sus páginas. La palabra «error» o «issue» (problema) en un correo no significa, por sí sola, una penalización.
Proteja el sitio hoy si llega uno de estos tres correos
Tres tipos de correo se van a la cima de su día. Cada uno involucra al equipo de cumplimiento de Google, un riesgo de seguridad para sus visitantes, o a alguien nuevo con control sobre su propiedad de Search Console. Ninguno debería esperar a un espacio mensual de mantenimiento. Los pasos de abajo vienen de las propias páginas de ayuda de Google para cada informe.
Un problema de seguridad
Abra el informe de problemas de seguridad. Google dice que las páginas afectadas pueden mostrar una advertencia en los resultados de búsqueda o una pantalla de advertencia en el navegador, así que los visitantes pueden alejarse antes de llegar a usted. Guarde evidencia de lo que muestra el informe, elimine el código malicioso o los recursos dañinos de terceros, cierre la vía de entrada, cambie las contraseñas, y luego solicite una revisión. Los ejemplos que enumera Google pueden no ser completos, así que trátelos como un punto de partida y no como la lista completa. Si el sitio fue hackeado, nuestro artículo sobre qué hacer en las primeras 24 horas después de un hackeo explica ese día en orden.
Una acción manual
Abra el informe de acciones manuales. Este es el único correo que significa que una persona en Google aplicó una acción por política de spam. Lea qué patrón nombra Google, corrija cada instancia de ese patrón en todo el sitio, no solo los ejemplos, y luego solicite una reconsideración.
Un nuevo propietario que usted no reconoce
Vaya a Configuración y luego a Usuarios y permisos. La página de Google sobre administrar propietarios, usuarios y permisos cubre los detalles. Elimine cualquier propietario o usuario que usted no autorizó, elimine también su token de verificación de propiedad, y luego proteja la cuenta de Google detrás del recurso. Si el nuevo propietario es su agencia o su desarrollador web, confírmelo con ellos y siga adelante.
Corrija esto en días si las páginas importan
El siguiente nivel son problemas reales en páginas que atraen clientes. Actúe en cuestión de días si el informe muestra alguno de estos:
- Error 5xx de Google Search Console: Su servidor falló cuando Google pidió páginas importantes, y sigue pasando. Hable con su proveedor de hosting sobre la interrupción.
- Fallas de HTTPS o de certificado en todo el sitio: El informe de HTTPS muestra páginas indexadas sin una versión segura funcional.
- Un error de redirección en una página que debería funcionar: Una redirección hace un bucle, encadena demasiados pasos o apunta a algo roto.
- Un noindex accidental, un bloqueo en robots.txt o un canonical equivocado: Esto suele seguir a un rediseño, una actualización de un plugin o un cambio de configuración en el CMS.
La palabra clave en cada línea es «important» (importante). Un 5xx en una página que nadie visita merece una nota. Un 5xx en su página de contacto merece una llamada a su proveedor de hosting. El detalle razón por razón de cada uno de estos, incluido cómo distinguir una redirección inofensiva de una rota, está en nuestra guía sobre el informe de indexación de páginas y qué razones corregir.
Programe el trabajo de Core Web Vitals y datos estructurados en lugar de apresurarlo
Un correo de «Core Web Vitals issues detected» (se detectaron problemas de Core Web Vitals) se basa en lo que Google llama datos de uso en el mundo real, es decir, la velocidad y la estabilidad de la página medidas en los navegadores Chrome de visitantes reales. El informe agrupa URL similares, así que una sola plantilla lenta puede meter muchas páginas en el mismo grupo. Los grupos calificados como Deficiente merecen programarse como una tarea formal. Los grupos en Necesita mejora merecen vigilarse. Ninguno de los dos suele necesitar una corrección el mismo día.
Los correos de datos estructurados funcionan igual. Un error en el marcado de producto o de migas de pan puede impedir que una página califique para un resultado enriquecido, mientras la página se mantiene indexable en los resultados ordinarios. Las pautas de datos estructurados de Google son claras en que un marcado válido hace que una página sea elegible para un resultado enriquecido, pero no garantiza que aparezca. Así que, programe los errores en las páginas donde el resultado enriquecido le importa, y trate las advertencias como una nota para la siguiente ronda de trabajo en el sitio. El resumen del informe de resultados enriquecidos de Google también dice que los ejemplos son muestras, no una lista completa.
Espere las alertas que se resuelven cuando Google vuelve a rastrear
Algunas alertas se arreglan solas en cuanto Google visita sus páginas de nuevo. Lo difícil es saber cuánto esperar antes de preocuparse. Google da plazos aproximados para varias de ellas, y ninguno de estos es una promesa.
| Situación | Qué dice Google | Qué hace usted |
|---|---|---|
| Un 404 real para una página que eliminó o una URL que nunca existió | El informe debería dejar de mostrarlo después de un mes aproximadamente | Nada, siempre que el servidor devuelva un 404 verdadero |
| Corrigió un problema y presionó Validar corrección | La validación suele tardar hasta unas dos semanas, y puede tardar mucho más | Espere, y luego revise el resultado |
| Cambió páginas y quiere que Google lo vea | Volver a rastrear puede tardar una semana o más | Espere; la Inspección de URL puede revisar una página |
| Un recurso totalmente nuevo con pocos datos o ninguno | Es posible que Google no haya rastreado el sitio todavía | Dele tiempo antes de sacar conclusiones de los vacíos |
El punto del 404 importa más para ese correo de «Not found (404)» (no encontrada). La página de ayuda sobre 404 de Google dice: «404 errors won't impact your site's search performance» (los errores 404 no afectan el rendimiento de búsqueda de su sitio) cuando las URL no deberían existir, y que corregirlas no es necesario en ese caso. Google hizo el mismo señalamiento hace años en su artículo de Search Central Do 404s hurt my site? (¿Me perjudican los 404?), fechado el 2 de mayo de 2011. Un 404 para una página que debería existir, como una página de servicio que usted no quería eliminar, es otra historia, y pertenece al grupo de «corregir en días».
La validación tiene su propio ritmo. La página de detalles de validación de Google dice que corrija cada instancia antes de presionar Validar corrección. Si la validación falla, Google muestra una URL de ejemplo que sigue fallando; corrija esa página, revise la corrección en cada URL que siga marcada como Pendiente, y vuelva a empezar. Google también dice que «might not always make sense to fix and validate a specific issue» (podría no siempre tener sentido corregir y validar un problema específico), y pone como ejemplo las URL bloqueadas a propósito por robots.txt.
Deje de perseguir las alertas que nadie puede arreglar
Algunas alertas de 404 señalan URL que usted nunca creó. Otro sitio web puede enlazar a una página del suyo con un error de tipeo en la dirección, y Google sigue ese enlace. Los bots automatizados también pueden pedir rutas inventadas en un sitio público. Usted no puede corregir el enlace de alguien más, y no puede impedir que los bots adivinen direcciones.
Lo que sí puede hacer es asegurarse de que su servidor responda a esas solicitudes con un 404 real, no con una página que dice «not found» (no encontrado) mientras le dice a Google que todo está bien. Ese segundo caso se llama un 404 suave, y la lista de Google sobre posibles problemas de indexación lo cubre.
Una corrección que hay que evitar: redirigir cada URL desconocida a su página de inicio. Parece ordenado, pero puede crear 404 suaves y enviar a los visitantes que siguieron un enlace roto a una página que no tiene nada que ver con lo que buscaban. Las páginas eliminadas con un reemplazo cercano merecen una redirección 301 uno a uno hacia ese reemplazo. Las páginas eliminadas sin reemplazo deberían devolver 404 o 410, y luego se dejan así.
Revise cualquier correo de Search Console en quince minutos
Cuando llega un correo nuevo, esta secuencia le dice a qué grupo pertenece. Usa solo Search Console y sus propios registros de cambios recientes en el sitio.
Una revisión de quince minutos después de cualquier correo de Search Console
- 1
Minutos 0 a 2, confirme y registre
Abra el mensaje desde el propio panel de mensajes de Search Console o desde el enlace del informe, no desde un enlace del que no esté seguro. Anote el recurso, el problema, la fecha de recepción y el conteo.
- 2
Minutos 2 a 7, revise las páginas afectadas
Abra el detalle del problema y vea las URL de ejemplo. Filtre por su sitemap enviado si el informe lo permite, y anote cualquier página que atraiga clientes.
- 3
Minutos 7 a 10, pruebe un ejemplo importante
Ejecute [Inspección de URL](https://support.google.com/webmasters/answer/12482179) en él. Compare la fecha de primera detección con cualquier rediseño reciente, un cambio de dominio o de HTTPS, una actualización de plugin o un problema de hosting.
- 4
Minutos 10 a 15, decida
Actúe por seguridad, acciones manuales, propietarios desconocidos y páginas importantes que estén caídas, bloqueadas o apuntando al canonical equivocado. Vigile los rastreos esperados y los grupos de velocidad o marcado que no sean críticos. Registre y deje así los 404 intencionales, las redirecciones, las etiquetas noindex y los canonical alternativos correctos.
Si solo recuerda una prueba de la lista, que sea esta: ¿debería existir esta URL y aparecer en Google, y un cambio reciente causó la alerta? Un «sí» en una página importante es una tarea de reparación. Un «no» en una página que devuelve la respuesta correcta es una nota en su registro.
Maneje las alertas de varios sitios de clientes sin despertar a un desarrollador
Para alguien en una agencia nueva con un puñado de recursos de clientes, el riesgo va en ambos sentidos. Puede escalar cada correo y quemar la confianza con su desarrollador, o puede pasar por alto el que sí importaba. Una rutina sencilla evita ambos. Se apoya en un registro compartido, el acceso correcto para cada persona y una primera respuesta estándar para el cliente.
Lleve un registro de entrada por cada recurso
Registre el recurso, el asunto del correo, la fecha de recepción, el tipo de problema, el conteo, algunas URL de ejemplo, qué tan importantes son esas páginas para el negocio, cualquier lanzamiento o migración reciente, quién es responsable del siguiente paso, la decisión y la próxima fecha de revisión. Después de unas semanas, el registro muestra qué alertas se repiten y qué clientes tienen problemas reales.
Configure el acceso como Google lo pensó
Cada cliente debería mantener al menos dos propietarios verificados propios. La página de permisos de Google describe los roles: una agencia suele necesitar acceso de usuario completo (Full user) para reportes y validación, no la propiedad, a menos que tenga que administrar quién más tiene acceso. Los usuarios restringidos pueden ver la mayoría de los datos pero no pueden validar correcciones. Cada persona también puede ajustar lo que recibe desde la página de preferencias de correo, para que las personas correctas vean los mensajes urgentes.
Filtre antes de escalar
Filtre el informe de indexación de páginas por las URL del sitemap enviado o por las secciones que importan antes de escalar nada. Las URL al azar fuera del sitemap suelen ser los enlaces con errores de tipeo y las solicitudes de bots descritas arriba.
Envíe al cliente un primer mensaje tranquilo
Una primera respuesta en este sentido mantiene informado al cliente sin alarmarlo: «This is a monitoring notice, not a penalty unless the report says Manual Action or Security Issue. We are checking whether the affected URLs are important and unintended» (este es un aviso de monitoreo, no una penalización, a menos que el informe diga Acción manual o Problema de seguridad. Estamos revisando si las URL afectadas son importantes y no intencionales). Luego dé seguimiento con la decisión de su registro.
Sepa cuándo tiene sentido pagar por ayuda
Muchos de estos correos no necesitan una corrección pagada. Un 404 correcto para una página que usted eliminó, una redirección esperada, un noindex intencional, un canonical alternativo correcto, una advertencia menor de datos estructurados o un cambio de informe que se resuelve solo necesitan una nota en su registro y una revisión posterior, no un proyecto.
La ayuda pagada tiene sentido cuando el informe señala páginas importantes, una causa que sigue reapareciendo, un riesgo de seguridad o de acceso, una acción manual, o una interrupción que no puede diagnosticar de forma segura usted mismo. El tamaño aproximado del trabajo varía. Revisar exclusiones esperadas puede tomar de minutos a una hora. Corregir un noindex o un canonical accidental suele tomar de una a cuatro horas. Los enlaces rotos y las páginas movidas pueden tomar de una a ocho horas según cuántas haya. Los problemas de servidor, certificado o DNS pueden tomar de horas a días, y un sitio hackeado o una acción manual pueden tomar días o más. Son cálculos aproximados de alcance, no precios.
Quien usted contrate debería primero decirle si hay un problema que vale la pena corregir, luego corregir la causa, revisarla, y explicarle qué necesita Google todavía tiempo para volver a rastrear. Desconfíe de cualquiera que le prometa que una corrección va a restaurar posiciones, forzar una indexación instantánea o detener cada alerta futura, porque Google tampoco promete esas cosas. Si prefiere que alguien vigile estos correos como parte del mantenimiento de rutina, para eso está el mantenimiento de sitios web.
¿Puede clasificar un correo de Search Console?
Elija una respuesta para empezar.
1. ¿Qué correo de Search Console significa que Google aplicó una penalización a su sitio?
2. Usted eliminó una página vieja a propósito y ahora devuelve un 404 real. ¿Qué debe hacer con la alerta?
3. Corrigió un problema y presionó Validar corrección. ¿Cuánto dice Google que suele tardar la validación?
Preguntas frecuentes sobre los correos de Google Search Console
¿Un correo de Google Search Console significa que mi sitio fue penalizado?
No, a menos que sea una Acción manual. Un Problema de seguridad es un hallazgo urgente de seguridad. Los correos de indexación de páginas, Core Web Vitals, HTTPS y datos estructurados son avisos de informe, y muchos describen condiciones que usted mismo configuró a propósito.
Me llegó «New reason preventing your pages from being indexed: Not found (404)» (nueva razón que impide indexar sus páginas: no encontrada). ¿Necesito corregirlo?
Solo si las páginas listadas deberían existir. Si son páginas que usted eliminó o URL que nunca existieron, y devuelven un 404 real, Google dice que los 404 como estos no perjudican el rendimiento de búsqueda, y el informe debería dejar de mostrarlas después de un mes aproximadamente.
¿Qué es un error de redirección de Google Search Console?
Por lo general significa que una redirección está rota, hace un bucle o no lleva a ningún lado útil. Una redirección normal e intencional no es un problema. Revise si la página que redirige es una que usan los clientes; si lo es, corrija la redirección en cuestión de días.
¿Cuánto tarda Validar corrección?
Google dice que la validación suele tardar hasta unas dos semanas y puede tardar mucho más. Corrija cada instancia antes de iniciarla. Si falla, corrija la URL de ejemplo que muestra Google, revise las URL pendientes y vuelva a empezar.
Alguien fue agregado como propietario en Search Console y no sé quién es. ¿Qué hago?
Vaya a Configuración, luego a Usuarios y permisos, elimine al propietario y su token de verificación, y proteja la cuenta de Google. Hágalo hoy.
¿Puedo desactivar los correos de Search Console?
La página de preferencias de correo de Google permite que cada usuario silencie tipos de mensaje específicos o desactive las notificaciones por correo. Mantenga activados los mensajes de seguridad, acción manual y propiedad para al menos una persona que los lea.
Para cerrar
Un correo de Google Search Console es una indicación para revisar, y la revisión suele tomar unos quince minutos. Los problemas de seguridad, las acciones manuales y los propietarios desconocidos van primero, el mismo día. Las interrupciones reales, las fallas de certificado y los bloqueos accidentales en páginas importantes vienen después, en cuestión de días. El trabajo de velocidad y marcado va en el calendario, y los 404 correctos, las redirecciones intencionales y el tráfico de bots van en el registro.
Una vez que clasifica las alertas así, la bandeja de entrada deja de fijar sus prioridades. Usted invierte tiempo en las páginas que atraen clientes, le da a Google las semanas que dice necesitar para volver a rastrear, y mantiene un registro que le muestra a los clientes exactamente qué se revisó y por qué.
Si prefiere entregarle esta clasificación a alguien más, podemos ayudar. En Web Leveling leemos estas alertas, le decimos cuáles importan, corregimos las causas de las que sí, y le explicamos qué necesita Google todavía tiempo para volver a rastrear, como parte de nuestro trabajo de posicionamiento en buscadores. Trabajamos con pequeñas y medianas empresas de todo el país y del extranjero. Cuéntenos qué correo de Search Console recibió y le diremos si necesita algo en absoluto.
Términos
Palabras de Search Console en este artículo
Toque un término para ver qué significa.
Google Search Console. La herramienta gratuita de Google que muestra a los propietarios de sitios cómo Google rastrea, indexa y presenta sus páginas en la búsqueda.
Acción manual (Manual action). Una medida por política de spam aplicada a un sitio por el equipo de Google, y el único correo de Search Console que es una penalización.
404. La respuesta que da un servidor cuando una página no existe. Un 404 real para una página que no debería existir es normal.
404 suave (Soft 404). Una página que se ve como un error para un visitante pero le dice a Google que todo está bien, lo cual confunde la indexación.
Canonical. La versión de una página que Google trata como la principal cuando existen varias versiones similares.
Validar corrección (Validate fix). Un botón de Search Console que le pide a Google que revise si un problema que usted corrigió quedó resuelto en las páginas afectadas.
Core Web Vitals. Las medidas de Google sobre velocidad de carga, capacidad de respuesta y estabilidad visual, tomadas de los navegadores Chrome de visitantes reales.
