Rediseñar tu web sin perder tráfico ni posicionamiento

Guía completa: mide antes, mapea las URLs, redirige con 301 y compara a 7, 30 y 90 días. Lo que se pierde en un rediseño de web y cómo conservarlo.

Un rediseño no hunde el posicionamiento por cambiar el diseño: lo hunde por cambiar las URLs sin mapa de redirecciones, por perder contenido y por publicar sin línea base. Mide antes, redirige con 301 permanentes, conserva las páginas que ya funcionan y compara a 7, 30 y 90 días.

Hay dos rediseños distintos y casi nadie los separa. Uno cambia cómo se ve tu web. El otro cambia dónde vive cada página. El primero es un problema de diseño. El segundo es un problema de direcciones, y es el que te cuesta tráfico.

Escribimos esta guía porque llevamos años recogiendo el mismo caso: un negocio español rehace su web, la nueva es más limpia, más rápida, más ordenada, y a las tres semanas el teléfono deja de sonar. Nadie hizo nada mal en el diseño. Alguien cambió /servicios/reformas-integrales-madrid por /que-hacemos y no dejó rastro.

Aquí tienes el procedimiento completo: cuándo tiene sentido rediseñar, qué medir antes de tocar una línea, cómo se ejecuta por fases, qué hacer el día del lanzamiento y cómo leer los números después sin engañarte.

Lo que de verdad se pierde en un rediseño

Empecemos por desmontar la expresión. "Perder el SEO" no significa nada operativo. Lo que se pierde son cosas concretas, y cada una tiene un mecanismo distinto:

Direcciones. Cada URL indexada es un activo con historial: enlaces externos que apuntan a ella, señales acumuladas, posiciones ganadas. Si la URL desaparece y no dice a dónde ha ido, ese activo se evapora.

Contenido. El rediseño típico "simplifica". Doce páginas de servicio se convierten en una página de servicios con doce párrafos. Has borrado once páginas que respondían a once búsquedas distintas y ahora tienes una que responde mal a todas.

Enlaces internos. El menú antiguo enlazaba a la página de precios desde 40 sitios. El menú nuevo la esconde en el pie. La página sigue existiendo, pero ha dejado de recibir señal de tu propia web.

Datos. Cambias de plataforma, cambias de medición, y pierdes la referencia contra la que comparar. Sin línea base no hay diagnóstico: solo hay sensaciones.

Velocidad. Un rediseño con vídeo de fondo, tres tipografías cargadas por CDN y un carrusel puede ser más lento que la web de 2019 que sustituye.

Lo habitual en el sector: El sector vende el rediseño como un cambio de imagen y trata las URLs como un detalle técnico que se resuelve al final, la víspera del lanzamiento.

Nuestro criterio: Nosotros tratamos el mapa de URLs como el primer entregable del proyecto, antes que la retícula y antes que el color. El diseño se dibuja encima de una estructura ya decidida.

Cuándo rediseñar: umbrales, no corazonadas

"La web se nos ha quedado antigua" no es un criterio. Es una sensación, normalmente del fundador, normalmente después de ver la web de un competidor. Nosotros no aceptamos un proyecto de rediseño solo con eso.

Un rediseño se justifica cuando puedes nombrar el número que quieres mover. Estos son cinco de los siete disparadores que sí sostienen la decisión:

1. La conversión cae con el tráfico estable. Tienes las mismas visitas que hace un año y menos contactos. El problema está dentro de la página, no en Google.
2. El coste de mantener supera el coste de rehacer. Cada cambio pequeño requiere a un programador porque nadie documentó el sistema. Estás pagando una renta.
3. La estructura ya no describe el negocio. Vendes cuatro líneas de servicio y la web habla de dos. El menú miente.
4. El rendimiento de campo está en rojo de forma sostenida. No un día: tres meses seguidos por encima de los umbrales.
5. Una obligación legal te obliga a tocar la capa de interacción. Accesibilidad, consentimiento, facturación. Si vas a abrir el capó, ábrelo entero.

Si ninguno de esos cinco aplica, lo que necesitas no es un rediseño: es una intervención quirúrgica sobre tres plantillas. Te lo decimos con esas palabras aunque nos quite el proyecto. El desarrollo completo de estos umbrales, los siete, con la forma exacta de medir cada uno, está en Cuándo rediseñar tu web: 7 umbrales medibles.

La línea base: qué medir antes de tocar nada

