Cómo Mostrar un Aviso en Todo el Sitio en un Sitio Web WordPress

Un aviso en todo el sitio en WordPress es un banner persistente o barra de notificación renderizada en cada página del sitio, utilizada para difundir anuncios urgentes, promociones, alertas de consentimiento de cookies o interrupciones del servicio a todos los visitantes simultáneamente. A diferencia del contenido específico de una página, un aviso en todo el sitio se inyecta a nivel de plantilla del tema — ya sea a través de un hook de plugin, un functions.php del tema, el motor de condiciones de visualización de un constructor de páginas, o una modificación directa de la plantilla PHP — garantizando que aparezca independientemente de la URL en la que aterrice el visitante.

Esta guía cubre cuatro métodos de nivel de producción, clasificados de menor a mayor complejidad de implementación, con casos límite técnicos, consideraciones de rendimiento y problemas de caché que la mayoría de los tutoriales omiten por completo.

Por qué los avisos en todo el sitio importan más allá del marketing

Antes de elegir un método de implementación, comprenda qué está ocurriendo realmente bajo el capó. Un aviso en todo el sitio se renderiza en cada respuesta del servidor o se inyecta mediante JavaScript después de la carga del DOM. Esta distinción tiene consecuencias reales:

• La renderización del lado del servidor (SSR) mediante hooks de plantilla PHP es rastreable por Googlebot y visible antes de que se ejecute JavaScript — fundamental para la accesibilidad y el SEO.
• Los avisos inyectados por JavaScript (comunes en algunos plugins) pueden no aparecer en el paso de renderización inicial de Google y pueden causar Cumulative Layout Shift (CLS), perjudicando directamente su puntuación de Core Web Vitals.
• El caché de página completa (WP Rocket, LiteSpeed Cache, caché FastCGI de Nginx) almacenará en caché el HTML del aviso. Si necesita mostrar un aviso solo a usuarios registrados o según la geolocalización, una página estática en caché ignorará completamente esa lógica a menos que configure exclusiones de caché o use caché de fragmentos.

El entorno de alojamiento es importante aquí. En un entorno de VPS Hosting donde controla la configuración de Nginx o Apache, puede implementar reglas de omisión de caché para cookies específicas establecidas por su plugin de avisos. En el alojamiento compartido, está limitado a la capa de caché que el proveedor expone.

Método 1: Usar un plugin dedicado de WordPress

Este es el camino más rápido hacia un aviso listo para producción y no requiere ningún código. La contrapartida es la sobrecarga del plugin y la dependencia de un ciclo de actualización de terceros.

Plugins recomendados

Paso 1: Instalar y activar

Inicie sesión en su panel de administración de WordPress y navegue a Plugins > Añadir nuevo. Busque WPFront Notification Bar, haga clic en Instalar ahora y luego en Activar.

Paso 2: Configurar la barra de notificación

Navegue a Ajustes > WPFront Notification Bar. Campos de configuración clave a tener en cuenta:

• Contenido del mensaje: Admite HTML, por lo que puede incrustar etiquetas de anclaje, etiquetas <strong> o estilos en línea directamente.
• Posición: Arriba o abajo. La colocación en la parte superior es más visible pero aumenta el riesgo de CLS si la barra se carga después del pintado inicial. La colocación en la parte inferior es más segura para Core Web Vitals.
• Comportamiento fijo: Activar el posicionamiento “fijo” mantiene la barra en pantalla durante el desplazamiento. Esto usa position: fixed en CSS, lo que elimina el elemento del flujo del documento y puede superponerse al encabezado de su tema en dispositivos móviles — pruebe en múltiples tamaños de ventana.
• Condiciones de visualización: Restrinja el aviso a tipos de publicaciones, páginas o roles de usuario específicos. Mostrar un aviso solo a usuarios no registrados, por ejemplo, requiere que el plugin establezca una verificación condicional contra is_user_logged_in().
• Cierre por cookie: Cuando un usuario cierra el aviso, se establece una cookie en el navegador. El aviso no volverá a aparecer hasta que esa cookie expire. Establezca un TTL apropiado — para una venta flash de 48 horas, una cookie de 2 días tiene sentido. Para un aviso GDPR permanente, establézcalo en 0 (nunca se cierra automáticamente).

Paso 3: Guardar y verificar

Haga clic en Guardar ajustes. Abra su sitio en una ventana de incógnito (para evitar que las cookies de administrador interfieran con la lógica de visualización) y verifique que la barra se renderiza en la página de inicio, una entrada del blog y una página estática.

