El estado de las webs municipales de Madrid en 2026: 194 portadas medidas

Este informe nace de un trabajo comercial, y lo decimos al principio: antes de escribir a un ayuntamiento revisamos su web para no enviar un correo genérico. Al cabo de seis lotes teníamos 220 entidades revisadas con el mismo método, y nos pareció más útil publicarlo. Sin ranking ni nombres.

Lo que se midió y cómo

• Universo: 220 entidades: los 179 municipios de la Comunidad de Madrid, mancomunidades y empresas municipales con web propia, y 25 organismos públicos con sede en Madrid.
• Herramienta: Lighthouse 12 (el motor de PageSpeed Insights) en local, con la configuración de móvil por defecto: procesador ralentizado cuatro veces y red 4G lenta simulada. Es una medición de laboratorio, pensada para comparar y repetir.
• Página: solo la portada, cargada una vez el 3 de septiembre de 2026. Las webs que bloqueaban herramientas automáticas o no respondían quedaron fuera de la parte de Lighthouse (26 de 220).
• Revisión estática: cabeceras HTTP, gestor, enlaces legales, aviso de cookies, analítica y página de accesibilidad, con una segunda pasada en navegador real para leer fecha, situación de conformidad y norma citada. 190 webs.

Lo que no se midió: la sede electrónica (suele ser de otro proveedor), páginas interiores, PDF, formularios reales, ni la experiencia con lector de pantalla.

Accesibilidad: la mediana es 84, y el problema está en los detalles

Una nota de 84 suena bien, pero Lighthouse pondera y una portada puede sacar 84 con ochenta textos que no se leen. Importa más qué falla:

Enlaces sin nombre accesible (68 %): iconos de redes sociales, logotipos o flechas de un carrusel sin texto. Un lector de pantalla lee "enlace" y nada más. Botones y enlaces demasiado pequeños (42 %): menos de 24 píxeles, difíciles de pulsar con el dedo, también para quien ve perfectamente. Orden de encabezados roto (44 %): un H4 después de un H1, que desorienta a quien navega por títulos. Imágenes sin texto alternativo (21 % según Lighthouse; en la revisión estática, el 31 % tenía al menos una).

Velocidad en móvil: la mediana tarda 13,5 segundos en mostrar el contenido

La red simulada es lenta a propósito (1,6 Mbit por segundo con 150 ms de latencia), así que en una buena conexión los segundos reales son menos; la comparación es justa porque es la misma para todas. El patrón se repite: portadas con vídeo de fondo y una docena de scripts de terceros. Lo que más pesa suele ser lo que menos usa el vecino que entra a buscar el horario del padrón.

La página de accesibilidad: lo que exige la norma y lo que hay

El Real Decreto 1112/2018 pide una declaración con el modelo de la Decisión (UE) 2018/1523, enlazada desde todas las páginas con el texto "Accesibilidad" y revisada al menos una vez al año. Lo que encontramos en 190 webs:

Lo que más se repite, sin nombres: certificaciones AENOR de 2011 bajo la UNE 139803, sustituida hace años por la UNE-EN 301 549; declaraciones genéricas sin fecha ni contenido no accesible; una barra de accesibilidad de un proveedor presentada como si fuera la declaración; y páginas que "están trabajando en ello" desde 2020. Algunos ayuntamientos lo hacen bien, con declaración fechada en 2026 y contenido no accesible listado con motivo. Son pocos. Cómo hacerla, paso a paso, en la guía de la declaración de accesibilidad.

Seguridad y mantenimiento: lo que dicen las cabeceras

Exponer la versión de PHP no es grave por sí solo. Exponer PHP 5.6, sí: lleva sin parches desde 2018 y cualquier vulnerabilidad conocida desde entonces sigue abierta. Es el síntoma de que nadie actualiza ese servidor, y no cuadra con la obligación del Esquema Nacional de Seguridad, que alcanza también a los proveedores, de mantener el software con parches.

Legal y medición

Las siete webs con Google Analytics y sin aviso las contamos con cautela: el aviso puede existir y no haberlo reconocido la herramienta. Es lo que la Agencia de Protección de Datos sanciona en el sector privado y lo que en el público acaba en un requerimiento.

Qué se puede arreglar en un mes y qué no

Lo que arreglaríamos primero, por orden de coste y efecto:

1. Contraste y nombres de enlaces. Hoja de estilos y atributos en la plantilla. Dos o tres días en una web tipo. Resuelve los dos fallos más frecuentes.
2. Peso de la portada. Imágenes optimizadas, vídeo de fondo fuera o diferido, scripts de terceros revisados. De 4,4 MB a menos de 1,5 en la mayoría de casos. Una semana.
3. Declaración de accesibilidad. Auditoría de una muestra de páginas, contenido no accesible con motivo, declaración con el modelo oficial, enlace en el pie, formulario de comunicación y fecha de la próxima revisión. Dos o tres semanas.
4. Cabeceras y versiones. HSTS, ocultar versiones, actualizar PHP. Un día si el alojamiento lo permite; si no, es el momento de cambiarlo.
5. Cookies y analítica. Inventario de lo que carga, aviso conforme a la guía de la AEPD o analítica sin cookies. Dos días.

Lo que no se arregla en un mes: una web de 2012 sobre un gestor sin soporte. Ahí la respuesta es una web nueva, que en el sector público significa contrato menor por debajo de 15.000 €. Lo contamos en sector público, con los precios cerrados.

Repetir la medición en tu ayuntamiento

Cualquier técnico puede repetir la parte de Lighthouse en cinco minutos:

1. Abre la portada en Chrome, en una ventana de incógnito, y entra en Herramientas para desarrolladores, pestaña "Lighthouse".
2. Marca "Móvil" y las categorías Rendimiento y Accesibilidad. Pulsa "Analizar".
3. Al terminar, despliega cada fallo de accesibilidad: te dice qué elementos son y cómo corregirlos.
4. Repite en dos o tres páginas interiores (un trámite, una noticia, el formulario de contacto). Es donde están los fallos que la portada no enseña.

Si prefieres que lo hagamos nosotros con la web completa y los tres hallazgos redactados para el expediente, es gratis y sin compromiso: pide la revisión. Y si tu ayuntamiento ya ha corregido algo, dínoslo: la siguiente edición es en marzo de 2027.