Rediseñar una web sin perder SEO: checklist de migración
Lista de comprobación para preparar un rediseño web: URLs, redirecciones, canónicas y seguimiento para reducir el riesgo de perder posicionamiento.
Una web lenta puede deberse a imágenes pesadas, JavaScript que bloquea las interacciones o una respuesta tardía del servidor. Para arreglarla, identifica qué falla —carga, respuesta o estabilidad— con PageSpeed Insights, los Core Web Vitals y pruebas de uso reales. Prioriza la causa comprobada, no una puntuación aislada.
Web lenta: empieza por el síntoma, no por la puntuación
«Va lenta» no identifica una causa. La página puede tardar en mostrar lo que necesitas, aparecer pronto pero quedarse bloqueada o mover un botón cuando vas a pulsarlo. Son problemas distintos y requieren comprobaciones distintas.
La estabilidad visual no mide velocidad de carga. Un aviso que desplaza el formulario puede molestar aunque los recursos hayan llegado rápido. Antes de abrir un informe, observa estas situaciones:
- Carga: ¿cuándo puedes ver el contenido principal y entender qué ofrece la página?
- Respuesta: ¿el menú, el botón o el selector reaccionan al tocarlos?
- Estabilidad: ¿el texto y los controles mantienen su posición mientras utilizas la web?
Por ejemplo, en la página de destino de una clínica dental, entra desde el móvil, intenta leer el titular y comprueba si puedes completar el formulario. Anota dónde aparece la fricción: espera inicial, teclado que tapa un campo o botón que se desplaza. No todo se resolverá reduciendo el peso de las imágenes.
Cómo diagnosticar una web lenta paso a paso
No limites el diagnóstico a la portada. Una web puede cargar bien ahí y atascarse en la página que recibe consultas. Empieza por las URL que participan en una acción útil para tu negocio.
Elige páginas y condiciones comparables
Selecciona una página de servicio, una página de campaña y el recorrido de contacto, si existen. En una tienda online, añade una ficha de producto y el carrito; en un hotel, el acceso al motor de reservas.
Abre PageSpeed Insights y analiza cada URL. Guarda la fecha, el perfil de análisis —móvil u ordenador— y el informe.
En las pruebas manuales, anota la conexión, el navegador y el estado del consentimiento. Repite las pruebas en condiciones semejantes para poder comparar los resultados.
Separa datos de campo y laboratorio
La documentación de PageSpeed Insights distingue datos de campo y laboratorio. Los primeros proceden de CrUX y reflejan experiencias reales de usuarios de Chrome. Lighthouse hace una prueba de laboratorio en condiciones controladas: sirve para investigar, pero no reproduce todas las visitas.
En PageSpeed Insights, los datos de campo de CrUX abarcan una ventana móvil de 28 días. Comprueba si el informe muestra datos de esa URL o del origen, que puede agrupar varias páginas del sitio. Un dato agregado del origen no describe necesariamente cómo funciona la página de destino que estás revisando.
Conserva ambos bloques. Usa el laboratorio para localizar posibles causas y los datos de campo para conocer la experiencia de las visitas incluidas en la muestra. No compares sus resultados como si midieran exactamente lo mismo.
Contrasta el informe con tareas reales
Prueba menú, formulario, botones y aviso de consentimiento en un teléfono real. En una asesoría, verifica que elegir un trámite no bloquea la página y que los errores del formulario se entienden. Comprueba también qué sucede tras aceptar o rechazar las cookies.
El TBT, o tiempo total de bloqueo, puede ayudar a detectar bloqueos durante la prueba de laboratorio. No equivale al INP de los usuarios reales. Utilízalo como pista para investigar, no como sustituto de una prueba de interacción.
Core Web Vitals: qué mide cada indicador
Los Core Web Vitals son tres métricas de experiencia de usuario: LCP evalúa la carga, INP la respuesta a las interacciones y CLS la estabilidad visual. Ayudan a orientar el diagnóstico, pero no identifican la causa por sí solas. Relaciona cada indicador con un recurso, una interacción o un desplazamiento observado.
Las definiciones y umbrales de Web Vitals de Google ofrecen una referencia común. Utiliza esta tabla para decidir por dónde investigar, no para dar la web por revisada.
| Indicador | Qué mide | Umbral bueno | Primera comprobación |
|---|---|---|---|
| LCP | Cuándo se muestra el elemento de contenido más grande visible. | ≤ 2,5 s | Identificar el elemento LCP y qué retrasa su aparición. |
| INP | La capacidad de respuesta a las interacciones. | ≤ 200 ms | Revisar las interacciones lentas y el trabajo que bloquea la respuesta. |
| CLS | Los desplazamientos inesperados del contenido. | ≤ 0,1, sin unidad | Buscar imágenes, bloques o fuentes que alteran el espacio reservado. |
En campo se evalúa el percentil 75: para cumplir el criterio, al menos tres cuartas partes de las visitas medidas deben quedar dentro del umbral bueno de cada indicador. No se evalúa la mejor prueba ni una media. Distingue dispositivo y ámbito del dato: URL u origen.
Los tres indicadores deben cumplir sus umbrales para superar la evaluación cuando hay datos suficientes. Una página con buen LCP puede seguir respondiendo mal al desplegar un menú. Y un CLS bajo no dice si resulta fácil encontrar el teléfono de una clínica.
El resultado tampoco es una auditoría completa de usabilidad. Comprueba legibilidad, navegación y contacto aunque el informe salga favorable. La puntuación de rendimiento de Lighthouse y la evaluación de Core Web Vitals son cosas diferentes.
Qué corregir en una web lenta según la causa que detectes
Corrige el cuello de botella que puedas demostrar. Anota qué esperas mejorar y cómo lo comprobarás después. Instalar otro plugin sin diagnóstico puede añadir complejidad sin resolver el problema.
Imagen principal, fuentes y saltos de diseño
Identifica primero el elemento LCP: puede ser una imagen o un bloque de texto. Si es una imagen, revisa sus dimensiones, formato y momento de descarga. No apliques carga diferida por sistema a la imagen principal visible al entrar.
Cuando el elemento LCP es una imagen, la guía de Google para optimizar LCP distingue el tiempo hasta el primer byte, el retraso hasta solicitar el recurso, su descarga y el retraso hasta mostrarlo. Una imagen ligera puede aparecer tarde si el navegador la descubre tarde o si otro trabajo retrasa su visualización.
En una ficha de producto, utiliza una imagen ajustada al espacio donde se mostrará y comprueba el resultado visual en móvil. Mejorar el LCP exige reducir la espera real, no comprimir a ciegas hasta perder detalle.
Para reducir el CLS, reserva espacio para imágenes, avisos y otros bloques que se cargan después. Revisa también las fuentes: si la tipografía definitiva cambia el tamaño del texto, puede desplazar controles. Tras el cambio, recorre la página y observa si el contenido permanece estable.
JavaScript, etiquetas y elementos de terceros
Revisa qué JavaScript se ejecuta y en qué momento. Un chat, un mapa o un sistema de reservas puede añadir trabajo justo cuando intentas interactuar. No elimines un componente porque aparezca en el informe: comprueba si participa en el bloqueo.
Para mejorar el INP, localiza las interacciones lentas y las tareas que ocupan el navegador antes de mostrar la respuesta. Si el menú se queda parado, pide revisar qué código coincide con esa acción. La solución puede ser reducir trabajo, dividirlo o posponer lo que todavía no hace falta.
En una asesoría, quizá el mapa pueda cargarse cuando se necesite, mientras el formulario debe seguir disponible. Prueba cualquier cambio de forma controlada. No rompas la navegación con teclado, el consentimiento ni la medición para conseguir una nota mejor.
Servidor, caché y entrega del contenido
El TTFB es el tiempo hasta recibir el primer byte y sirve como pista diagnóstica. No es un Core Web Vital. Puede verse afectado por la conexión, las redirecciones y el tiempo que necesita la aplicación para responder.
Compara distintas páginas y revisa si el retraso cambia con la caché. Esta puede evitar que se genere una respuesta de nuevo, pero no arregla una interacción bloqueada por JavaScript. En una tienda online, comprueba que el carrito y los datos personalizados quedan fuera de cualquier caché compartida.
Si la evidencia apunta a esa capa, coordina la administración de servidores con quien mantiene la aplicación. Pide revisar tiempos de respuesta, redirecciones y caché, no una migración a ciegas. Después de cada ajuste, repite las pruebas sobre las mismas URL.
Cómo conectar la velocidad con Google Ads y SEO
En Ads, revisa lo que ocurre después del clic
Una página lenta puede añadir fricción después del clic. En la página de destino de un taller, la persona necesita entender qué reparación se ofrece y cómo consultar disponibilidad. Si el mensaje no encaja con su búsqueda, mejorar la carga no corrige ese desencuentro.
Para interpretar contactos y conversiones, revisa las métricas de Google Ads. Separa la comprobación técnica de la comercial y anota si también has cambiado anuncios, oferta, formulario o medición. No atribuyas cualquier variación de consultas al último ajuste de velocidad.
Si la revisión afecta a las campañas, consulta el servicio de gestión de Google Ads.
Comprueba además que la página de destino real es la que has medido. Una portada rápida no compensa una página de destino que deja esperando al visitante.
En SEO, mejora la experiencia sin prometer posiciones
Según Google Search Central, los Core Web Vitals son una señal más de sus sistemas de posicionamiento. Encajan en la optimización SEO, pero no sustituyen la relevancia, el contenido útil ni otras señales. Mejorarlos no garantiza posiciones.
Si utilizas un método de SEO con IA para ordenar tareas, exige que cada recomendación incluya evidencia, hipótesis y forma de validación. «Retrasar scripts» está incompleto: falta saber cuáles, qué problema causan y cómo se comprobará que todo sigue funcionando.
Al colaborar con la IA, deja la decisión final en manos de una persona que pueda revisar las dependencias de la web. Una sugerencia bien redactada todavía necesita contrastarse con el informe y con las tareas reales.
Qué hacer esta semana para mejorar la velocidad de tu web
No necesitas empezar por un rediseño. Esta semana puedes convertir «la web va lenta» en una lista breve de problemas comprobados, con responsable y forma de verificar cada cambio.
- Selecciona las páginas importantes. Elige las que participan en la navegación y el contacto: páginas de servicio, de campaña, de producto o de reserva. Incluye el recorrido completo cuando puedas.
- Guarda una línea de partida. Anota URL, fecha, dispositivo, condiciones, datos de campo disponibles y prueba de laboratorio. Conserva el informe, no solo la nota.
- Clasifica el problema observado. Distingue carga, respuesta y estabilidad. Describe la tarea afectada para que otra persona pueda reproducir lo que has visto.
- Asigna una corrección concreta. Decide si corresponde a infraestructura, recursos o diseño y desarrollo de la web, según la evidencia. Evita acumular cambios sin poder compararlos.
- Repite la prueba y comprueba funciones. Revisa formularios, consentimiento y medición. Mantén el seguimiento de campo para comprobar si el cambio se refleja en el uso real.
Una mejora en Lighthouse no actualiza de inmediato los datos agregados de usuarios: la ventana móvil de CrUX incorpora las visitas nuevas de forma gradual.
Si quieres una segunda mirada sobre esas prioridades, pide una auditoría gratuita. Nuestra propia web está hecha a medida y obtiene 100/100 de rendimiento en PageSpeed Insights —puedes comprobarlo tú mismo en pagespeed.web.dev—. Es un resultado propio, no una garantía para otras webs, pero sabemos qué hay que revisar para acercarse.