Caso límite crítico: Si está ejecutando un plugin de caché de página completa, purgue el caché después de guardar. De lo contrario, los visitantes verán la versión antigua en caché de la página sin el aviso.

Método 2: Usar el personalizador de temas de WordPress

Muchos temas modernos — particularmente los construidos sobre frameworks como Genesis, Astra, GeneratePress u OceanWP — incluyen un componente nativo de Barra de anuncios o Barra superior. Este enfoque no añade ninguna sobrecarga de plugin y es la opción más limpia si su tema lo admite.

Paso 1: Acceder al personalizador de temas

Vaya a Apariencia > Personalizar. Busque secciones etiquetadas como Opciones de encabezado, Barra superior, Barra de anuncios o Barra de utilidades. La etiqueta exacta depende del tema.

Paso 2: Configurar la barra de anuncios

Dentro del panel del personalizador, normalmente encontrará:

• Un campo de texto o HTML para el contenido del aviso
• Selectores de color para el fondo y el texto
• Interruptor para activar/desactivar la barra globalmente
• Campo de enlace opcional para un botón CTA

El personalizador renderiza los cambios en un iframe de vista previa en vivo. Úselo para comprobar cómo interactúa la barra con su menú de navegación en los puntos de interrupción de escritorio y móvil antes de publicar.

Paso 3: Publicar

Haga clic en Publicar. Los cambios se escriben en la opción de base de datos theme_mods para su tema activo. No se modifican archivos, lo que significa que la personalización sobrevive a las actualizaciones del tema (para temas hijo o temas que almacenan modificaciones en la base de datos, no en style.css).

Importante: Si actualiza su tema padre sin usar un tema hijo, y el tema almacena la lógica de la barra de anuncios en un archivo de plantilla en lugar de un hook de filtro, su configuración de aviso puede ser sobreescrita. Utilice siempre un tema hijo al modificar el comportamiento del tema.

Método 3: Añadir un aviso en todo el sitio con código personalizado

La implementación directa en PHP y CSS le da control total sobre la lógica de renderización, el estilo y el rendimiento. Este es el enfoque correcto cuando necesita lógica de visualización condicional que ningún plugin expone, o cuando desea minimizar las solicitudes HTTP y la ejecución de JavaScript.

Paso 1: Añadir el HTML mediante un hook del tema

En lugar de editar header.php directamente — lo que se rompe con las actualizaciones del tema — use el hook de acción wp_body_open o el hook wp_head dentro del functions.php de su tema hijo. Este es el enfoque idiomático de WordPress.

Añada lo siguiente al functions.php de su tema hijo:

function alexhost_sitewide_notice() {
    // Only display for non-logged-in users
    if ( is_user_logged_in() ) {
        return;
    }
    ?>
    <div class="sitewide-notice" role="alert" aria-live="polite">
        <p>Scheduled maintenance on Saturday 02:00–04:00 UTC.
           <a href="/maintenance-info/">Learn more</a>
        </p>
        <button class="sitewide-notice__close" aria-label="Dismiss notice">×</button>
    </div>
    <?php
}
add_action( 'wp_body_open', 'alexhost_sitewide_notice' );

¿Por qué wp_body_open en lugar de wp_head? El hook wp_head se activa dentro de <head>, que es el lugar incorrecto para HTML visible. wp_body_open se activa inmediatamente después de la etiqueta de apertura <body>, lo cual es semánticamente correcto y está soportado por todos los temas que llaman a wp_body_open() en sus plantillas. Si su tema no llama a esta función, recurra a enganchar en get_header con un búfer de salida, o edite header.php en un tema hijo.

Si necesita editar el archivo de plantilla directamente, abra el header.php de su tema hijo e inserte el marcado del aviso inmediatamente después de la etiqueta <body>:

<div class="sitewide-notice" role="alert" aria-live="polite">
    <p>This is an important announcement!
       <a href="https://example.com">Learn more here.</a>
    </p>
</div>

Paso 2: Añadir CSS mediante el personalizador o functions.php

Para fragmentos de CSS pequeños, use Apariencia > Personalizar > CSS adicional. Para algo más complejo, ponga en cola una hoja de estilos desde su tema hijo.

Pegue lo siguiente en CSS adicional:

.sitewide-notice {
    background-color: #1a73e8;
    color: #ffffff;
    text-align: center;
    padding: 12px 40px;
    position: sticky;
    top: 0;
    width: 100%;
    z-index: 9999;
    box-sizing: border-box;
    font-size: 0.95rem;
    line-height: 1.5;
}

.sitewide-notice a {
    color: #ffffff;
    text-decoration: underline;
    font-weight: 600;
}

