Alertas de emergencia en sitios web de gobierno: banners, páginas y un plan para el peor día

Cómo debe comportarse el sitio web de una ciudad, un condado o un organismo en una emergencia: niveles de alerta, diseño del banner y de la página, quién puede publicar a las 3 a. m., mantener el sitio en línea con mucha carga, accesibilidad y traducción, y cómo encaja el sitio web junto a IPAWS, las alertas por SMS y las redes sociales.

En un día normal, el sitio web es un canal entre muchos. El día de una inundación, un incendio forestal, un aviso de hervir el agua o un derrame químico se convierte en el lugar al que apuntan todos los demás canales: la alerta por SMS dice "detalles en", el presentador de televisión lee la dirección, los vecinos comparten el enlace. El tráfico llega de golpe, quienes publican están agotados y trabajan desde el teléfono, y cada palabra se examina con lupa. Esta guía trata de preparar el sitio web para ese día mientras no pasa nada.

Dónde encaja el sitio web en el sistema de avisos

El sitio web rara vez es el primer aviso. En EE. UU., el Integrated Public Alert and Warning System (IPAWS) de la Federal Emergency Management Agency permite a las autoridades de alerta autorizadas enviar avisos autenticados mediante Wireless Emergency Alerts a los teléfonos móviles, el Emergency Alert System en radio y televisión, NOAA Weather Radio y fuentes de internet que otros sistemas pueden recoger. Muchos lugares también tienen servicios de alertas por SMS y correo a los que la gente se suscribe, y publican en redes sociales.

La función del sitio web es distinta. Es el lugar para el detalle que no cabe en 360 caracteres: qué calles, qué refugios, qué hacer con las mascotas, cuándo llega la próxima actualización y qué ha cambiado desde la anterior. Planifícalo como la referencia a la que enlaza cada alerta breve.

Canal	Ideal para	Papel del sitio web
Wireless Emergency Alerts / EAS	Avisos inmediatos y breves ante amenazas inminentes	El enlace o la dirección de la alerta debe llevar a una página de emergencia estable
SMS y correo por suscripción	Actualizaciones para quienes se suscribieron	Cada mensaje enlaza a la página; la página muestra los mismos datos
Redes sociales	Actualizaciones rápidas, alcance, control de rumores	Las publicaciones remiten a la página como registro oficial
Línea telefónica y centro de llamadas	Personas sin internet, preguntas complejas	Quienes atienden leen de la misma página para que las respuestas coincidan
Sitio web	Detalle completo, mapas, listas, traducciones, historial de actualizaciones	La fuente única con la que todo lo demás coincide

Niveles de alerta: decídelos ahora

Sin niveles acordados, cada evento se convierte en un debate sobre si "merece" el banner rojo. Acuerda tres niveles, con ejemplos, y quién puede activar cada uno.

Nivel	Ejemplos	Tratamiento en el sitio web	Quién puede publicar
1. Información	Corte de calle programado, cambios por festivos en la recogida de basura	Noticia; tarjeta en la página de inicio	Editores de departamento, revisión normal
2. Aviso	Aviso de hervir el agua en una zona, alerta por calor, vigilancia de tormenta	Banner en todo el sitio (se puede cerrar) que enlaza a una página del evento	Guardia de comunicación, sin revisión adicional
3. Emergencia	Evacuación, confinamiento, gran corte de servicio, amenaza inminente	Banner en todo el sitio que no se puede cerrar; la página de inicio se sustituye por la página de emergencia o empieza con ella; se pausa el contenido no esencial	Guardia de comunicación o gestión de emergencias, según decida el responsable del incidente

Diseñar el banner

