El equipo de Google Search Central publicó el recordatorio el 21 de octubre de 2026 en redes sociales, en el momento preciso en que miles de sitios estaban cayendo o aplicando parches de emergencia por dos vulnerabilidades críticas del núcleo de PHP. Las versiones corregidas (PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35) se publicaron hoy mismo a las 14:00 UTC, y los mantenedores advirtieron que todas las instalaciones que sirven peticiones web están en riesgo, con mayor exposición en servidores Apache con mod_php.
El impacto estimado abarca a una porción muy grande del internet. PHP sigue siendo la base de la mayoría de CMS populares, con WordPress a la cabeza, lo que explica por qué el equipo de Google decidió lanzar el recordatorio en un momento tan concreto.
En la práctica, muchos administradores de sistemas están tomando sitios offline durante minutos u horas para aplicar el parche y el aviso de Google busca evitar que ese downtime técnico se convierta en un daño SEO innecesario.
El post oficial lo resume en que servir un código 503 asegura que las URLs ya indexadas se preserven en Search mientras trabajas y en cuanto el servidor vuelve a responder con 200, las cosas regresan a la normalidad de forma natural ☕.
Qué dice la documentación oficial de Google sobre códigos HTTP
El recordatorio no introduce nada nuevo, se apoya en la documentación oficial sobre cómo los códigos de estado HTTP afectan a los rastreadores de Google. La lectura técnica es la que sigue, con tres puntos clave que importan a la hora de aplicar un parche de emergencia.
Primero, los errores del servidor en el rango 5xx y el código 429 (demasiadas peticiones) hacen que los rastreadores de Google se ralenticen de forma temporal con el rastreo del sitio. El contenido recibido durante esas respuestas es ignorado, no se procesa ni se indexa como si fuera la versión definitiva; es exactamente la señal que necesitas durante un mantenimiento planificado.
Segundo, el código 500 (error interno del servidor) tiene un golpe más duro; Google reduce la frecuencia de rastreo en proporción a la cantidad de URLs individuales que devuelven el error, y si el error persiste, la canalización de indexación acaba eliminando esas URLs del índice. Es decir, un 500 prolongado es peor que un 503 bien implementado.
Tercero, los códigos del rango 4xx tienen un comportamiento muy distinto y es donde la mayoría de equipos técnicos la caga sin saberlo. Un 404 (no encontrado) durante el mantenimiento le dice a Google que esa URL ha dejado de existir.
Si el 404 se mantiene suficiente tiempo, Google interpreta que la página ya no debe estar en el índice y la retira. Peor aún, servir una página de error con un código 200 (lo que se conoce como soft 404) es la peor opción posible, porque Google ni siquiera sabe que estás en mantenimiento y procesa el contenido vacío como si fuera el definitivo del sitio.
El fragmento técnico que resuelve el problema
La implementación práctica depende de tu stack, pero el principio es el mismo. Durante el downtime, el servidor web debe responder a cualquier petición con un código 503, idealmente con una cabecera Retry-After que indique a Google y a los usuarios aproximadamente cuándo volver.
En Apache con htaccess, la regla básica es esta.RewriteEngine OnRewriteCond %
REQUEST_URI} !^/mantenimiento.html$RewriteRule .* /mantenimiento.html [R=503,L]ErrorDocument 503 /mantenimiento.htmlHeader always set Retry-After "3600"
En Nginx, el bloque equivalente dentro de la configuración del server.
location / { return 503;}error_page 503 @mantenimiento;location @mantenimiento { add_header Retry-After "3600" always; root /var/www/html; rewrite ^(.*)$ /mantenimiento.html break;}
Si usas WordPress, los plugins de mantenimiento serios devuelven 503 por defecto.
Si no estás seguro de cuál usa tu sitio, verifica desde una terminal con curl -I https://tusitio.com y comprueba que la primera línea del output sea HTTP/2 503 o HTTP/1.1 503 Service Unavailable. Si ves un 200 o un 404, cambia de plugin antes de desplegar el parche.
El valor de Retry-After en segundos es orientativo pero útil. 3600 segundos equivalen a una hora. Para un parche de PHP concreto como el de hoy, una ventana entre 30 y 60 minutos es razonable. No pongas valores de días, porque Google puede interpretarlo como una señal de problema prolongado.
Qué pasa en Search Console mientras el sitio está en 503
Durante el downtime, si tienes abierta Search Console, no entres en pánico al ver movimientos. Es normal observar en las próximas horas o días una caída puntual del rastreo en el informe de Estadísticas de rastreo, un aumento transitorio en «Error del servidor (5xx)» en el informe de Páginas, y una ligera disminución del número de URLs rastreadas por día. Nada de esto es grave si la ventana es corta y el 503 está bien configurado.
Lo que sí deberías vigilar en las 48 horas posteriores al parche son dos cosas:
Primero, que el rastreo vuelva a su ritmo habitual, lo que suele ocurrir entre uno y tres días después de que el sitio vuelva a responder con 200. Según los datos de Google que compartió Gary Illyes en el Search Central Live Deep Dive de Barcelona, recuperar la capacidad de rastreo total puede tardar entre 4 horas y 1 o 2 semanas en el caso típico, dependiendo del tamaño del sitio y de cómo haya reaccionado Googlebot al downtime.
Segundo, que el informe de Páginas no muestre un pico sostenido en estados como “Error del servidor” o “Rastreada, actualmente no indexada” en los días posteriores al parche. Si lo ves, revisa que el servidor haya vuelto efectivamente al 200 en todas las URLs y que no hayas dejado tras el parche alguna configuración residual que esté devolviendo errores intermitentes.
Lo que no deberías hacer durante el parche
Hay tres errores operativos que vemos repetirse cada vez que hay una emergencia como la de hoy y te recomendamos que evites a toda costa hacerlo
1. No sirvas una página de mantenimiento con código 200. Es el peor escenario, porque Google procesa el contenido vacío como si fuera la nueva versión definitiva de todas las URLs del sitio. En pocas horas, puedes perder la indexación de miles de páginas sin que nadie se dé cuenta.
2. No apagues el servidor sin configurar el 503. Si Googlebot encuentra el servidor completamente caído durante demasiado tiempo, acabará reduciendo la capacidad de rastreo asignada a tu sitio, y recuperarla puede tardar semanas aunque hayas vuelto a estar online en minutos.
3. No cambies el robots.txt para «protegerte» durante el mantenimiento. Bloquear Googlebot con un robots.txt restrictivo no evita el daño, lo multiplica. El código correcto es 503, no un disallow improvisado.
Qué dice este aviso sobre la relación de Google con el ecosistema
Que el equipo de Google Search Central publique un recordatorio técnico tan concreto en el día exacto en que PHP libera un parche de emergencia dice bastante sobre cómo funciona la coordinación informal entre proveedores de infraestructura.
Aunque no es un comunicado oficial de política, es un gesto de proximidad al administrador de sistemas que esta tarde está parcheando a contrarreloj, con el sitio caído y los clientes llamando.
El aviso tiene también un efecto educativo que importa a medio plazo, porque muchos equipos de desarrollo aún no distinguen con precisión entre 503, 500 y 404 durante operaciones de mantenimiento y los costes SEO de esa confusión son reales.
Un parche de 30 minutos mal implementado puede desembocar en varias semanas de recuperación posterior en el informe de Páginas si Google deshace parcialmente la indexación.
Si tu equipo todavía no tiene un procedimiento documentado para mantenimientos y despliegues con impacto en respuesta HTTP, hoy es el día perfecto para redactarlo. La próxima emergencia llegará sin aviso previo y la diferencia entre un downtime limpio y una caída de posicionamiento posterior está en las tres líneas de configuración que vimos arriba 🎯.