Esta es la fase que casi ningún presupuesto español incluye y la que decide si podrás diagnosticar un problema o solo lamentarlo. Es trabajo de una semana, no de una tarde.

La regla es simple: si no lo has exportado antes del lanzamiento, no existe después. El informe de rendimiento de Search Console muestra por defecto los tres últimos meses, y Google Analytics 4 aplica un límite de conservación a los datos de nivel de usuario y de evento — las opciones estándar son 2 o 14 meses, ampliables solo en las propiedades 360. Los informes agregados no se ven afectados por ese ajuste, pero cualquier análisis fino sí.

• Rastreo completo de la web actual (todas las URLs con su código de estado, título, meta description, encabezados, canonical y enlaces entrantes internos)
• Exportación de Search Console: consultas, páginas, clics, impresiones y posición media de los últimos meses disponibles, en CSV
• Exportación de Analytics: sesiones, conversiones y páginas de entrada por mes, con la ventana más larga que te permita tu configuración de conservación
• Listado de páginas que reciben enlaces externos, ordenado por número de dominios de referencia
• Captura de los Core Web Vitals de campo actuales, por plantilla y por dispositivo
• Inventario de formularios, con destino de cada envío y dirección de correo asociada
• Inventario de integraciones que llaman a una URL tuya: pasarela de pago, herramienta de reservas, CRM, facturación, campañas activas
• Copia completa de la base de datos y de los archivos, con fecha y ubicación anotadas

Ese último punto merece una frase aparte. En una tienda española con Redsys, la pasarela devuelve al comprador a una URL concreta y notifica a otra. Si el rediseño cambia esas rutas y nadie actualiza la configuración en el TPV virtual, los cobros se autorizan y los pedidos no se registran. No es un problema de posicionamiento: es un problema de facturación, y aparece el primer día. Cómo se integran Redsys y Bizum, y qué rutas hay que conservar, lo explicamos en Redsys y Bizum en tu tienda online.

Los seis movimientos de un rediseño

Trabajamos igual en un rediseño que en una web nueva, con una diferencia: aquí hay un pasado que respetar. Estos son nuestros movimientos.

El movimiento 03 es el que separa un rediseño sano de uno caro. Se hace en una hoja de cálculo con dos columnas y tantas filas como URLs indexadas tengas. No se hace de memoria.

El mapa de redirecciones

Aquí se concentra casi todo el riesgo del proyecto y una fracción mínima del presupuesto. Es una desproporción que conviene corregir.

Qué código usar

Google es explícito: para un traslado, redirecciones permanentes del lado del servidor. En su documentación de traslados con cambio de URL recomienda usar redirecciones permanentes HTTP "si es posible, como 301 y 308".

La diferencia con las temporales no es cosmética. Con un 301 o un 308, según la propia documentación de Google, "el proceso de indexación usa la redirección como señal de que el destino de la redirección debe ser el canónico". Con un 302 o un 307, "el proceso de indexación no usa la redirección como esa señal", y la página antigua puede seguir indexada.

Cuánto tiempo se mantienen

No son un apaño de dos meses.

Nosotros las dejamos puestas indefinidamente y lo documentamos en el traspaso, porque el coste de mantener una tabla de redirecciones es cero y el coste de quitarla el día equivocado es un mes de tráfico.

Los cuatro errores del mapa

Cadenas. La URL A redirige a B, que redirige a C. Cada salto es una oportunidad de perder algo y una llamada más al servidor. El mapa se aplana: A va directamente a C.

Bucles. La versión sin www redirige a la versión con www que redirige a la versión sin www. Se detecta en dos minutos con una petición de cabecera. Se detecta si alguien la hace.

Redirección masiva a la portada. Es el atajo favorito del sector: todo lo que no encuentro, a la portada. Google trata muchas de esas redirecciones como páginas no encontradas, y el usuario que buscaba tu página de precios aterriza en una cabecera con un vídeo de fondo. Cada URL va a su equivalente temático, o a un 404 honesto. No hay tercera opción.

Olvidar los recursos. El PDF del catálogo, la imagen que alguien enlazó en un foro, la URL de la política de cookies que aparece en tu documentación legal. También son direcciones.

Antes del lanzamiento pasamos la lista completa de URLs antiguas por una comprobación automática que verifica, una por una, el código de estado y el destino final. Sin excepciones y sin muestreo.

Cambio de dominio: un caso aparte

Si además del diseño cambias el dominio — de .com a .es, por rebranding, por separación de sociedades — hay una herramienta específica y tiene reglas estrictas.

