Cómo configurar las notificaciones push de Webpushr para WordPress

Webpushr es una plataforma de notificaciones push web que entrega notificaciones en tiempo real a usuarios suscritos directamente en el navegador, incluso cuando esos usuarios han abandonado completamente tu sitio. A diferencia del correo electrónico o los SMS, las notificaciones push web no requieren información de contacto personal — los suscriptores reciben notificaciones directamente a través del sistema de notificaciones nativo del navegador mediante el Web Push Protocol y la Push API.

Esta guía recorre el proceso de configuración completo: desde la creación de la cuenta y la configuración del plugin de WordPress hasta la segmentación avanzada, la automatización basada en disparadores y el análisis de suscriptores. También cubre casos técnicos especiales — conflictos de service workers, requisitos de HTTPS, brechas de compatibilidad con iOS y consideraciones de rendimiento — que la mayoría de los tutoriales omiten por completo.

Requisitos Previos Antes de Comenzar

Antes de tocar el panel de WordPress, verifica que tu entorno cumple los siguientes requisitos obligatorios:

• HTTPS es obligatorio. La Push API y los service workers están restringidos a orígenes seguros. Un sitio que funcione con HTTP simple no puede registrar un service worker y, por lo tanto, no puede entregar notificaciones push web. Si tu sitio aún no está protegido, necesitas un certificado SSL válido — AlexHost proporciona Certificados SSL que cubren este requisito.
• WordPress 5.0 o superior es recomendado para una compatibilidad completa con el editor de bloques Gutenberg y el meta box de Webpushr.
• PHP 7.4 o superior en el servidor para evitar advertencias de funciones obsoletas que pueden interrumpir silenciosamente la inicialización del plugin.
• Conocimiento de compatibilidad con navegadores: Chrome, Firefox y Edge en escritorio y Android admiten el Web Push Protocol. Safari en macOS añadió soporte en Safari 16 (macOS Ventura). iOS Safari añadió soporte limitado en iOS 16.4 solo para PWAs en pantalla de inicio — las notificaciones push web estándar basadas en navegador en iOS siguen siendo poco fiables al momento de redactar este artículo.
• Sin service workers en conflicto. Si ya ejecutas un plugin PWA u otro servicio de notificaciones push, sus service workers pueden entrar en conflicto con los de Webpushr. Audita tus service workers activos en chrome://serviceworker-internals/ antes de continuar.

Paso 1: Crear y Configurar tu Cuenta de Webpushr

Ve a webpushr.com y registra una nueva cuenta. Durante el proceso de incorporación, se te pedirá el dominio de tu sitio web. Introduce el dominio exacto tal como aparece en la barra de direcciones de tu navegador, incluyendo el prefijo www o su ausencia — este valor se utiliza para delimitar el alcance del service worker y las discrepancias causarán fallos en las suscripciones.

Tras el registro, Webpushr proporciona dos credenciales críticas:

• API Key — utilizada por el plugin de WordPress para autenticar las llamadas a la REST API al enviar notificaciones.
• Auth Token — utilizado para solicitudes API del lado del servidor si más adelante construyes integraciones personalizadas.

Localiza ambos valores en Account > API Keys en el panel de Webpushr y guárdalos de forma segura. La API Key no es un secreto en el sentido tradicional (está integrada en las solicitudes del lado del cliente), pero el Auth Token debe mantenerse privado.

Límites del Plan Gratuito vs. Planes de Pago de Webpushr

Para la mayoría de los sitios WordPress pequeños, el nivel gratuito es suficiente para validar el canal antes de comprometerse con un plan de pago.

Paso 2: Instalar el Plugin de WordPress de Webpushr

Inicia sesión en tu panel de administración de WordPress y sigue esta ruta:

1. Ve a Plugins > Añadir nuevo.
2. Busca Webpushr.
3. Localiza el plugin oficial publicado por Webpushr Inc. — verifica el nombre del editor para evitar instalar un plugin con un nombre similar.
4. Haz clic en Instalar ahora y luego en Activar.

Alternativamente, instala mediante WP-CLI si gestionas WordPress desde la línea de comandos:

wp plugin install webpushr-web-push-notifications --activate

Tras la activación, aparece un nuevo elemento de menú Webpushr en la navegación izquierda de WordPress.