.sitewide-notice a:hover {
    opacity: 0.85;
}

.sitewide-notice__close {
    position: absolute;
    right: 16px;
    top: 50%;
    transform: translateY(-50%);
    background: transparent;
    border: none;
    color: #ffffff;
    font-size: 1.4rem;
    cursor: pointer;
    line-height: 1;
}

@media (max-width: 768px) {
    .sitewide-notice {
        font-size: 0.85rem;
        padding: 10px 36px;
    }
}

position: sticky vs position: fixed: Usar sticky mantiene el aviso en el flujo del documento, evitando que se superponga a su navegación. fixed lo elimina del flujo, lo que puede hacer que el contenido se renderice debajo de la barra a menos que añada un padding-top correspondiente al elemento <body> o <main>. Para la mayoría de los temas, sticky es el valor predeterminado más seguro.

Paso 3: Añadir JavaScript para el cierre basado en cookies

Sin un mecanismo de cierre, el aviso reaparece en cada carga de página, lo que degrada la experiencia del usuario. Añada este script mediante Apariencia > Personalizar > CSS adicional (no ideal) o, mejor, póngalo en cola correctamente en functions.php:

function alexhost_notice_dismiss_script() {
    wp_enqueue_script(
        'notice-dismiss',
        get_stylesheet_directory_uri() . '/js/notice-dismiss.js',
        array(),
        '1.0.0',
        true // Load in footer
    );
}
add_action( 'wp_enqueue_scripts', 'alexhost_notice_dismiss_script' );

Cree /wp-content/themes/your-child-theme/js/notice-dismiss.js con:

(function () {
    var COOKIE_NAME = 'sitewide_notice_dismissed';
    var COOKIE_TTL_DAYS = 7;

    function getCookie(name) {
        var match = document.cookie.match(new RegExp('(^| )' + name + '=([^;]+)'));
        return match ? match[2] : null;
    }

    function setCookie(name, value, days) {
        var expires = new Date(Date.now() + days * 864e5).toUTCString();
        document.cookie = name + '=' + value + '; expires=' + expires + '; path=/; SameSite=Lax';
    }

    var notice = document.querySelector('.sitewide-notice');
    if (!notice) return;

    if (getCookie(COOKIE_NAME) === '1') {
        notice.style.display = 'none';
        return;
    }

    var closeBtn = notice.querySelector('.sitewide-notice__close');
    if (closeBtn) {
        closeBtn.addEventListener('click', function () {
            notice.style.display = 'none';
            setCookie(COOKIE_NAME, '1', COOKIE_TTL_DAYS);
        });
    }
}());

Este script es autónomo, no tiene dependencia de jQuery y se ejecuta después de la carga del DOM ya que está en cola en el pie de página.

Paso 4: Verificar en diferentes contextos

• Abra el sitio en una ventana de incógnito para confirmar que el aviso es visible.
• Haga clic en el botón de cierre y recargue — el aviso debe estar oculto.
• Borre la cookie manualmente mediante las DevTools del navegador (Aplicación > Cookies) y recargue — el aviso debe reaparecer.
• Pruebe en la ventana de visualización móvil (320px de ancho mínimo) para confirmar que el CSS responsivo funciona.

Método 4: Usar un constructor de páginas (Elementor, Bricks, Oxygen)

Los constructores de páginas con un módulo de Theme Builder le permiten diseñar un aviso visualmente y asignarlo a todas las páginas mediante condiciones de visualización. Esta es la mejor opción para equipos que gestionan el contenido visualmente y necesitan un diseño perfecto al píxel sin tocar el código.

Elementor Pro: Enfoque con Theme Builder

Paso 1: Navegue a Plantillas > Theme Builder > Encabezado (o cree una nueva plantilla de encabezado personalizado).

Paso 2: Añada una nueva Sección en la parte superior de la plantilla de encabezado. Dentro de ella, coloque un widget de Editor de texto o Encabezado con el contenido de su anuncio. Estilícelo usando el panel de Elementor — color de fondo, tipografía, relleno y widgets de botón están todos disponibles.

Paso 3: En Publicar > Condiciones de visualización, establezca la condición en Todo el sitio. Esto garantiza que la sección se renderice en cada página que use esta plantilla de encabezado.

Paso 4: Publique la plantilla. Elementor escribe la salida de la plantilla en sus propias tablas de base de datos y la renderiza mediante su motor de plantillas en cada carga de página.

Nota de rendimiento: El Theme Builder de Elementor Pro carga activos adicionales de CSS y JavaScript. En un sitio sensible al rendimiento, mida el impacto con Lighthouse antes y después. Si la sobrecarga es inaceptable, el método de código personalizado (Método 3) es más eficiente.