Tres condiciones que conviene conocer antes de planificar:

• Necesitas ser propietario verificado de ambas propiedades en la misma cuenta de Google.
• La herramienta funciona solo a nivel de dominio, no de ruta. Puedes mover ejemplo.com; no puedes mover ejemplo.com/tienda.
• Requiere una redirección 301 de la portada antigua a la nueva antes de empezar.

Y una precisión que ahorra confusión: no la necesitas si pasas de HTTP a HTTPS, si cambias entre www y sin www en el mismo dominio, o si reorganizas rutas dentro del mismo dominio. Para eso basta con el mapa de redirecciones bien hecho.

Sobre plazos, Google no promete nada más allá de esto: "un sitio web pequeño o mediano puede tardar unas semanas en que la mayoría de sus páginas se muevan, y los sitios grandes tardan más". Cualquiera que te dé una fecha exacta de recuperación está inventando.

1. El entorno de pruebas indexado

El clásico. Se desarrolla en nuevo.tudominio.es, se olvida bloquearlo, Google lo indexa y el día del lanzamiento tienes dos versiones de cada página compitiendo entre sí.

Y su variante inversa, más silenciosa: bloquear el entorno con robots.txt y creer que eso lo desindexa. No lo hace. Google es tajante: "si la página está bloqueada por un archivo robots.txt o el rastreador no puede acceder a ella, el rastreador nunca verá la regla noindex". La forma correcta es dejar rastrear y devolver noindex, con la etiqueta meta o con la cabecera X-Robots-Tag. El bloqueo por contraseña también sirve, y es lo que usamos nosotros.

2. Lanzar con el noindex puesto

El reverso exacto. El entorno de pruebas llevaba noindex en la plantilla base y nadie lo quitó al publicar. La web nueva funciona, se ve bien, y está pidiendo activamente que no la indexen. Es un fallo de treinta segundos que cuesta seis semanas. Va en la lista de verificación previa, no en la memoria de nadie.

3. Podar contenido sin datos

"Estas 30 entradas del blog son viejas, las quitamos." Antes de borrar, cruza el listado con la exportación de Search Console. La entrada de 2019 que nadie recuerda puede ser la que te trae una parte apreciable de las visitas de búsqueda. Si el contenido sobra de verdad, se retira y su URL se redirige al contenido que lo sustituye. Se decide con la exportación delante, no con el criterio estético de la reunión.

4. Romper la capa legal en la mudanza

Al cambiar de plataforma se rehace el banner de cookies y se pierde la configuración que ya funcionaba: el consentimiento previo, el bloqueo real de las etiquetas antes de aceptar, la señal que la analítica necesita. La web nueva puede ser más rápida y a la vez menos conforme que la antigua. Lo tratamos como una plantilla más del proyecto, con sus pruebas. El detalle está en Obligaciones legales de una web en España.

Añade un caso español muy concreto: si tu web actual salió de un bono de Kit Digital, revisa qué compromisos de mantenimiento y de permanencia sigue vivos tu contrato con el agente digitalizador antes de sustituir nada.

5. Confundir rediseño con cambio de plataforma

Son dos proyectos. Puedes rediseñar sobre la misma plataforma y puedes migrar de plataforma sin tocar el diseño. Hacer los dos a la vez multiplica las variables y hace imposible saber qué causó qué cuando algo falle. Cuando el cliente insiste, lo hacemos igual, pero secuenciado y con dos ventanas de lanzamiento distintas. El árbol de decisión de plataforma está en Qué plataforma elegir para tu web en 2026.

Rendimiento: qué mejora de verdad

El rediseño es la mejor oportunidad que vas a tener para arreglar la velocidad, y la peor si nadie la vigila. Los umbrales son públicos y no admiten interpretación.

Dos matices que casi ninguna página española sobre el tema recoge, y que se contradicen entre sí solo en apariencia.

El primero: Google dice literalmente que "las Core Web Vitals se usan en nuestros sistemas de posicionamiento", y en la misma página que obtener buenos resultados "no garantiza que tus páginas se posicionen arriba". Añade que la Búsqueda "siempre trata de mostrar el contenido más relevante, aunque la experiencia de página sea deficiente". Traducción operativa: la velocidad no compra posiciones, pero desempata. Optimizar por debajo del umbral no te da nada extra; estar por encima sí te resta.

El segundo, y es el que rompe expectativas: los datos de campo tardan.