Lo que el Plugin Hace Realmente a Nivel de Servidor

Entender la arquitectura del plugin te ayuda a solucionar problemas de forma inteligente. Al activarse, el plugin:

1. Registra una regla de reescritura para servir el archivo del service worker (webpushr-sw.js) desde la raíz del sitio. Esto es crítico — los service workers deben servirse desde el ámbito raíz para controlar todo el origen.
2. Inyecta un fragmento de JavaScript en cada página del front-end mediante wp_enqueue_scripts que carga el SDK de Webpushr y registra el service worker.
3. Se engancha a las acciones de WordPress publish_post y publish_page para activar notificaciones push automáticas cuando se publica contenido.

Si tu plugin de caché almacena en caché de forma agresiva el archivo del service worker, los suscriptores pueden recibir payloads push desactualizados o no registrarse en absoluto. Excluye webpushr-sw.js de tus reglas de caché.

Paso 3: Conectar el Plugin a tu Cuenta de Webpushr

Ve a Webpushr > Ajustes en tu panel de WordPress. Verás un campo etiquetado como API Key. Pega la API Key que obtuviste del panel de Webpushr en el Paso 1.

Haz clic en Guardar cambios. El plugin realizará una solicitud de validación a la API de Webpushr. Si la clave es válida, aparecerá una confirmación de éxito. Si ves un error:

• Confirma que no hay espacios en blanco al inicio o al final de la clave pegada.
• Verifica que tu servidor puede realizar solicitudes HTTPS salientes a api.webpushr.com. Algunas configuraciones de VPS reforzadas bloquean las conexiones salientes por defecto. En un servidor Linux, prueba con:

curl -I https://api.webpushr.com

Una respuesta 200 OK o 301 confirma la conectividad. Si la conexión se agota, comprueba tus reglas de firewall con iptables -L OUTPUT o la ACL de red de tu proveedor de alojamiento.

Si estás ejecutando WordPress en un entorno de Alojamiento VPS, tienes control total sobre las reglas del firewall y puedes incluir en la lista blanca el endpoint de la API de Webpushr directamente.

Paso 4: Configurar el Aviso de Suscripción

El aviso de suscripción es el diálogo de permisos del navegador que solicita a los usuarios que permitan las notificaciones. El diálogo de permisos nativo del navegador no puede personalizarse — es renderizado por el propio navegador. Sin embargo, Webpushr proporciona un aviso previo a la suscripción (una superposición personalizada que aparece antes del diálogo nativo) que puedes personalizar completamente.

Configura el aviso previo a la suscripción en el panel de Webpushr en Settings > Opt-in Prompt:

• Estilo del aviso: Elige entre un widget de campana, una barra superior, un cuadro deslizante o un modal personalizado.
• Texto del aviso: Escribe un texto que comunique claramente el valor de suscribirse. Los avisos vagos como «¿Permitir notificaciones?» tienen un rendimiento consistentemente inferior al de los avisos que especifican lo que recibirán los suscriptores, como «Recibe notificaciones al instante cuando publiquemos nuevos avisos de seguridad».
• Retraso del aviso: Establece un retraso (en segundos o páginas vistas) antes de mostrar el aviso. Mostrarlo inmediatamente al cargar la página produce tasas de suscripción más bajas que esperar hasta que el usuario haya interactuado con al menos un contenido.
• Intervalo de re-aviso: Define cuántos días deben pasar antes de mostrar el aviso de nuevo a un usuario que lo haya descartado. Los re-avisos agresivos dañan la experiencia del usuario y aumentan la tasa de rebote.

Tasas de Suscripción de Referencia por Tipo de Aviso

Los avisos contextuales — mostrados después de que un usuario completa una acción significativa como leer un artículo hasta el final — superan consistentemente a todos los demás enfoques.

Paso 5: Configurar los Ajustes de Entrega de Notificaciones

Push Automático al Publicar una Entrada

En Webpushr > Ajustes, el interruptor Auto-Push Notification controla si se envía automáticamente una notificación push cada vez que publicas una entrada. Cuando está activado, Webpushr extrae el título de la entrada, el extracto y la URL de la imagen destacada y construye el payload de la notificación automáticamente.