Enfoque con Bricks Builder

En Bricks > Plantillas, cree una nueva plantilla de Encabezado. Añada un contenedor en la parte superior del encabezado, diseñe su aviso y establezca las Condiciones de la plantilla para aplicarlas a todas las páginas. Bricks genera HTML limpio y mínimo en comparación con Elementor, lo que lo convierte en una mejor opción para construcciones centradas en el rendimiento.

Comparación de los cuatro métodos

Consideraciones de rendimiento y caché

Esta sección aborda el modo de fallo de producción más común: un aviso que funciona perfectamente en desarrollo pero se comporta de forma inconsistente en un sitio en vivo con caché.

El caché de página completa almacena la salida HTML completa de una página. Si su aviso se renderiza del lado del servidor y luego la página se almacena en caché, todos los visitantes — independientemente de si han cerrado el aviso — recibirán el mismo HTML en caché. El JavaScript de cierre basado en cookies seguirá ocultando el aviso del lado del cliente, pero el HTML siempre estará presente en el código fuente.

Si necesita que el servidor omita la renderización del aviso para los usuarios que lo han cerrado (por ejemplo, para reducir la carga útil HTML o evitar el destello del aviso al cargar), debe configurar su plugin de caché para omitir el almacenamiento en caché cuando la cookie de cierre esté presente.

En WP Rocket, añada el nombre de la cookie en Ajustes > Reglas avanzadas > No almacenar en caché las cookies:

sitewide_notice_dismissed

En LiteSpeed Cache, navegue a Caché > Exclusiones > No almacenar en caché las cookies y añada el mismo valor.

En un caché FastCGI de Nginx a nivel de servidor, añada una condición de omisión de caché a su configuración de Nginx:

map $http_cookie $skip_cache {
    default 0;
    "~*sitewide_notice_dismissed=1" 1;
}

fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Esto garantiza que los usuarios que han cerrado el aviso reciban una página generada dinámicamente sin el HTML del aviso, mientras que todos los demás visitantes reciben la versión en caché con el aviso intacto.

Si está ejecutando WordPress en un VPS con cPanel o un Servidor dedicado totalmente gestionado, tiene acceso directo a los archivos de configuración de Nginx o Apache para implementar estas reglas de omisión de caché a nivel de servidor — algo que no es posible en los planes de alojamiento compartido estándar.

Requisitos de accesibilidad

Un aviso en todo el sitio que no cumple los estándares de accesibilidad puede exponer su sitio a riesgos legales bajo los marcos de cumplimiento de WCAG 2.1 y ADA. Aplique estos requisitos independientemente del método de implementación que elija:

• Añada role="alert" y aria-live="polite" al contenedor del aviso. Esto hace que los lectores de pantalla anuncien el contenido del aviso cuando aparece.
• Asegúrese de que el contraste de color entre el texto del aviso y el fondo cumpla una relación mínima de 4,5:1 para texto normal (WCAG AA). Use una herramienta como el Comprobador de contraste de WebAIM para verificarlo.
• El botón de cierre debe ser enfocable mediante teclado y operable con las teclas Enter y Espacio. Un elemento nativo <button> gestiona esto automáticamente — no use un <div> o <span> como objetivo de clic.
• No dependa únicamente del color para transmitir la urgencia del aviso. Use texto explícito (p. ej., “Importante:” o “Aviso:”) como prefijo.

Implicaciones SEO de los avisos en todo el sitio

Un aviso fijo o adhesivo renderizado en el HTML de cada página es indexado por Googlebot como parte del contenido de la página. Tenga en cuenta estos puntos:

• Evite el texto del aviso saturado de palabras clave. Google puede interpretar el texto idéntico repetido en miles de páginas como contenido repetitivo de baja calidad.
• Use aria-hidden="true" en avisos puramente decorativos (p. ej., un banner de cookies que no tiene valor informativo) para evitar que el texto sea ponderado en los cálculos de SEO en la página.
• Impacto en el CLS: Un aviso que se carga después del pintado inicial y empuja el contenido hacia abajo generará una puntuación de CLS. Mitigue esto reservando espacio para el aviso en su CSS usando min-height en el body, o renderizando el aviso del lado del servidor para que esté presente en la carga útil HTML inicial.
• Datos estructurados: Si su aviso anuncia un evento o promoción, considere añadir el marcado de esquema Event o Offer a la página en lugar de depender únicamente del texto del banner para la visibilidad en búsquedas.

Matriz de decisión práctica