Si lanzas hoy, dentro de dos semanas tu informe de campo sigue mezclando la web antigua con la nueva. La lectura limpia llega a los 28 días. Quien te enseñe una mejora de campo a los cinco días te está enseñando un dato de laboratorio y llamándolo otra cosa. Cuándo compensa optimizar y cuánto, en Rendimiento web para negocios.

Accesibilidad: en 2026 rediseñas bajo la EAA

Si vas a rehacer la capa de interacción de tu web, rehazla conforme. Rehacerla dos veces cuesta el doble.

La directiva cubre expresamente los "servicios de comercio electrónico", definidos como servicios prestados a distancia a través de sitios web y aplicaciones móviles para celebrar un contrato de consumo. También servicios bancarios, transporte de viajeros, libros electrónicos y telefonía. Y exime a las microempresas que prestan servicios: el artículo 4 establece que los requisitos y obligaciones de la directiva "no se aplicarán a las microempresas que presten servicios".

Esa exención es más estrecha de lo que la gente cree y no exime a microempresas que fabrican o distribuyen productos incluidos en el ámbito. Antes de acogerte a ella, comprueba tu caso. El detalle, en Accesibilidad web en España tras la European Accessibility Act.

Comprobado el 27-08-2026 contra el texto de la Directiva (UE) 2019/882 y la Ley 11/2023 publicada en el BOE. El desarrollo reglamentario español y los criterios de supervisión pueden evolucionar: verifica el estado vigente antes de tomar una decisión con consecuencias contractuales.

Un aviso práctico: los widgets superpuestos que prometen conformidad en una línea de JavaScript no la dan. La accesibilidad se resuelve en el marcado, en el contraste, en el orden de foco y en los estados. Por qué los overlays no bastan, aquí.

El lanzamiento: orden y primeras 72 horas

El lanzamiento es una lista de verificación, no un salto de fe. Estas son las decisiones que tomamos antes de la ventana.

Cuándo. Martes o miércoles por la mañana. Nunca un viernes, nunca la víspera de festivo, nunca en tu semana de más facturación. Si vendes turrón, no se lanza en noviembre.

En qué orden. Primero las redirecciones, después el DNS. Nunca al revés: si el dominio ya apunta al servidor nuevo y las redirecciones no están, cada visita a una URL antigua es un 404 servido a un usuario real.

Con qué salida. Un plan de reversión escrito, con el nombre de quien lo ejecuta y el tiempo estimado. Si no puedes volver atrás en menos de una hora, no estás listo para lanzar.

• Comprobación automática de las URLs antiguas: código de estado y destino final, sin muestreo
• Sitemap nuevo generado y enviado en Search Console; sitemap antiguo retirado después
• robots.txt de producción revisado línea a línea, y ninguna plantilla con noindex heredado del entorno de pruebas
• Certificado válido y redirección forzada a HTTPS, con la versión canónica de dominio elegida y aplicada
• Formularios enviados de prueba, uno por uno, confirmando que el correo llega a la bandeja correcta
• Pasarela de pago probada con una transacción real de importe mínimo, incluida la notificación de vuelta
• Analítica y consentimiento verificados: la etiqueta no dispara antes de aceptar y sí dispara después
• Errores de servidor vigilados en los registros durante las primeras 24 horas
• Informe de páginas indexadas en Search Console revisado al tercer día para detectar picos de 404 y de exclusiones

Nuestra lista completa, la que aplicamos en producción, tiene 47 comprobaciones y está publicada entera en Checklist de 47 comprobaciones antes de poner una web en producción.

Una nota sobre el sitemap: no lo infles. El límite de un archivo es de 50.000 URLs o 50 MB sin comprimir, y Google usa el valor lastmod solo "si es coherente y verificablemente preciso", mientras ignora por completo priority y changefreq. Un sitemap con fechas falsas es peor que uno sin fechas.

Qué medir después, y cuándo mirarlo

La tentación es abrir la analítica cada hora del primer día. No sirve de nada y genera decisiones malas. Este es el calendario que seguimos.

Compara siempre contra el mismo periodo del año anterior, no contra el mes pasado. En España, agosto y diciembre distorsionan cualquier lectura, y un rediseño lanzado en julio parecerá un desastre en agosto por razones que no tienen nada que ver con tu web.

Y compara por página, no solo en agregado. Un total plano puede esconder que tus cinco páginas comerciales han caído mientras el blog ha subido. El agregado consuela; el desglose informa.

Cuánto tarda y cuánto cuesta