Caso especial: Si utilizas un flujo de trabajo de staging a producción donde las entradas se importan o su estado cambia de forma programática (por ejemplo, mediante WP-CLI o un script de migración), el hook publish_post se activará para cada entrada importada, lo que podría inundar a tus suscriptores con docenas de notificaciones en segundos. Desactiva el auto-push antes de ejecutar importaciones masivas:

wp option update webpushr_auto_push 0

Vuelve a activarlo una vez completada la importación.

Push Manual desde el Editor de Entradas

Para un control más preciso, desactiva el auto-push globalmente y utiliza el meta box de Webpushr por entrada en el editor de entradas. Este meta box aparece debajo del editor de contenido principal y expone los siguientes controles:

• Enviar notificación push: Una casilla que, cuando está marcada, pone en cola una notificación al publicar o actualizar.
• Título personalizado de la notificación: Reemplaza el título de la entrada con un titular más atractivo para la notificación.
• Mensaje personalizado de la notificación: Reemplaza el extracto generado automáticamente.
• URL personalizada de la notificación: Redirige a los suscriptores a una página de destino específica en lugar del permalink de la entrada — útil para campañas promocionales.
• Icono personalizado de la notificación: Reemplaza el icono predeterminado del sitio con una imagen específica de la campaña.

Anatomía del Payload de una Notificación

Un payload de notificación push web consta de:

• title — se muestra en negrita en la parte superior de la notificación.
• body — el texto descriptivo debajo del título.
• icon — una imagen cuadrada (192×192 px recomendado) que se muestra junto a la notificación.
• image — una imagen de banner grande que se muestra debajo del cuerpo en plataformas compatibles (Chrome en Android, Chrome en Windows).
• badge — un pequeño icono monocromo que se muestra en la barra de estado de Android.
• url — la URL de destino cuando el usuario hace clic en la notificación.
• actions — hasta dos botones de acción con etiquetas y URLs personalizadas (compatibles con Chrome y Edge).

Mantener el title por debajo de 50 caracteres y el body por debajo de 120 caracteres evita el truncamiento en la mayoría de las plataformas.

Paso 6: Probar las Notificaciones Push de Extremo a Extremo

Realizar pruebas en la misma sesión del navegador donde estás conectado a WordPress no te dará una imagen precisa de la experiencia del suscriptor. Utiliza un perfil de navegador separado o una ventana de incógnito:

1. Abre tu sitio web en una ventana privada/de incógnito.
2. El aviso previo a la suscripción debería aparecer después del retraso configurado.
3. Haz clic en el llamado a la acción del aviso y luego en Permitir en el diálogo de permisos nativo del navegador.
4. Vuelve a tu panel de WordPress y publica una entrada de prueba, o utiliza el botón Send Test Notification en el panel de Webpushr.
5. Verifica que la notificación aparece con el título, cuerpo e icono correctos, y que al hacer clic navega a la URL correcta.

Modos de fallo comunes durante las pruebas:

