por The Black | May 23, 2026 | HTML |
Pequeños cambios que ayudan a pasar tests de accesibilidad y mejoran la experiencia de usuario
Cuando haces una auditoría con herramientas como Lighthouse, WAVE o axe DevTools, hay dos errores que aparecen constantemente en muchas webs: botones vacíos y enlaces con iconos sin texto accesible.
Es algo muy habitual, sobre todo cuando trabajamos con menús móviles, iconos sociales o botones hechos únicamente con Bootstrap Icons, Font Awesome o SVG.
La buena noticia es que, en muchos casos, la solución es muy sencilla: añadir correctamente aria-label.
Comparto dos ejemplos reales que he aplicado recientemente y que ayudan a eliminar este tipo de avisos rápidamente.
Error “Empty Button” en botones con iconos
Este error suele aparecer mucho en botones de menú hamburguesa o elementos que visualmente muestran un icono, pero no tienen texto legible para lectores de pantalla.
Por ejemplo, este botón funciona perfectamente a nivel visual:
<button class="btn p-0 border-0 d-xl-none"
type="button"
data-bs-toggle="offcanvas"
data-bs-target="#offcanvasMenu">
<i class="bi bi-list fs-1"></i>
</button>
El problema es que un lector de pantalla no sabe qué hace ese botón. Para la herramienta de accesibilidad, está “vacío”.
La solución es añadir un aria-label describiendo la acción:
<button class="btn p-0 border-0 d-xl-none"
type="button"
data-bs-toggle="offcanvas"
data-bs-target="#offcanvasMenu"
aria-controls="offcanvasMenu"
aria-label="Abrir menú">
<i class="bi bi-list fs-1"></i>
</button>
Con algo tan simple como esto:
- Desaparece el error “Empty Button”.
- El botón pasa a ser accesible.
- Los lectores de pantalla entienden su función.
- No afecta al diseño visual.
Enlaces con iconos sociales sin texto accesible
Otro caso muy típico aparece con los botones de compartir en redes sociales.
Muchas veces dejamos únicamente el icono:
<a href="https://x.com/intent/tweet?text=<?php echo urlencode($titlecompartir); ?>&url=<?php echo urlencode($urlcompartir); ?>" target="_blank">
<i class="bi bi-twitter-x"></i>
</a>
Visualmente se entiende perfectamente que sirve para compartir en X, pero a nivel de accesibilidad el enlace no tiene descripción.
La solución vuelve a ser añadir un aria-label:
<a href="https://x.com/intent/tweet?text=<?php echo urlencode($titlecompartir); ?>&url=<?php echo urlencode($urlcompartir); ?>"
target="_blank"
rel="noopener noreferrer"
class="fs-3 mx-3 text-primary"
aria-label="Compartir en X"
title="Compartir en X">
<i class="bi bi-twitter-x"></i>
</a>
En este caso, el lector de pantalla ya puede interpretar correctamente la acción del enlace.
¿title y aria-label hacen lo mismo?
Es una duda bastante habitual.
El atributo title puede mostrar un tooltip visual al pasar el ratón, pero no siempre es suficiente para accesibilidad.
En cambio, aria-label está pensado específicamente para tecnologías asistivas y lectores de pantalla.
Por eso, cuando usamos iconos sin texto visible, es recomendable utilizar ambos:
title="Compartir en X"
aria-label="Compartir en X"
Cuándo merece la pena usar aria-label
Yo suelo utilizarlo sobre todo en estos casos:
- Botones que solo tienen iconos.
- Menús hamburguesa.
- Botones flotantes.
- Iconos de compartir en redes sociales.
- SVG sin texto visible.
- Elementos interactivos donde la función no queda clara para lectores de pantalla.
Importante: no hay que abusar de aria-label
Si un botón ya tiene texto visible, normalmente no hace falta añadirlo.
Por ejemplo:
<button>Enviar formulario</button>
En ese caso el contenido ya es accesible y entendible.
Conclusión
Muchas veces pensamos que mejorar la accesibilidad implica hacer grandes cambios, pero no siempre es así.
Detalles tan pequeños como añadir correctamente un aria-label pueden ayudarte a:
- Pasar auditorías de accesibilidad.
- Mejorar la experiencia de usuarios con lectores de pantalla.
- Optimizar la calidad técnica de la web.
- Evitar errores frecuentes en Lighthouse o WAVE.
Son cambios rápidos de aplicar y que aportan mucho más valor del que parece.
Ponte Manos a la Web y aplica ya estos cambios!
por The Black | Sep 28, 2025 | SEO, Wordpress |
Los Core Web Vitals son un conjunto de métricas que el Sr. Google utiliza para evaluar la experiencia de usuario en una web. Estas métricas afectan directamente al SEO y a la satisfacción de los visitantes.y del propio Sr Google (¿por qué negarlo?)
Índice
¿Qué son los Core Web Vitals?
- LCP (Largest Contentful Paint): mide el tiempo que tarda en mostrarse el contenido principal.
- FID (First Input Delay) → ahora INP (Interaction to Next Paint): mide la rapidez de respuesta a la primera interacción del usuario.
- CLS (Cumulative Layout Shift): mide la estabilidad visual (evitar que los elementos “salten” mientras carga la página).
Optimizar LCP
- Optimiza imágenes (
WebP, AVIF, tamaños adecuados).
- Usa
loading="lazy" en imágenes no críticas.
- Elimina o combina CSS que no uses para reducir peso (con cuidado que la puedes liar).
En WordPress: puedes quitar CSS innecesario en el functions.php de tu tema hijo con wp_dequeue_style():
// functions.php en tu tema hijo
function remove_unused_styles() {
if ( ! is_page('contacto') ) {
wp_dequeue_style('contact-form-7');
}
}
add_action('wp_enqueue_scripts', 'remove_unused_styles', 20);
—
Optimizar INP
- Reduce JavaScript pesado y elimina lo que no uses con
wp_dequeue_script(). (Si algo deja de funcionar vuelve a dejarlo como estaba)
- Mueve scripts al footer para que no bloqueen el renderizado inicial.
Ejemplo en functions.php de tu tema hijo:
// functions.php en tu tema hijo
function move_scripts_footer() {
if (is_admin()) return;
remove_action('wp_head', 'wp_print_scripts');
remove_action('wp_head', 'wp_print_head_scripts', 9);
add_action('wp_footer', 'wp_print_scripts', 5);
add_action('wp_footer', 'wp_print_head_scripts', 5);
}
add_action('wp_enqueue_scripts', 'move_scripts_footer', 20);
—
Optimizar CLS
- Reserva espacio en CSS para imágenes y banners (usa
width y height o aspect-ratio).
- Evita cargar fuentes de Google sin
display=swap.
En tu functions.php del tema hijo añade:
function cargar_fuentes_google() {
echo '<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>' . "\n";
wp_enqueue_style(
'google-fonts-roboto',
'https://fonts.googleapis.com/css2?family=Roboto&display=swap',
false
);
}
add_action('wp_head', 'cargar_fuentes_google', 5);
—
Cómo detectar scripts innecesarios
- Ver código fuente: busca todos los
<script src="...js">.
- DevTools > Network > JS: revisa el peso y el origen de cada archivo.
- Query Monitor plugin (solo para auditar): te lista qué plugin o tema añadió cada script y estilo.
Una vez identifiques un script que no necesitas en todas las páginas, puedes desactivarlo con algo como:
// functions.php en tu tema hijo
function optimizar_scripts() {
// Quitar Contact Form 7 excepto en su página
if ( ! is_page('contacto') ) {
wp_dequeue_script('contact-form-7');
wp_dequeue_style('contact-form-7');
}
}
add_action('wp_enqueue_scripts', 'optimizar_scripts', 20);
⚠️ Siempre revisa la web después de quitar un script. Si algo deja de funcionar (un slider, un menú, un formulario), vuelve a activarlo: significa que sí era necesario.
—
Conclusión
Para mejorar los Core Web Vitals, no basta con pegar código: hay que auditar qué se carga y eliminar lo innecesario de forma segura. Hazlo siempre en el functions.php de tu tema hijo, prueba los cambios en un entorno de staging si puedes, y mide después con PageSpeed Insights o Lighthouse para confirmar las mejoras. (si no las notas tampoco te extrañes, el Sr.Google si lo va a notar)
¿A qué esperas?. Ponte Manos a la web para optimizar tu site
por The Black | Sep 14, 2025 | Seguridad, SEO |
¿Tu web está preparada para frenar a los bots de IA?
Hoy en día, los bots de inteligencia artificial están rastreando miles de webs para llevarse contenido y usarlo en el entrenamiento de modelos. Eso significa que tu trabajo, tus textos o tus imágenes pueden acabar en una base de datos sin que te enteres. Para ayudar con este problema, ImmuniWeb ha sacado una herramienta online gratuita que te dice en segundos si tu web está protegida o no frente a estos bots.
¿Qué hace esta herramienta?
El test forma parte de la Community Edition de ImmuniWeb y básicamente revisa dos cosas:
- Si tienes un WAF (firewall de aplicaciones web) u otro sistema que bloquee accesos no deseados.
- Si tu archivo robots.txt está configurado para limitar el rastreo de bots (aunque ojo, muchos bots de IA ni lo respetan).
¿Por qué debería importarte?
Porque cada vez más empresas de IA están usando bots para rascar («robar») contenido sin pedir permiso. Y aunque pongas reglas en robots.txt, la mayoría de estos bots las ignoran. Con esta herramienta sabrás si tu web está en bragas o si al menos tienes algunas barreras que les compliquen el trabajo.
De hecho, el propio CEO de ImmuniWeb, Ilia Kolochenko, lo dijo claro: «El scraping para entrenar modelos de IA está creciendo y los creadores de contenido no reciben nada a cambio«.
Los bots más bloqueados
ImmuniWeb también ha publicado un estudio con datos sobre qué bots de IA son los más rechazados en las webs:
- GPTBot (OpenAI): bloqueado en el 61,7 % de los sitios que aplican restricciones.
- Claude (Anthropic): 59,3 %.
- Gemini (Google): 53,1 %.
- AmazonBot: 45,7 %.
Como ves, cada vez más webs están cerrando la puerta a estos bots.
Cómo probar tu web
- Entra en la herramienta online de ImmuniWeb.
- Escribe la dirección de tu sitio.
- En segundos tendrás un informe que te dice si tu web bloquea (o no) a los bots de IA.
Al finalizar el test, podrás ver los resultados por pantalla y descargarlos en formato PDF. También puedes registrarte de forma gratuita.
Conclusión
Si tienes una web y te preocupa que tu contenido acabe alimentando inteligencias artificiales sin que lo sepas, este test gratuito es un buen punto de partida. No te soluciona todo, pero al menos te da una idea clara de qué tan protegido estás y qué podrías mejorar.
No esperes a que otros se lleven tu trabajo, ponte manos a la web y refuerza la seguridad de tu sitio.
por The Black | Sep 4, 2025 | Google, SEO |
Desde 2024 Google exige la implementación de Consent Mode v2 para todos los sitios web que utilicen Google Analytics, Google Ads u otras de sus herramientas en la Unión Europea. Este cambio afecta tanto al cumplimiento legal de la normativa de privacidad como a la forma en la que se miden las conversiones y se optimizan las campañas.En este post vamos a ver qué es el Consent Mode v2, cómo configurarlo en Google Tag Manager (GTM) y Google Analytics 4 (GA4), y cuál es el papel de los CMP certificados (como Cookiebot o CookieYes) en todo el proceso.
¿Qué es el Consent Mode v2?
El Consent Mode es una API de Google que adapta la forma en la que se cargan las etiquetas en función de la decisión del usuario respecto al consentimiento de cookies. La versión v2 introduce dos nuevos parámetros obligatorios:
ad_user_data: control del uso de datos personales para publicidad.ad_personalization: control de la personalización de anuncios.
Estos parámetros se suman a los ya existentes (ad_storage y analytics_storage). Permiten que Google respete las preferencias del usuario en relación con la privacidad.
Requisitos previos
- Tener configurada una propiedad de GA4.
- Disponer de Google Tag Manager (recomendado para mayor flexibilidad).
- Usar un CMP certificado para mostrar el banner de cookies y registrar el consentimiento de forma legal.
Configuración básica en Google Tag Manager
- Crea variables de consentimiento para:
ad_storage, analytics_storage, ad_user_data y ad_personalization.
- En las etiquetas de GA4 y Google Ads, activa la opción de “Configuración de consentimiento”.
- Define un estado por defecto (normalmente “denied”) hasta que el usuario acepte.
Ejemplo de código con gtag.js
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
// Estado por defecto (todo denegado)
gtag('consent', 'default', {
'ad_storage': 'denied',
'analytics_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied'
});
gtag('js', new Date());
gtag('config', 'G-XXXXXXX');
</script>
Sustituye G-XXXXXXX por tu código de GTM
Consent Mode v2 y CMP certificados
Aquí es donde aparecen muchas dudas. Un CMP certificado (Consent Management Platform) es una herramienta que muestra el banner de cookies, guarda la preferencia del usuario y transmite esa decisión a Google de forma válida y conforme a la normativa.
Ejemplos de CMP certificados: Cookiebot, CookieYes, OneTrust, Complianz, Didomi.
¿Son complementarios al Consent Mode?
Sí. El CMP y el Consent Mode v2 trabajan juntos:
- El CMP recoge la decisión del usuario (aceptar, rechazar, personalizar).
- El Consent Mode v2 comunica esa decisión a Google (Analytics, Ads, Floodlight…).
En otras palabras: el CMP decide, el Consent Mode ejecuta.
Cómo se integran en la práctica
Si tu CMP es certificado, normalmente ya incluye la integración con Google. Por ejemplo, cuando un usuario acepta, el CMP ejecuta algo como:
gtag('consent', 'update', {
'ad_storage': 'granted',
'analytics_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted'
});
En Google Tag Manager, el CMP suele añadir automáticamente la configuración de consentimiento a todas las etiquetas relevantes.
Ejemplo práctico con Cookiebot
- Insertas el script de Cookiebot en tu
<head>.
- Cookiebot muestra el banner y guarda la preferencia del usuario.
- Cookiebot actualiza el estado del Consent Mode con la API de gtag.
- GA4 y Ads respetan esa decisión automáticamente.
Si no usas un CMP certificado, puedes intentar gestionar el consentimiento manualmente, pero no cumplirías los requisitos de Google ni de la legislación europea. Eso implica pérdida de datos en campañas y riesgo legal.
Validación de la implementación
- Usa la extensión Google Tag Assistant para comprobar el estado del consentimiento.
- Revisa en GA4 si se registran correctamente los eventos con y sin consentimiento.
- Confirma en la interfaz de Google Ads que se están recibiendo conversiones válidas.
Errores comunes
- No usar un CMP certificado → incumplimiento legal y pérdida de datos.
- Configurar el consentimiento después de cargar las etiquetas → se envían datos sin control.
- No añadir
ad_user_data y ad_personalization → Consent Mode v2 incompleto.
Conclusión
La implementación de Consent Mode v2 ya no es opcional: es un requisito para poder seguir midiendo de forma fiable en Google Ads y Analytics. El uso de un CMP certificado es fundamental, porque sin él el banner de cookies no tendría validez legal y la integración técnica no funcionaría correctamente.
En resumen: el CMP recoge el consentimiento, el Consent Mode lo transmite y Google lo aplica. Si configuras todo correctamente, protegerás tanto la privacidad de tus usuarios como la calidad de tus datos.
Prueba Cookieyes
Más información de Consent Mode V2 en nuestro artículo Consent Mode v2 de Google: Cambios clave para anunciantes en la UE en julio de 2025
por The Black | Sep 2, 2025 | Seguridad, Wordpress |
Aunque tengas los comentarios desactivados y no muestres ningún formulario de registro en tu web, WordPress mantiene activa por defecto la página estándar de registro en la URL /wp-login.php?action=register. Los bots la conocen bien y aprovechan para crear cuentas de suscriptor de forma automática.
La buena noticia es que existen varias formas de bloquear este tipo de registros no deseados. A continuación, repasamos las principales opciones, con sus pros y contras.
1. Desactivar el registro de usuarios desde ajustes
La forma más sencilla de cortar el problema de raíz es ir a Ajustes > Generales y desmarcar la opción “Cualquiera puede registrarse”.
- Ventajas: No requiere plugins ni código. Solución inmediata y nativa de WordPress.
- Inconvenientes: Si en algún momento necesitas que los usuarios puedan registrarse (por ejemplo, en una tienda online o comunidad), tendrás que volver a activarlo.
2. Bloquear la URL de registro
Aunque desactives el registro, algunos bots seguirán intentando acceder a la URL /wp-login.php?action=register. Para bloquearla puedes hacerlo de dos maneras:
Vía .htaccess (servidores Apache):
<Files "wp-login.php">
<If "%{QUERY_STRING} =~ /action=register/">
Require all denied
</If>
</Files>
Vía functions.php o un mu-plugin:
add_action('login_form_register', function() {
wp_die('Registro deshabilitado.');
});
- Ventajas: Bloqueo total de la URL de registro. Mayor seguridad incluso con registro activado.
- Inconvenientes: Requiere tocar código o archivos del servidor. Puede ser demasiado restrictivo si en el futuro quieres habilitar el registro.
3. Usar un plugin de seguridad o anti-spam
Existen plugins que bloquean registros falsos de forma automática:
- Stop Spammers
- Disable User Registration
- Wordfence o iThemes Security
- Ventajas: No necesitas tocar código. Suelen incluir más funciones de seguridad adicionales. Útiles si planeas permitir registro de usuarios reales.
- Inconvenientes: Añaden carga extra al sitio. Dependencia de un plugin externo para algo que se puede resolver de forma más ligera.
4. Añadir un CAPTCHA
Si realmente necesitas que los usuarios se registren, añadir un CAPTCHA o reCAPTCHA en el formulario es la mejor forma de evitar registros automáticos.
- Ventajas: Mantienes abierto el registro a personas reales. Dificulta casi por completo el registro de bots.
- Inconvenientes: Añade fricción al proceso de registro. Puede afectar a la experiencia del usuario.
Conclusión
La mejor opción depende del uso que tenga tu web:
- Si no necesitas ningún registro: desactiva la opción de “Cualquiera puede registrarse” y bloquea la URL de registro para mayor seguridad.
- Si necesitas registros reales: activa el registro pero añade un plugin anti-spam o un CAPTCHA para filtrar a los bots.
Con estas medidas, tu WordPress estará protegido contra registros falsos y evitarás llenar tu base de datos de cuentas basura.
