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 publicar el conjunto que guardarlo. No hay ningún ranking con nombres y no lo va a haber. Hay cifras, gráficos, el método para repetirlas y lo que no sabemos.

Lo que se midió y cómo

• Universo: 220 entidades: los 179 municipios de la Comunidad de Madrid (el Ayuntamiento de Madrid, una vez), mancomunidades y empresas municipales con web propia, y 25 organismos públicos con sede en Madrid que compran servicios web en la Plataforma de Contratación.
• Herramienta: Lighthouse 12 (el mismo motor de PageSpeed Insights) ejecutado en local en Chrome sin cabeza, con la configuración por defecto de móvil: pantalla de móvil, procesador ralentizado cuatro veces y red 4G lenta simulada. Es una medición de laboratorio, no lo que ve cada vecino; sirve para comparar webs entre sí y para repetirla.
• Página: solo la portada de cada web, cargada una vez. 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 de contenidos, enlaces legales, aviso de cookies, analítica, y búsqueda de la página de accesibilidad en la ruta habitual, seguida de una revisión con navegador real para leer fecha, situación de conformidad y norma citada. 190 webs.
• Fecha: 3 de septiembre de 2026. Todo el proceso se puede repetir con Chrome desde cualquier ordenador; el bloque de preguntas al final explica cómo.

Lo que no se midió: la sede electrónica (suele ser de otro proveedor y tener plantilla propia), páginas interiores, PDF, formularios reales, ni la experiencia con lector de pantalla. Una nota de accesibilidad de Lighthouse cubre una parte de los criterios de la norma; el resto exige revisión manual.

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

Una nota de 84 suena bien. El problema es que Lighthouse pondera, y una portada puede sacar 84 con ochenta elementos de texto que no se leen bien. Por eso importa más qué falla que la nota:

Enlaces sin nombre accesible (68 %): iconos de redes sociales, logotipos, flechas de un carrusel, enlazados 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, y esto también le pasa a 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).

Siete webs sacan 100 en la portada. Lo decimos por si alguien piensa que 100 es un certificado: no lo es; la portada no enseña las páginas interiores.

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

Conviene poner estas cifras en contexto. La red simulada de Lighthouse es lenta a propósito (1,6 Mbit por segundo con 150 ms de latencia), así que los segundos reales en una buena conexión son menos. Pero la comparación es justa porque es la misma para todas, y el patrón es claro: portadas con vídeos de fondo, carruseles de fotos de 3 MB y una docena de scripts de terceros. Lo que más pesa en una web municipal 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 de accesibilidad con el modelo de la Decisión (UE) 2018/1523, enlazada desde todas las páginas con el texto "Accesibilidad", revisada al menos una vez al año, con el contenido no accesible y sus motivos, un mecanismo de comunicación y el procedimiento de reclamación. Lo que encontramos en 190 webs:

Lo que más se repite, sin nombres: páginas que citan una certificación AENOR de 2011 bajo la norma 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 anuncian que "estamos trabajando en ello" desde 2020. También hay ayuntamientos que lo hacen bien, con declaración fechada en 2026, contenido no accesible listado con motivo y formulario de comunicación. Son pocos, y se nota que alguien se ha sentado a hacerlo.

Cómo hacerla bien, paso a paso, en la guía de la declaración de accesibilidad.

Seguridad y mantenimiento: lo que dicen las cabeceras

Que una web diga públicamente qué versión de PHP usa no es un fallo grave por sí solo. Que diga que usa PHP 5.6, sí: lleva sin parches desde 2018 y cualquier vulnerabilidad conocida desde entonces sigue abierta. Y es el síntoma de otra cosa: nadie actualiza ese servidor desde hace años. El Esquema Nacional de Seguridad aplica también a los proveedores que alojan estas webs; un servidor con PHP 5.6 en 2026 no cuadra con la obligación del ENS de mantener el software con parches de seguridad.

Legal y medición

Siete webs municipales cargan Google Analytics sin que hayamos encontrado ningún aviso de cookies. Es un número pequeño y lo contamos con la cautela de que el aviso puede estar y no haberlo reconocido la herramienta. Aun así, es el tipo de cosa que la Agencia de Protección de Datos sanciona en el sector privado, y que en el público acaba en un requerimiento.

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

Con lo que hemos visto, esto es lo que arreglaríamos primero en la mayoría de las webs, 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 de trabajo en una web tipo. Resuelve los dos fallos más frecuentes.
2. Peso de la portada. Imágenes optimizadas y en formato moderno, 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, lista de 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 cambiar de alojamiento.
5. Cookies y analítica. Inventario real 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, y en el sector público eso significa contrato menor por debajo de 15.000 € o un procedimiento simplificado. Lo contamos en sector público, con los precios cerrados.

Repetir la medición en tu ayuntamiento

Cualquier técnico puede reproducir la parte de Lighthouse en cinco minutos y sin instalar nada:

1. Abre la portada en Chrome, en una ventana de incógnito (para que las extensiones no interfieran).
2. Menú, Más herramientas, Herramientas para desarrolladores, pestaña "Lighthouse".
3. Marca "Móvil" y las categorías Rendimiento y Accesibilidad. Pulsa "Analizar".
4. Al terminar, abre "Accesibilidad" y despliega cada fallo: te dice qué elementos son y cómo corregirlos.
5. Repite en dos o tres páginas interiores (un trámite, una noticia, el formulario de contacto). Es donde suelen estar 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 desde septiembre, dínoslo: la siguiente edición del informe es en marzo de 2027.