Use esta lista de verificación para seleccionar el método adecuado para su situación específica:

• Necesita un aviso en vivo en menos de 10 minutos sin código: Use un plugin (Método 1). Instale WPFront Notification Bar, configúrelo y purgue su caché.
• Su tema tiene una barra de anuncios integrada y no necesita lógica personalizada: Use el Personalizador de temas (Método 2). Sin sobrecarga, sobrevive a las actualizaciones de plugins.
• Necesita lógica de visualización condicional (rol de usuario, tipo de publicación, geo-IP, estado de cookie) o máximo rendimiento: Use PHP/CSS/JS personalizado (Método 3). Enganche en wp_body_open, ponga en cola los scripts correctamente, implemente el cierre basado en cookies.
• Su equipo no es técnico y gestiona el sitio visualmente: Use Elementor Pro Theme Builder o Bricks (Método 4). Establezca las condiciones de visualización en Todo el sitio.
• Está en un VPS en caché o entorno de servidor dedicado: Independientemente del método que elija, configure reglas de omisión de caché para su cookie de cierre. No hacerlo es la causa más común de tickets de soporte relacionados con avisos.
• Necesita que el aviso cumpla con WCAG 2.1: Use el Método 3 (código personalizado) o el Método 1 con un plugin que admita role="alert". Verifique las relaciones de contraste manualmente.

Para los equipos que gestionan WordPress en infraestructura que controlan — ya sea un plan de VPS Hosting o un Servidor dedicado — el enfoque de código personalizado combinado con reglas de omisión de caché a nivel de servidor ofrece el resultado más fiable y eficiente. Para sitios más pequeños en Alojamiento web compartido, un plugin bien configurado con soporte de purga de caché es la opción pragmática.

Si su sitio gestiona comunicaciones transaccionales junto con avisos en todo el sitio — como confirmaciones de pedidos o correos electrónicos promocionales — asegúrese de que su infraestructura de Alojamiento de correo electrónico esté configurada con los registros SPF, DKIM y DMARC adecuados para que los correos electrónicos activados por avisos no acaben en la carpeta de spam.

Preguntas frecuentes

P: ¿Un aviso en todo el sitio perjudicará mi SEO o la puntuación de Core Web Vitals?

R: Puede hacerlo si se implementa de forma descuidada. Un aviso inyectado por JavaScript que se carga después del pintado inicial causa Cumulative Layout Shift (CLS), que es una métrica de Core Web Vitals. Los avisos renderizados del lado del servidor evitan el CLS por completo. Mantenga el texto del aviso conciso y no repetitivo para evitar que Google lo trate como contenido repetitivo en todo su sitio.

P: ¿Cómo muestro un aviso en todo el sitio solo a usuarios no registrados?

R: En código PHP personalizado, envuelva la salida de su aviso en una verificación condicional: if ( ! is_user_logged_in() ) { ... }. En WPFront Notification Bar, use la condición de visualización “Rol de usuario”. En Elementor Pro, establezca una condición de visualización que excluya a los usuarios registrados. Purgue siempre su caché de páginas después de cambiar esta lógica.

P: Mi aviso desaparece después de una actualización del tema. ¿Qué lo está causando?

R: Probablemente está editando el header.php del tema padre directamente en lugar de usar un tema hijo o un hook functions.php. Mueva el código de su aviso al functions.php de un tema hijo usando el hook de acción wp_body_open. Las actualizaciones del tema nunca sobreescribirán functions.php en un tema hijo.

P: ¿Puedo programar un aviso en todo el sitio para que aparezca y desaparezca automáticamente?

R: Las versiones gratuitas de la mayoría de los plugins de avisos no admiten programación. WPFront Notification Bar Pro y WP Notification Bars Pro ofrecen programación por rango de fechas. En código personalizado, puede implementar la programación con una simple comparación de fechas en PHP: compruebe current_time('timestamp') contra sus marcas de tiempo de inicio y fin antes de generar el HTML del aviso.

P: ¿Por qué mi aviso en todo el sitio no aparece en las páginas en caché?

R: El caché de página completa almacena la instantánea HTML de una página en el momento de la primera solicitud. Si el caché se construyó antes de que se añadiera su aviso, los visitantes reciben el HTML antiguo en caché. Purgue todo su caché de páginas inmediatamente después de publicar un nuevo aviso. Si usa una cookie de cierre, configure su plugin de caché o servidor para omitir el almacenamiento en caché de las solicitudes que lleven la cookie de cierre, de modo que los visitantes que regresan no vean un destello del aviso antes de que JavaScript lo oculte.