Breve y concreto: "Orden de evacuación para las Zonas 3 y 4. Salga ahora. Detalles y refugios." No "Información importante sobre la situación actual".
Un solo enlace a la página del evento. No cinco.
En todas las páginas, incluidos los sitios de departamentos y programas. Si esos sitios usan otras plataformas, alguien tiene que actualizar cada uno; enuméralos en el plan.
Accesible: texto real (nunca una imagen), contraste suficiente, alcanzable pronto con el teclado y anunciado de forma sensata por los lectores de pantalla. No dependas solo del color para mostrar la gravedad; incluye el nivel en palabras. Para gobiernos estatales y locales de EE. UU., la norma del ADA Title II fija WCAG 2.1 AA para el contenido web, y el contenido de emergencia es contenido web.
Con hora: "Actualizado a las 6:40 a. m., martes". Nada destruye la confianza más rápido que un banner desactualizado.
Retirado a tiempo: nombra a quién lo quita y sustitúyelo durante un día por una nota de "este evento ha terminado".

Diseñar la página del evento

Crea una plantilla ahora, pruébala y mantenla sin publicar hasta que haga falta. La estructura que sirve para la mayoría de los eventos:

Qué está pasando en una o dos frases, con la hora de la última actualización.
Qué debe hacer ahora, en una lista numerada corta.
A quién afecta: zonas, con una descripción en texto además del mapa (los mapas por sí solos fallan a quienes usan lectores de pantalla y a quienes tienen conexiones lentas).
Dónde obtener ayuda: refugios, puntos de distribución, teléfonos, con sus horarios.
Qué está cerrado o ha cambiado: calles, escuelas, servicios.
Registro de actualizaciones, de la más reciente a la más antigua, con horas.
Otros idiomas: enlaces a las versiones traducidas, rotulados en el propio idioma.
Cuándo llega la próxima actualización.

Mantén una dirección permanente como /emergency que siempre muestre el evento actual o "No hay emergencias activas" junto con enlaces de preparación. Así puede imprimirse en imanes de nevera y en plantillas de alerta con años de antelación. Escribe en lenguaje claro; nuestra guía de lenguaje claro tiene reglas que importan aún más bajo presión.

Quién puede publicar a las 3 a. m.

La mayoría de los fallos web en emergencias tienen que ver con personas y permisos, no con tecnología.

Al menos tres personas formadas que puedan activar un banner de nivel 3 y publicar la página del evento, por turnos, con el acceso probado cada mes.
Acceso desde el teléfono probado: ¿pueden iniciar sesión y publicar desde un teléfono, con datos móviles, sin una VPN que esté caída?
Reglas de revisión flexibles por diseño: si tu proceso normal exige aprobación antes de publicar, deja escrito quién puede saltársela en los niveles 2 y 3, y registra cuando lo haga.
Textos preaprobados para los eventos habituales, para que la persona de guardia rellene huecos en lugar de escribir desde cero.
Una copia fuera de banda del plan y de los accesos, por si la red o el sistema de identidad forman parte del problema.

Mantener el sitio en línea

En una emergencia, el tráfico puede multiplicar varias veces un pico normal, todo a la vez y sobre todo desde teléfonos. Antes de que ocurra:

Pregunta a tu host o proveedor qué pasa con un tráfico varias veces superior al normal y si cambia la factura. Pídelo por escrito.
Haz ligera la página de emergencia: primero el texto, imágenes comprimidas, sin video de reproducción automática ni widgets pesados de terceros.
Usa una red de distribución de contenido (CDN) para servir las páginas desde caché.
Ten un plan B: una copia estática de la página de emergencia en otro host y una cuenta de estado en redes sociales que pueda llevar el enlace si el sitio principal falla.
Pausa los scripts no esenciales (widgets de chat, analítica pesada) en el nivel 3 si ralentizan las páginas.

El plan, en una página

Paso	Acción	Responsable
1	El responsable del incidente confirma el nivel	Gestión de emergencias
2	Publicar la página del evento desde la plantilla; activar el banner en el sitio principal	Guardia de comunicación
3	Activar el banner en cada sitio de departamento y programa del registro	Guardia de comunicación o equipo web
4	Enviar el enlace de la página a la autoridad de alertas, al centro de llamadas y al equipo de redes	Guardia de comunicación
5	Pedir la traducción de la sección principal	Responsable de acceso lingüístico
6	Actualizar la página según el calendario prometido; registrar cada actualización	Guardia de comunicación
7	Bajar de nivel o terminar: cambiar el banner, añadir la nota de "evento terminado", archivar la página	Responsable del incidente y comunicación
8	Revisión en dos semanas: qué fue lento, qué estuvo mal, qué cambiar	Responsable web

