Cierra solo lo que de verdad necesita parar
La opción más estable suele ser mantener la web accesible y limitar la función afectada. Una tienda puede desactivar temporalmente la compra y conservar productos, horarios y contacto. Un negocio de reservas puede bloquear nuevas citas sin retirar servicios, ubicación y teléfono. Así el cliente entiende qué ocurre y los buscadores siguen encontrando información válida.
Antes de activar un modo de mantenimiento general, identifica qué trabajo exige la pausa. Una actualización breve, una migración de base de datos y una reconstrucción que durará semanas no necesitan la misma respuesta. Cerrar todas las rutas por comodidad técnica puede dejar sin información a personas que solo querían llamar, consultar una dirección o comprobar un servicio.
Prepara siempre una vía alternativa. El mensaje temporal debe decir qué está disponible, cuándo se espera recuperar el servicio y cómo contactar. «Volvemos pronto» sin fecha ni canal traslada el problema al cliente y tampoco permite saber si la pantalla sigue allí por error.
- Función concreta que debe detenerse
- Información que puede seguir publicada
- Canal alternativo comprobado
- Responsable y hora prevista de reapertura
Usa la respuesta adecuada a la duración
Para una interrupción urgente de uno o dos días, el servidor puede mostrar una página informativa con código HTTP 503, que significa servicio no disponible de forma temporal. La cabecera Retry-After puede indicar cuándo conviene volver a intentarlo. El visitante ve una explicación y el buscador recibe una señal distinta de una página eliminada.
El 503 no es una solución para semanas. Si se mantiene demasiado tiempo, las URLs pueden acabar saliendo del índice y Google tampoco puede actualizar su contenido mientras recibe esa respuesta. Para una pausa más larga, suele ser mejor conservar una portada útil con respuesta 200, datos vigentes y enlaces a las secciones que continúan funcionando.
Una pantalla de mantenimiento con código 200 en todas las URLs también es problemática. Para el servidor todo funciona y un buscador puede interpretar ese contenido temporal como si hubiera sustituido cada servicio o artículo. La apariencia no revela el estado: hay que comprobar la respuesta HTTP real.
No uses noindex ni robots.txt como un interruptor
Una directiva noindex pide que una página no aparezca en los resultados. Puede ser deliberada en un borrador, un área privada o una demo, pero no es un modo de espera inocuo para una página comercial que debe volver. Si permanece en una ruta activa, esa ruta no podrá indexarse hasta que se retire y el buscador la procese otra vez.
Bloquear el rastreo en robots.txt no equivale a ocultar temporalmente una página. Además, si el robot no puede entrar, tampoco puede leer un noindex incluido dentro. La guía de Google recomienda mantener accesible robots.txt durante una pausa y no bloquear todo el sitio como sustituto de una respuesta temporal bien configurada.
Comprueba tanto el HTML como las cabeceras. El noindex puede estar en una etiqueta meta o en una cabecera X-Robots-Tag que no se ve en pantalla. Revisa también plantillas, plugins y reglas del alojamiento: retirar una casilla del gestor de contenidos no garantiza que otra capa haya dejado de enviar la directiva.
- Meta robots de las páginas públicas
- Cabecera X-Robots-Tag
- Reglas de robots.txt
- Configuración del alojamiento o del modo mantenimiento
Revisa las rutas, no solo la portada
Abre una muestra de servicios, artículos, contacto y páginas que reciben visitas desde campañas o enlaces antiguos. Un mantenimiento mal aplicado puede afectar a la portada y dejar otras rutas expuestas, o hacer lo contrario: recuperar la portada mientras páginas importantes siguen devolviendo 503 o noindex.
Comprueba el sitemap, las canónicas y las redirecciones. El sitemap debe seguir reflejando las URLs públicas que quieres conservar. Las canónicas no deben apuntar por accidente a la pantalla temporal. Contacto, teléfono y formularios tienen que conducir a destinos reales, no a una campaña antigua o a una página que se retirará al terminar la intervención.
Haz las pruebas sin sesión iniciada, desde móvil y desde ambos idiomas. Los administradores pueden saltarse el mantenimiento gracias a una cookie y ver una web que el público todavía no recibe. Guarda una lista corta de rutas críticas y su respuesta esperada para poder repetirla antes de reabrir.
Reabre de forma comprobable
Al terminar, retira la pantalla temporal y confirma que cada ruta crítica vuelve a responder 200 con su contenido real. Elimina noindex y X-Robots-Tag donde no correspondan, revisa robots.txt y abre el sitemap. Después prueba contacto, reservas, compras y cualquier función que se hubiera detenido.
En Search Console, la inspección de URL permite comparar lo que Google conoce con la versión publicada y ejecutar una prueba en directo. Si la página ya es indexable, puedes solicitar el rastreo de unas pocas URLs prioritarias. Para un conjunto amplio, actualiza el sitemap en vez de enviar peticiones una a una.
La reapertura no termina cuando el equipo ve la portada. Termina cuando una visita externa puede encontrar la información, completar la acción principal y el responsable ha confirmado que las señales temporales han desaparecido. Conserva esa prueba junto a la fecha y el cambio realizado; la próxima pausa empezará con un procedimiento, no con una improvisación.
- Contenido real con respuesta 200
- Directivas temporales retiradas
- Sitemap y rutas críticas accesibles
- Acción principal probada desde fuera