Nuestro marco de trabajo: marca y web en 6-12 semanas, productos digitales en fases de 8 semanas. Precio fijo por fase, acordado antes de empezar, sin horas sorpresa. Al terminar entregamos código, archivos fuente y documentación, y quedan 30 días de soporte incluido tras el lanzamiento.

Un rediseño con conservación de posicionamiento añade trabajo que una web nueva no tiene: el inventario, el mapa de redirecciones, la migración de contenido y la vigilancia posterior. Ese trabajo se presupuesta aparte y se nombra en el contrato, para que sepas exactamente qué estás pagando.

— = dato en medición; lo publicaremos cuando tengamos muestra propia.

Sobre plazos de recuperación no damos garantías porque nadie puede darlas. Lo que sí podemos decirte es lo que hemos medido en nuestros propios proyectos:

Y su reverso, que es el dato que de verdad querrías conocer antes de firmar:

Cuando esos dos números estén medidos con método, se publican aquí con su n y su fecha. Preferimos un hueco marcado a una cifra cómoda. Si quieres ver cómo tratamos los precios con el mismo criterio, está en Por qué casi ninguna agencia española publica precios (y estos son los nuestros), y el presupuesto se lee sabiendo si la cifra va con IVA o sin él: eso lo desarrollamos en ¿Los precios de una web llevan IVA?.

Cuándo no deberías rediseñar

Tres situaciones en las que rechazamos el proyecto o proponemos otra cosa.

Cuando el problema es de oferta, no de web. Si nadie te compra porque tu propuesta no está clara en tu cabeza, una web nueva la expresará mal con mejor tipografía.

Cuando acabas de rediseñar. Si tu web tiene menos de dieciocho meses y el problema es la conversión, se arregla con cambios medidos en tres plantillas. Rediseñar entero es tirar aprendizaje.

Cuando no hay nadie que pueda mantenerla. Entregar un sistema que tu equipo no puede tocar es fabricar una dependencia. Diseñamos para que tu equipo pueda seguir sin nosotros, y si no hay equipo, lo primero que hay que resolver es eso.

Un rediseño se juzga por lo que conserva, no por lo que estrena.

Un rediseño bien hecho no se nota. No hay caída, no hay semana rara, no hay reunión de emergencia. El teléfono sigue sonando igual y a los tres meses suena algo más. Ese silencio es el resultado.

Un rediseño no es una oportunidad de reinventarte: es una oportunidad de conservar lo que ya funciona y quitar lo que estorba. Empezamos preguntando qué páginas te dan de comer, no proponiendo una paleta.

¿Te encaja esta forma de trabajar? Cuéntanos qué tienes delante en una primera llamada de 30 minutos sin coste. Respondemos en menos de 24 horas laborables.

Preguntas frecuentes

¿Cuánto tráfico se pierde al rediseñar una web?

Con las URLs intactas y el contenido conservado, la pérdida debería ser cero o cercana a cero. Si cambias las URLs, hay una fluctuación normal de semanas mientras Google reindexa; Google indica que un sitio pequeño o mediano puede tardar unas semanas en mover la mayoría de sus páginas. Nadie puede garantizarte una cifra exacta, y quien lo haga te está vendiendo humo.

¿Es mejor mantener las URLs antiguas aunque sean feas?

Sí, en la mayoría de los casos. Una URL fea que posiciona vale más que una nueva que empieza de cero. Cambia solo las que sean incoherentes con la estructura nueva, y cuando lo hagas, redirígelas una a una con un 301.

¿Cuánto tiempo hay que mantener las redirecciones?

Google recomienda mantenerlas al menos un año. Nosotros las dejamos indefinidamente y lo documentamos en el traspaso: mantener una tabla de redirecciones no cuesta nada y retirarla el día equivocado cuesta un mes de tráfico.

¿Puedo rediseñar y cambiar de plataforma a la vez?

Puedes, pero multiplicas las variables y pierdes la capacidad de saber qué causó un problema. Nosotros lo secuenciamos en dos ventanas de lanzamiento separadas. Si tu calendario no lo permite, lo hacemos junto y te lo decimos claro: el diagnóstico posterior será más lento.

¿Hay que volver a hacer el banner de cookies y la accesibilidad?

Sí. Cambiar la capa de interacción invalida las pruebas anteriores. Aprovecha la obra para dejar la web conforme desde el primer día, porque rehacerla en dos pasadas cuesta el doble.

Sigue leyendo