• La notificación no aparece: Comprueba que las notificaciones del navegador no estén bloqueadas a nivel del sistema operativo (Windows Focus Assist, macOS No molestar, canales de notificación de Android).
• El service worker no se registra: Abre DevTools > Application > Service Workers y confirma que webpushr-sw.js aparece como activo. Si aparece como «en espera», otro service worker está bloqueando la activación.
• El icono no carga: La URL del icono debe ser absoluta (comenzando con https://) y la imagen debe servirse con cabeceras CORS permisivas si está alojada en un CDN.

Paso 7: Funciones Avanzadas — Segmentación, Programación y Disparadores

Segmentación de Audiencia

El motor de segmentación de Webpushr te permite etiquetar suscriptores basándote en:

• Segmentos basados en URL: Etiqueta automáticamente a los suscriptores que visitan URLs o patrones de URL específicos (por ejemplo, todos los usuarios que visitan /category/security/ se etiquetan como security-readers).
• Atributos personalizados: Pasa pares clave-valor arbitrarios mediante el SDK de JavaScript para construir segmentos basados en propiedades del usuario que tu aplicación ya rastrea.
• Segmentos de participación: Webpushr rastrea automáticamente las marcas de tiempo de última visita, lo que te permite crear campañas de reactivación dirigidas a suscriptores que no han recibido una notificación en más de 30 días.

La segmentación requiere un plan de pago y se configura en el panel de Webpushr en Segments.

Notificaciones Programadas

La programación te permite redactar una notificación ahora y entregarla en una fecha y hora futuras, con soporte de zona horaria. Esto es especialmente valioso para:

• Promociones con límite de tiempo y una fecha límite fija.
• Contenido publicado fuera de las horas de mayor tráfico que deseas entregar durante ventanas de alta participación.
• Notificaciones de resumen recurrentes (por ejemplo, resúmenes semanales).

Notificaciones Personalizadas Basadas en Disparadores

Los disparadores personalizados activan notificaciones basadas en eventos de JavaScript en tu sitio. Por ejemplo, puedes activar una notificación 24 horas después de que un usuario abandone un carrito de compras, o cuando un usuario alcanza una profundidad de desplazamiento específica. Los disparadores se configuran mediante el SDK de JavaScript de Webpushr y requieren trabajo de desarrollo personalizado más allá de las capacidades predeterminadas del plugin de WordPress.

Pruebas A/B del Texto de las Notificaciones

En los planes de pago, Webpushr admite pruebas divididas de títulos y texto del cuerpo de las notificaciones entre segmentos de suscriptores. Realiza pruebas A/B para determinar qué mensajes generan tasas de clics más altas antes de lanzar una campaña completa.

Paso 8: Monitorear el Análisis de Suscriptores

El panel de Webpushr proporciona las siguientes métricas:

• Total de suscriptores: Recuentos de endpoints activos, dados de baja y caducados.
• Tasa de entrega: Porcentaje de notificaciones enviadas que fueron entregadas correctamente al servicio push del navegador (FCM para Chrome/Edge, Mozilla Autopush para Firefox).
• Tasa de clics (CTR): Porcentaje de notificaciones entregadas que resultaron en un clic.
• Crecimiento de suscriptores a lo largo del tiempo: Tendencias de adquisición de suscriptores diarias y semanales.

Nota técnica importante sobre «entregado» vs. «recibido»: Una notificación se marca como entregada cuando el servicio push del navegador (por ejemplo, FCM de Google) acepta el payload. Si el dispositivo del usuario está desconectado, FCM pone en cola la notificación y la entrega cuando el dispositivo se reconecta — pero solo dentro de la ventana TTL (Time to Live) que configures. El TTL predeterminado es de 28 días. Para notificaciones urgentes, establece un TTL más corto para evitar entregar contenido desactualizado.

Matriz de Compatibilidad de Plataformas y Navegadores

«Soporte completo» significa que el Web Push Protocol, los service workers y las acciones de notificación son todos compatibles. Los usuarios de iOS en sesiones de navegador estándar siguen estando fuera del alcance de las notificaciones push web, lo que representa una brecha de audiencia significativa para los sitios con gran tráfico móvil.

Consideraciones sobre la Infraestructura de Alojamiento

La entrega de notificaciones push web es gestionada en gran medida por servicios push de terceros (FCM, Mozilla Autopush), por lo que el rendimiento bruto de tu servidor no es un cuello de botella para la entrega. Sin embargo, tu entorno de alojamiento sí afecta a:

• Velocidad de servicio del service worker: El archivo webpushr-sw.js debe obtenerse rápidamente en cada carga de página para que los navegadores verifiquen que el service worker está actualizado. Un servidor lento aumenta el Time to First Byte (TTFB) para este archivo.
• Tiempo de respuesta de la API: Cuando se publica una nueva entrada, el plugin realiza una llamada API síncrona a Webpushr. En alojamiento compartido con límites restrictivos de conexiones salientes, esta llamada puede agotar el tiempo de espera y fallar silenciosamente.
• Fiabilidad de los webhooks: Si configuras webhooks de Webpushr para notificar a tu servidor sobre eventos de suscripción, tu servidor debe aceptar de forma fiable las solicitudes POST entrantes.

Ejecutar WordPress en un VPS con cPanel te da el control para ajustar los tiempos de espera de ejecución de PHP, configurar reglas de firewall salientes y monitorear la entrega del service worker sin las restricciones de los entornos compartidos. Para sitios de alto tráfico donde las campañas de notificaciones push generan picos significativos de tráfico concurrente, un Servidor Dedicado garantiza que tu origen pueda absorber la carga de clics resultante sin limitaciones. Para equipos que gestionan múltiples propiedades WordPress, el Alojamiento de Correo Electrónico combinado con Webpushr crea una estrategia de reactivación de dos canales — push para la inmediatez, correo electrónico para la profundidad.

Matriz de Decisión Técnica: Cuándo Usar Webpushr vs. Alternativas

El nivel gratuito de Webpushr es más limitado que el de OneSignal, pero su implementación de service worker es notablemente más limpia y menos propensa a conflictos con otros plugins de WordPress — una ventaja práctica en instalaciones de WordPress complejas.

Lista de Verificación Práctica Antes de Publicar

• HTTPS está activo y el certificado SSL es válido y no está autofirmado.
• El service worker webpushr-sw.js es accesible en https://yourdomain.com/webpushr-sw.js y devuelve un estado 200.
• El archivo del service worker está excluido de las reglas de caché de tu plugin de caché.
• El retraso del aviso de suscripción está configurado en al menos 5 segundos o una página vista.
• El auto-push está desactivado si ejecutas importaciones masivas programadas o migraciones de contenido.
• Se ha recibido una notificación de prueba de extremo a extremo en una sesión de navegador limpia.
• Las dimensiones del icono de notificación son 192×192 px y la URL es HTTPS absoluta.
• El TTL está configurado de forma apropiada para la urgencia temporal de tu contenido.
• La línea base de análisis está registrada antes de tu primera campaña para tener un punto de comparación significativo.
• La política de privacidad/GDPR está actualizada para revelar la recopilación de datos de notificaciones push.

Preguntas Frecuentes

¿Funciona Webpushr sin HTTPS?

No. La Web Push API y los service workers están restringidos a orígenes seguros por la especificación del navegador. Cualquier sitio que funcione con HTTP no puede registrar un service worker y, por lo tanto, no puede enviar ni recibir notificaciones push web. Un certificado SSL es un requisito técnico obligatorio, no una práctica recomendada opcional.

¿Por qué mis notificaciones push no se entregan a algunos suscriptores?

Las causas más comunes son: el dispositivo del suscriptor estaba desconectado más allá de la ventana TTL de la notificación; el usuario revocó los permisos de notificación a nivel del navegador o del sistema operativo; o el endpoint del servicio push del navegador (FCM, Mozilla Autopush) devolvió un registro caducado o no válido. El panel de Webpushr marca estos como entregas «fallidas» y elimina automáticamente los endpoints que devuelven una respuesta 410 Gone, que es el comportamiento correcto según la especificación del Web Push Protocol.

¿Puedo enviar notificaciones push a usuarios de iOS?

A partir de iOS 16.4, las notificaciones push web solo son compatibles con Progressive Web Apps (PWAs) que hayan sido añadidas a la pantalla de inicio. Los usuarios que naveguen por tu sitio en Safari o cualquier otro navegador de iOS sin añadirlo a su pantalla de inicio no recibirán notificaciones push web. Esta es una restricción a nivel de plataforma impuesta por Apple, no una limitación de Webpushr.

¿El service worker de Webpushr entrará en conflicto con mi PWA existente o mi plugin de caché?

Puede. Solo un service worker puede controlar un ámbito determinado a la vez. Si un plugin PWA (por ejemplo, Super PWA) u otro servicio push ya ha registrado un service worker en el ámbito raíz, el service worker de Webpushr quedará en cola en estado «en espera» y nunca se activará. La solución es utilizar un service worker que importe ambos scripts, o elegir un único proveedor de push y desactivar los demás. Comprueba chrome://serviceworker-internals/ para auditar todos los workers registrados en tu dominio.

¿Desactivar el plugin de Webpushr cancela la suscripción de mis suscriptores existentes?

No. Desactivar el plugin elimina el SDK de JavaScript de tu front-end, lo que impide nuevas suscripciones y detiene las notificaciones automáticas. Sin embargo, los registros de endpoints push existentes permanecen válidos en el navegador hasta que el usuario revoque explícitamente el permiso o el endpoint caduque. Si vuelves a activar el plugin con la misma API Key, esos suscriptores serán accesibles de nuevo de inmediato.