Practica

Haz un simulacro de mesa dos veces al año que incluya el sitio web: la persona de guardia publica la página del evento de prueba en una vista previa, activa un banner de prueba en una copia de pruebas y se mide el tiempo. El primer simulacro suele revelar una contraseña que nadie tiene, un sitio de departamento que nadie puede editar y un banner que no aparece en el móvil.

Cuando gestionas muchos sitios

El paso 3 del plan es el difícil para las organizaciones con muchos sitios: cada biblioteca, parque, departamento y programa necesita el banner o al menos un enlace. Dos cosas lo facilitan: un registro único de todos los sitios con una persona nombrada que pueda editar cada uno, y una plataforma en la que un administrador central pueda llegar a todos los sitios.

En We.Inc, una organización gestiona sus sitios bajo una sola marca y el equipo central ve todos los sitios en una lista. La aprobación antes de publicar es un interruptor por sitio, así que puedes decidir qué sitios la necesitan y dejar sin ella los de tus publicadores de emergencia. We.Inc no incluye un sistema de alertas ni una función de banner de emergencia lista para usar; los banners y las páginas de evento se crean como contenido normal del sitio.

Una lista de todos los sitios con búsqueda, etiquetas y columnas de estado — Todos los sitios de la marca en una lista con búsqueda: el registro del que depende el paso 3.

Ajustes de un sitio, con interruptores para publicación, dominio, código, blog, tienda, formularios, SEO y aprobación de publicación — La aprobación antes de publicar se define por sitio, así que los publicadores de emergencia no quedan retenidos en una cola.

Opciones de publicación, incluidas publicar en vista previa y conectar un dominio propio — Un paso de vista previa para ensayar una página de evento antes de necesitarla.

Un sitio web de ejemplo mostrado con ancho de teléfono, apilado en una sola columna — Los sitios se adaptan al ancho del teléfono, desde donde llega la mayor parte del tráfico en una emergencia. Se muestra un sitio de plantilla de ejemplo en vista previa en vivo.

Si quieres ver cómo funciona el control central de muchos sitios, agenda una demo.

Fuentes

Última revisión: 2026-10-25.

FEMA, Integrated Public Alert and Warning System (IPAWS).
ADA.gov, Fact Sheet: Title II web and mobile app rule (WCAG 2.1 AA).

Esta guía es información general, no asesoramiento legal ni de gestión de emergencias. Sigue el plan de operaciones de emergencia de tu jurisdicción.

Preguntas frecuentes

¿Qué debe decir un banner de emergencia en un sitio web de gobierno?

Una frase breve y concreta sobre qué está pasando y qué hacer, el nivel de alerta en palabras, un enlace a la página del evento y la hora de la última actualización. Usa texto real, no una imagen.

¿Qué relación tiene el sitio web con IPAWS y las Wireless Emergency Alerts?

IPAWS lleva avisos breves y autenticados a teléfonos, radio, televisión, NOAA Weather Radio y fuentes de internet. El sitio web es la referencia detallada a la que apuntan esas alertas y los demás canales.

¿Las actualizaciones de emergencia deberían requerir aprobación antes de publicarse?

Decídelo de antemano. Muchas organizaciones permiten que publicadores de guardia designados se salten la revisión normal en los niveles de aviso y emergencia, y registran cuando lo hacen.

¿Cómo mantenemos el sitio web en línea durante una emergencia?

Mantén ligera la página de emergencia, sírvela mediante una red de distribución de contenido, confirma con tu host qué pasa con mucho tráfico y ten una copia estática de respaldo en otro host.

¿We.Inc incluye un sistema de alertas de emergencia?

No. We.Inc permite a un equipo central ver y gestionar muchos sitios bajo una sola marca y definir la aprobación por sitio, pero los banners y las páginas de evento se crean como contenido normal del sitio y las alertas siguen en tus sistemas actuales.