• Cuándo rediseñar tu web: 7 umbrales medibles (no «7 señales»)
• Checklist de 47 comprobaciones antes de poner una web en producción
• Rendimiento web para negocios: qué son los Core Web Vitals y cuándo compensa optimizar
• Accesibilidad web en España tras la European Accessibility Act
• Qué plataforma elegir para tu web en 2026: árbol de decisión honesto
• Cómo conseguir que tu web aparezca en Google y sea citada por ChatGPT y Perplexity
• Plantilla de contrato y cesión de derechos

Nota de transparencia. Algunos datos propios de esta guía todavía están en medición en proyectos reales, con un mismo método. Los publicaremos con su tamaño de muestra y su ventana de fechas cuando la muestra sea suficiente; hasta entonces, cada cifra que ves lleva su fuente y su fecha de consulta.

Fuentes verificadas

• https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes — recomendación de redirecciones permanentes 301/308, «keep the redirects for as long as possible, generally at least 1 year», plazos de traslado («a few weeks» para sitios pequeños y medianos) y envío del sitemap nuevo. Consultado 27-08-2026.
• https://developers.google.com/search/docs/crawling-indexing/301-redirects — diferencia entre permanentes (301/308, señal de canonical) y temporales (302/307, sin esa señal); meta refresh a 0 s vs con retardo; advertencia sobre redirecciones por JavaScript. Consultado 27-08-2026.
• https://developers.google.com/search/docs/crawling-indexing/site-move-no-url-changes — caída temporal del ritmo de rastreo tras un cambio de infraestructura y recomendaciones de vigilancia (registros de servidor, informes de indexación). Consultado 27-08-2026.
• https://support.google.com/webmasters/answer/9370220 — herramienta de cambio de dirección: propiedad verificada de ambas propiedades en la misma cuenta, solo a nivel de dominio, 301 de portada a portada, y señal de traslado durante 180 días. Consultado 27-08-2026.
• https://developers.google.com/search/docs/crawling-indexing/block-indexing — «si la página está bloqueada por robots.txt o el rastreador no puede acceder, nunca verá la regla noindex»; implementación con meta robots o X-Robots-Tag. Consultado 27-08-2026.
• https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap — límite de 50.000 URLs o 50 MB sin comprimir por sitemap; uso de lastmod solo si es preciso y verificable; priority y changefreq ignorados. Consultado 27-08-2026.
• https://developers.google.com/search/docs/appearance/page-experience — «Core Web Vitals are used by our ranking systems», buenos resultados no garantizan posiciones, y la Búsqueda muestra el contenido más relevante aunque la experiencia de página sea deficiente. Consultado 27-08-2026.
• https://web.dev/articles/vitals — umbrales «bueno»: LCP 2,5 s, INP 200 ms, CLS 0,1, evaluados en el percentil 75 segmentado por móvil y escritorio. Consultado 27-08-2026.
• https://developer.chrome.com/docs/crux/api — «The data in the Chrome UX Report is a 28-day rolling average of aggregated metrics»; actualización diaria en torno a las 04:00 UTC. Consultado 27-08-2026.
• https://developer.chrome.com/docs/crux/methodology — criterios de elegibilidad de CrUX: la página debe ser públicamente detectable (no noindex, código 200) y suficientemente popular. Consultado 27-08-2026.
• https://support.google.com/webmasters/answer/7576553 — el informe de rendimiento de Search Console muestra por defecto los tres últimos meses. Consultado 27-08-2026.
• https://support.google.com/analytics/answer/7667196 — conservación de datos en GA4: 2 o 14 meses en propiedades estándar (26/38/50 en 360); no afecta a los informes agregados estándar. Consultado 27-08-2026.
• https://eur-lex.europa.eu/legal-content/ES/TXT/HTML/?uri=CELEX:32019L0882 — Directiva (UE) 2019/882: art. 31 (medidas aplicables desde el 28 de junio de 2025), art. 4 (los requisitos no se aplican a las microempresas que presten servicios), art. 2 (servicios de comercio electrónico incluidos). Consultado 27-08-2026.
• https://www.boe.es/diario_boe/txt.php?id=BOE-A-2023-11022 — Ley 11/2023, de 8 de mayo, de trasposición de Directivas de la UE en materia de accesibilidad de determinados productos y servicios (entre otras); BOE de 9 de mayo de 2023. Consultado 27-08-2026.
• https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/european-accessibility-act-eaa_en — listado de productos y servicios cubiertos por la EAA (comercio electrónico, servicios bancarios, transporte de viajeros, libros electrónicos, telefonía). Consultado 27-08-2026.