GUÍA · TÉCNICO Y CONFIANZA

Cuándo conviene rediseñar tu página web (y cuándo el problema es otro)

Conviene rediseñar tu página web cuando fallan al menos dos de seis señales medibles, y la primera es objetiva: si el sitio no pasa las Core Web Vitals —LCP mayor a 2,5 segundos, INP mayor a 200 milisegundos o CLS mayor a 0,1 en el percentil 75 de las visitas reales, según los umbrales oficiales de Google en web.dev (agosto de 2026)—, el rediseño ya tiene una justificación técnica y no estética. Las otras cinco señales son igual de verificables: que el sitio no funcione bien en el celular, que corra sobre tecnología fuera de soporte, que no tenga HTTPS o haya estado infectado, que reciba visitas y no genere consultas, y que lo que dice el sitio ya no sea lo que vendés. El dato incómodo es el del otro lado: el 52% de los sitios móviles del mundo reprueba las Core Web Vitals (Web Almanac 2025 de HTTP Archive, con datos de julio de 2025), así que reprobar no te hace único ni justifica solo por eso tirar todo abajo. Y hay cuatro casos concretos en los que rediseñar es tirar la plata: están en la sección 6. Si al final rediseñás, lo que decide si perdés o no el posicionamiento ganado no es el diseño: es el mapeo de URLs viejas a nuevas con redirecciones 301, que según la documentación oficial de Google Search Central no pierden PageRank y hay que mantener al menos un año.

ACTUALIZADO EN AGOSTO DE 2026

Escrito por Franco BovoneFundador de Point Web. Trabaja con sitios y campañas de negocios argentinos desde 2021.

¿Cuándo conviene rediseñar tu página web?

Conviene rediseñar cuando fallan al menos dos de estas seis señales, y todas se miden con herramientas gratuitas en menos de una hora. Una sola señal casi nunca justifica un rediseño completo: casi siempre se arregla con un ajuste puntual, que cuesta una fracción.

La diferencia entre un rediseño necesario y un rediseño de capricho es exactamente esta lista. Un sitio que carga en 1,8 segundos, se usa bien en el celular, tiene HTTPS y genera consultas todos los días no necesita rediseño aunque el diseño te aburra. Un sitio lindo que reprueba cuatro de las seis señales sí lo necesita, aunque lo hayan entregado el año pasado.

Ojo con el orden de los factores: el rediseño se decide con datos y después se discute la estética, nunca al revés. Cuando la decisión arranca por «no me gusta cómo se ve», el proyecto termina siendo un cambio de colores caro que no mueve ninguno de los seis números.

Señal	Qué se mide	Umbral que reprueba	Herramienta gratuita
1. Velocidad y estabilidad visual	Core Web Vitals con datos de usuarios reales	LCP > 2,5 s · INP > 200 ms · CLS > 0,1 (percentil 75)	PageSpeed Insights + informe de Core Web Vitals de Search Console
2. Uso en celular	Si el sitio se puede operar con una mano, sin zoom	Texto ilegible, botones que no se aciertan, tablas cortadas	Tu propio celular + modo dispositivo de Chrome DevTools
3. Tecnología fuera de soporte	Versión de PHP, plugins y librerías	PHP anterior a 8.2, Flash, plugins sin actualizar hace más de 2 años	Panel del hosting + Salud del sitio de WordPress
4. Seguridad	Certificado y estado del sitio	Sin HTTPS, aviso «No es seguro» en Chrome, o antecedentes de infección	Barra del navegador + Problemas de seguridad en Search Console
5. Conversión	Consultas generadas cada 100 visitas	El sitio recibe tráfico sostenido y no produce contactos	GA4 + tu propio registro de WhatsApp y mails
6. Alineación con el negocio	Qué vendés hoy contra qué dice el sitio	Servicios, público o precios que ya no son los actuales	Leer el sitio con tu lista de servicios al lado

¿Cómo sabés si tu sitio reprueba las Core Web Vitals?

Lo sabés en dos minutos: pegá la URL de tu página en PageSpeed Insights y mirá el bloque «Descubre lo que están experimentando tus usuarios reales». Si alguno de los tres indicadores está en rojo o en amarillo, el sitio reprueba. Ese bloque usa datos de campo del Chrome UX Report, no una simulación.

Los tres umbrales que publica Google en web.dev (vigentes en agosto de 2026) son fijos y públicos, así que no hay lugar para interpretaciones del proveedor. Y hay un cuarto dato que casi nadie mira: la medición se hace sobre el percentil 75 de las visitas reales, separando móvil de escritorio. Que a vos te cargue rápido con fibra en la oficina no dice nada: el percentil 75 lo define el visitante con 4G flojo.

Para dimensionar: según el Web Almanac 2025 de HTTP Archive (datos de julio de 2025 sobre millones de sitios), el 48% de los sitios móviles y el 56% de los de escritorio pasan las tres métricas. La métrica que más traba es LCP, que la aprueba solo el 62% de los sitios móviles. La tendencia móvil viene subiendo: 36% en 2023, 44% en 2024 y 48% en 2025.

LCP (Largest Contentful Paint). Cuánto tarda en dibujarse el elemento más grande de la pantalla, casi siempre la imagen del encabezado. Bueno: 2,5 segundos o menos. Malo: más de 4 segundos.
INP (Interaction to Next Paint). Cuánto tarda la página en responder visualmente cuando alguien toca un botón o abre el menú. Bueno: 200 milisegundos o menos. Reemplazó a FID como métrica estable en 2024.
CLS (Cumulative Layout Shift). Cuánto se mueve el contenido mientras carga. Bueno: 0,1 o menos. Es la métrica de «apreté un botón y se me corrió».
Percentil 75. Google no promedia: exige que 75 de cada 100 visitas tengan una experiencia buena. Un solo dispositivo rápido no representa nada.
Datos de campo, no de laboratorio. El puntaje grande de 0 a 100 de PageSpeed Insights es una simulación y no es lo que Google usa para clasificar. Lo que cuenta es el bloque de usuarios reales.

¿Tu sitio funciona bien en el celular o solamente «se ve»?

Que el sitio se adapte al ancho de la pantalla no significa que funcione en el celular. La prueba real es operarlo con una mano, en la calle, con datos móviles: si necesitás hacer zoom para leer un precio, o errás el botón de contacto dos de cada tres veces, el sitio no es usable aunque sea técnicamente responsive.

El peso del celular no es opinable. Según StatCounter Global Stats, en julio de 2026 el 54,07% del tráfico web de Argentina vino de dispositivos móviles, contra 45,46% de escritorio y 0,47% de tablets. Y desde el lado de Google, la documentación oficial de Search Central es explícita: Google usa la versión móvil del contenido para indexar y clasificar, y «solo el contenido que se muestra en el sitio móvil se usa para la indexación».

Esa última frase tiene una consecuencia cara que se ve mucho en sitios viejos: si el sitio esconde secciones enteras en la versión móvil para «que cargue más rápido», ese contenido escondido deja de existir para Google. No es que rankea menos: no se indexa. Es una de las razones más frecuentes por las que un sitio pierde posiciones sin que nadie haya tocado nada.

Prueba del pulgar. Todo lo importante —teléfono, WhatsApp, precio, botón de compra— tiene que ser alcanzable con el pulgar, sin estirar la mano.
Prueba de la primera pantalla. En el celular, antes de scrollear tiene que estar claro qué vendés y cómo te contactan.
Prueba del formulario. Completá tu propio formulario desde el celular. Si el teclado tapa el botón de enviar, perdés consultas todos los días.
Prueba de paridad. Compará el texto de la versión móvil con el de escritorio. Si en el celular falta contenido, para Google ese contenido no existe.
Prueba de datos móviles. Apagá el WiFi. Un sitio que solo anda bien con fibra no está funcionando para la mitad del país.

¿Qué tecnología vencida te obliga a rediseñar sí o sí?

Hay tres casos donde el rediseño deja de ser una decisión comercial y pasa a ser mantenimiento obligatorio: contenido en Flash, PHP fuera de soporte y plugins abandonados. Los tres tienen fecha oficial, no son opinión de nadie.

Flash está muerto desde el 31 de diciembre de 2020, la fecha de fin de vida que Adobe anunció en julio de 2017, y desde el 12 de enero de 2021 Adobe directamente bloquea la ejecución de contenido Flash. Un sitio con animaciones o menús en Flash hoy muestra un rectángulo vacío: no hay parche, hay que rehacer esa parte.

Con PHP la fecha también es pública. Según php.net (agosto de 2026), toda versión anterior a PHP 8.2 está fuera de soporte y no recibe parches de seguridad; PHP 8.2 recibe solo parches de seguridad hasta el 31 de diciembre de 2026; las versiones con soporte activo son 8.4 y 8.5. Un WordPress corriendo sobre PHP 7.4 no está «un poco viejo»: está sin parches desde hace años, y eso es una puerta abierta.

El tercer caso es el más común en WordPress, que según W3Techs (14 de agosto de 2026) usa el 40,8% de todos los sitios web del mundo y el 59,0% de los que tienen un CMS conocido. Un plugin sin actualizaciones hace más de dos años es deuda técnica pura: cuando el tema o el constructor se actualizan, ese plugin rompe algo, y cuando aparece una vulnerabilidad, nadie la va a parchar.

¿Una tasa de rebote alta significa que hay que rediseñar?

No. La tasa de rebote es la señal más citada para justificar un rediseño y la menos confiable de las seis, porque en Google Analytics 4 dejó de medir lo que la gente cree que mide. Antes de usarla como argumento, hay que entender su definición actual.

Según la ayuda oficial de Google Analytics (2026), una sesión cuenta como sesión con interacción si cumple al menos una de tres condiciones: dura más de 10 segundos, registra un evento clave, o tiene 2 o más vistas de página. La tasa de rebote de GA4 es exactamente el inverso: el porcentaje de sesiones que no cumplieron ninguna de las tres. Es decir que una persona que entra, lee tu página 40 segundos y te llama por teléfono no cuenta como rebote, pero alguien que entra 8 segundos, encuentra tu dirección y se va, sí.

Por eso una tasa de rebote del 70% en una página de contacto o en una guía larga puede ser perfectamente sana, y una del 35% en una tienda puede ser terrible. El número solo sirve comparado contra sí mismo en el tiempo y segmentado por página y por dispositivo. Si el rebote de la home en celular se disparó 20 puntos después de un cambio, ahí sí hay una señal que investigar.

El indicador que sí obliga a mirar el sitio es más simple y no está en ninguna herramienta: consultas generadas cada 100 visitas. Si el sitio recibe tráfico sostenido durante tres meses y no produce ni una consulta, el problema está en la página. Si no recibe tráfico, el problema no es el diseño.

Consultas cada 100 visitas. El único número que importa para decidir un rediseño. Se calcula con GA4 más tu propio conteo de WhatsApp, mails y llamadas.
Rebote segmentado por página y dispositivo. El promedio del sitio no dice nada. El salto de la home en celular después de un cambio, sí.
Páginas de salida. Dónde abandona la gente el recorrido: si todos se van en el formulario, el problema es el formulario, no el diseño entero.
Comparación contra el mismo período del año anterior. La estacionalidad explica más caídas de tráfico que el diseño.

¿Cuándo NO conviene rediseñar tu página web?

En cuatro situaciones concretas, rediseñar es gastar plata en el lugar equivocado. Las decimos aunque el rediseño sea uno de nuestros servicios, porque el cliente que rediseña por el motivo equivocado vuelve enojado a los seis meses.

El caso más frecuente es el primero de la lista: el sitio no tiene visitas. Un sitio sin tráfico rediseñado sigue sin tráfico, solo que ahora es un sitio lindo sin tráfico. La plata del rediseño, puesta en campañas o en trabajo de visibilidad, cambia el número; puesta en un cambio de colores, no cambia nada.

No conviene si el sitio no recibe visitas. El rediseño mejora la tasa de conversión sobre el tráfico que ya tenés. Si entran 40 personas por mes, mejorar la conversión del 1% al 3% son 0,8 consultas más. El problema es de captación: mirá Google y Meta Ads o el trabajo de visibilidad, no el diseño.
No conviene si la única razón es «está pasado de moda». El gusto no es una métrica. Si el sitio pasa las Core Web Vitals, funciona en celular, tiene HTTPS y genera consultas, un rediseño estético pone en riesgo un activo que funciona a cambio de nada medible.
No conviene si no hay quién actualice el contenido. Un sitio nuevo con la misma información desactualizada de hace tres años es el mismo problema con tipografía nueva. Si nadie va a cargar los servicios, los precios ni las novedades, el rediseño se vence en el mismo plazo que el anterior.
No conviene si el problema real es el negocio, no la web. Si no tenés claro a quién le vendés, qué te diferencia y cuánto sale, ningún diseñador lo va a resolver por vos. Ese trabajo se hace antes, con la lista de servicios y precios cerrada.
Sí conviene, en cambio, si vas a cambiar de modelo de negocio. Pasar de mostrar productos a venderlos online no es un rediseño: es otro sitio, con otra estructura, otro checkout y otra facturación. Ese caso está explicado en tiendas online.

¿Se pierde posicionamiento al rediseñar una página web?

Depende de una sola cosa: si cambian las URLs o no. La documentación oficial de Google Search Central es clara en los dos escenarios, y confundirlos es el error que hace perder tráfico en la mayoría de los rediseños fallidos.

Si el rediseño mantiene las mismas URLs y el mismo contenido, para Google no hay traslado de sitio: hay una página que cambió de aspecto. El riesgo de perder posiciones es bajo. El riesgo real ahí es otro y es el que nadie mira: que el rediseño borre texto. Muchos rediseños «modernizan» reemplazando 800 palabras por tres frases y una foto grande, y con eso se lleva puesto el contenido por el que Google rankeaba la página.

Si el rediseño cambia URLs o de dominio, sí es un traslado de sitio y tiene su propia documentación. Google afirma sobre las redirecciones permanentes que «no hay pérdida en PageRank», pero también avisa que «es posible que experimentes fluctuaciones en la clasificación mientras Google vuelve a rastrear e indexar tu sitio». Las dos frases conviven: no se pierde autoridad, pero sí hay un período de reacomodamiento.

Sobre el tipo de redirección, la documentación de Google sobre redirecciones no deja margen: las permanentes (301 y 308) son la señal más fuerte y el sistema de indexación las usa como indicador de que el destino tiene que ser la URL canónica; las temporales (302, 303, 307) no se usan como indicador de canonicalización. Una migración hecha con 302 es una migración a medio hacer.

Escenario	¿Google lo trata como traslado?	Riesgo SEO	Qué hay que hacer
Mismas URLs, mismo contenido, diseño nuevo	No	Bajo	Conservar títulos, H1 y textos; medir Core Web Vitals antes y después
Mismas URLs, contenido reescrito o recortado	No	Medio	No borrar texto que rankea; reescribir sumando, no restando
URLs nuevas dentro del mismo dominio	Sí	Alto si no hay 301	Mapeo 1 a 1 con redirecciones 301 del lado del servidor
Dominio nuevo	Sí	Alto	301 + herramienta de cambio de dirección de Search Console
HTTP a HTTPS	Sí, pero Google lo detecta solo	Bajo	301 de todo el sitio; NO se usa la herramienta de cambio de dirección

¿Cómo rediseñás sin perder el posicionamiento ganado?

Con nueve pasos en orden, y ocho de los nueve se hacen antes de publicar. El error clásico es publicar el sitio nuevo un viernes y recién el lunes ponerse a ver qué URLs quedaron rotas: para ese momento Google ya rastreó cientos de páginas devolviendo error 404.

El paso que decide todo es el número 2, el mapeo. Es una planilla aburrida de dos columnas —URL vieja, URL nueva— con todas las URLs que Google ya conoce, no solo las del menú. Se arma con la exportación de páginas de Search Console, el sitemap actual y los informes de páginas más vistas de GA4. Si una URL vieja no tiene equivalente exacto, se redirige a la página más parecida, nunca a la home en bloque.

1. Inventario de URLs. Exportá todas las URLs indexadas desde Search Console, el sitemap.xml y las páginas con tráfico de los últimos 12 meses en GA4. Esa es la lista que hay que preservar.
2. Mapeo 1 a 1. Planilla de URL vieja → URL nueva, para cada una. Las que no tengan equivalente van a la página más cercana por tema. Redirigir todo a la home es la receta para perder esas posiciones.
3. Conservar el contenido que rankea. Antes de reescribir, mirá qué consultas trae cada página en Search Console. Ese texto se puede mejorar, no borrar.
4. Conservar títulos, H1 y metadescripciones de las páginas que ya traen clics. Si el título cambia, cambia el CTR, y eso es un experimento aparte del rediseño.
5. Redirecciones 301 del lado del servidor. Google ordena las opciones por fiabilidad: primero redirección del servidor, después meta refresh instantánea, y solo si no queda otra, JavaScript. En WordPress, a nivel servidor o con un plugin de redirecciones.
6. Probar en staging con la lista en la mano. Cada URL vieja del mapeo tiene que devolver 301 al destino correcto, sin cadenas de dos o tres saltos.
7. Sitemap nuevo y Search Console. Publicá el sitemap actualizado y enviálo. Si cambiaste de dominio, usá también la herramienta de cambio de dirección, que reenvía señales durante 180 días.
8. Mantener las redirecciones. La recomendación oficial de Google es mantenerlas «el mayor tiempo posible; lo ideal es al menos 1 año». La ayuda de Search Console pide como mínimo 180 días. Si una URL vieja todavía trae tráfico, la redirección se queda.
9. Monitorear los dos sitios. Google recomienda mirar el tráfico del sitio viejo y del nuevo, y los informes de cobertura e indexación, durante las semanas posteriores.

¿Cuánto tarda en recuperarse el tráfico después de un rediseño?

Semanas, no días, y la referencia es de Google, no nuestra: «un sitio web de tamaño mediano puede tardar algunas semanas en trasladar la mayoría de las páginas a nuestro índice; los sitios más grandes pueden tardar más», dice la documentación oficial de Search Central sobre traslados de sitio con cambio de URLs.

Si el rediseño no cambió las URLs, ese plazo prácticamente no existe: Google vuelve a rastrear las mismas direcciones y actualiza lo que cambió. Si además solo se movió el hosting, la propia documentación de Google avisa que «es normal ver una disminución temporal en la frecuencia de rastreo de Googlebot inmediatamente después de la publicación», seguida de un aumento sostenido en los días siguientes. Esa baja no es una penalización.

Lo que sí conviene tener claro de antemano es qué mirar y cuándo, para no tomar decisiones de pánico en la semana 2. Un rediseño se evalúa contra el mismo período del año anterior y contra los tres meses previos, nunca contra la semana anterior a la publicación.

Momento	Qué mirar	Qué es normal	Cuándo preocuparse
Día 1 a 3	Errores 404 y redirecciones en Search Console	Aparición de algunos 404 de URLs olvidadas	Decenas de 404 de páginas con tráfico: falta mapeo
Semana 1	Frecuencia de rastreo e indexación	Baja temporal del rastreo	Caída del rastreo que no se recupera en 7 días
Semana 2 a 4	Impresiones y posición media por página	Fluctuación de posiciones mientras reindexa	Páginas clave sin indexar después de 30 días
Mes 2 a 3	Clics y consultas generadas	Recuperación gradual hasta el nivel previo	Tráfico por debajo del 70% del período anterior
Mes 6	Comparación contra el año anterior	Nivel igual o superior al previo	Sigue por debajo: revisar mapeo y contenido borrado

¿Rediseño, ajuste o sitio nuevo: cuál te conviene?

Son tres caminos con costos, plazos y riesgos distintos, y la mayoría de los presupuestos cotizan el tercero cuando alcanzaba el primero. La regla práctica: si fallan una o dos señales de las seis, es ajuste; si fallan tres o cuatro, es rediseño; si además cambia el modelo de negocio o la tecnología está fuera de soporte, es sitio nuevo.

El ajuste es el camino que menos se ofrece y el que más veces corresponde. Optimizar imágenes, activar caché, limpiar plugins, rehacer la home y arreglar los formularios puede mover las Core Web Vitals y la conversión sin tocar ni una URL, o sea con riesgo SEO prácticamente nulo.

El sitio nuevo se justifica cuando la base ya no da: tecnología fuera de soporte, un tema comprado que nadie mantiene, o un cambio de modelo —de sitio institucional a tienda online, por ejemplo—. Ahí el costo de parchar supera al de construir, y además arrastrás las limitaciones viejas hacia adelante.

Sea cual sea el camino, pedí siempre dos cosas por escrito en la propuesta: el plan de redirecciones 301 y a nombre de quién quedan el dominio y el hosting. Si el proveedor no menciona las 301 en un proyecto que cambia URLs, todavía no pensó en tu posicionamiento.

Camino	Cuándo corresponde	Riesgo de perder posiciones	Qué toca
Ajuste sobre el sitio actual	Fallan 1 o 2 señales de las 6	Prácticamente nulo (no cambian URLs)	Velocidad, celular, formularios, textos de las páginas clave
Rediseño manteniendo URLs	Fallan 3 o 4 señales y la base técnica sirve	Bajo, si no se borra contenido que rankea	Diseño, estructura de páginas y contenido, con las mismas direcciones
Rediseño con nuevas URLs o dominio	Cambia la arquitectura o el dominio	Alto sin mapeo; controlado con 301 bien hechas	Diseño, estructura y contenido + mapeo, 301 y Search Console
Sitio nuevo desde cero	Tecnología fuera de soporte o cambia el modelo de negocio	Alto sin mapeo; controlado con 301 bien hechas	Plataforma, diseño, contenido y migración completa

PREGUNTAS FRECUENTES

Preguntas frecuentes

¿Cada cuánto hay que rediseñar una página web?

No existe un plazo oficial ni una recomendación de Google al respecto. El rediseño se decide por señales medibles, no por calendario: velocidad (Core Web Vitals), uso en celular, tecnología fuera de soporte, seguridad, conversión y alineación con lo que vendés hoy. Un sitio que aprueba las seis puede tener cinco años y no necesitar nada. Uno que falla en cuatro puede tener un año y necesitarlo ya.

¿Se pierde el posicionamiento en Google al rediseñar un sitio?

Solo si cambian las URLs y no se hacen redirecciones. La documentación oficial de Google Search Central afirma que con redirecciones permanentes 301 «no hay pérdida en PageRank», aunque advierte que es posible ver fluctuaciones de clasificación mientras Google vuelve a rastrear e indexar. Si el rediseño mantiene las mismas URLs, el riesgo mayor no es técnico: es borrar el contenido por el que la página ya rankeaba.

¿Cuánto tiempo hay que mantener las redirecciones 301?

Google Search Central recomienda mantenerlas «el mayor tiempo posible; lo ideal es al menos 1 año». La ayuda de Search Console fija un mínimo distinto para cambios de dominio: al menos 180 días, que es el período durante el cual la herramienta de cambio de dirección reenvía señales del sitio viejo al nuevo. En la práctica, si una URL vieja todavía recibe tráfico o tiene enlaces externos, la redirección se deja indefinidamente.

¿Qué diferencia hay entre una redirección 301 y una 302?

La 301 es permanente y la 302 es temporal. Según la documentación de Google sobre redirecciones, las permanentes (301 y 308) son la señal más fuerte y el sistema de indexación las toma como indicador de que la URL de destino debe ser la canónica. Las temporales (302, 303, 307) no se usan como indicador de canonicalización. Para un rediseño con cambio de URLs corresponde 301, siempre.

¿Cómo sé si mi sitio reprueba las Core Web Vitals?

Pegá la URL en PageSpeed Insights y mirá el bloque de datos de usuarios reales, no el puntaje simulado. Reprueba si el LCP supera 2,5 segundos, el INP supera 200 milisegundos o el CLS supera 0,1, medidos en el percentil 75 de las visitas (umbrales oficiales de web.dev, agosto de 2026). El informe de Core Web Vitals de Search Console muestra lo mismo para el sitio completo.

¿Rediseñar el sitio mejora el posicionamiento por sí solo?

No. Google es explícito en su documentación sobre experiencia de la página: no hay un indicador único, y «la Búsqueda de Google siempre intenta mostrar el contenido más relevante, incluso si la experiencia de página es deficiente». Un rediseño mejora la experiencia y puede mejorar la conversión, pero si el contenido no responde mejor la consulta que el de la competencia, las posiciones no se mueven por el diseño.

¿Cuándo NO conviene rediseñar la web?

Cuando el sitio no recibe visitas —el rediseño mejora la conversión del tráfico existente, no lo genera—; cuando la única razón es estética y las seis señales técnicas están bien; cuando no hay quién actualice el contenido después; y cuando el problema real es de definición del negocio y no de la página. En los cuatro casos, la misma plata puesta en captación o en contenido rinde más.

¿Hay que usar la herramienta de cambio de dirección de Search Console?

Solo si cambiás de dominio, por ejemplo de tuempresa.com.ar a tuempresa.com. Según la ayuda oficial de Search Console, no se usa para pasar de HTTP a HTTPS (Google lo detecta solo), ni para mover páginas dentro del mismo dominio, ni para el cambio entre www y sin www. Requiere tener verificadas las dos propiedades con la misma cuenta y reenvía señales durante 180 días.

¿Cuánto tarda un rediseño en recuperar el tráfico?

Si no cambian las URLs, prácticamente no hay caída que recuperar. Si cambian, Google indica que «un sitio web de tamaño mediano puede tardar algunas semanas en trasladar la mayoría de las páginas» a su índice, y los sitios grandes más. La evaluación honesta se hace a los 60 y 90 días, comparando contra el mismo período del año anterior, nunca contra la semana previa a publicar.

¿Conviene rediseñar o hacer un sitio nuevo desde cero?

Depende de si la base técnica sirve. Si el sitio corre sobre PHP fuera de soporte (toda versión anterior a 8.2, según php.net en agosto de 2026), usa Flash o depende de plugins abandonados hace años, parchar sale más caro que construir. Si la base está sana y el problema es la estructura y el contenido, un rediseño manteniendo las URLs conserva el posicionamiento y cuesta menos.

FUENTES CONSULTADAS

SEGUÍ LEYENDO

¿Por qué tu sitio carga lento?Las causas reales de la lentitud y qué se arregla sin rediseñar nada.Leer →¿Cuánto sale una página web en Argentina?El método para armar y comparar presupuestos de sitio web sin marearte.Leer →Mi sitio WordPress fue hackeado: qué hacerCómo limpiar, blindar y evitar rediseñar sobre una instalación comprometida.Leer →

Resumiendo: se rediseña cuando fallan al menos dos de seis señales medibles —Core Web Vitals fuera de umbral (LCP 2,5 s, INP 200 ms, CLS 0,1 en el percentil 75), mal funcionamiento en celular, tecnología fuera de soporte, falta de HTTPS o antecedentes de infección, tráfico que no convierte, y contenido desalineado con lo que vendés—, y no se rediseña cuando el sitio simplemente no tiene visitas. Si el rediseño va, lo que protege el posicionamiento no es el diseño: es el mapeo de URLs viejas a nuevas con redirecciones 301 hecho antes de publicar y mantenido al menos un año, como recomienda Google Search Central. Si querés que revisemos tu sitio con las seis señales y te digamos cuál de los cuatro caminos te corresponde, escribinos por WhatsApp al 11 2462-3183 o desde la página de contacto: si el diagnóstico es que no necesitás rediseñar nada, te lo decimos igual. Podés mirar cómo trabajamos el rediseño web y, si el diagnóstico termina en un sitio nuevo, cómo encaramos el diseño web desde cero.

Point Web — Nicaragua 5812, Palermo, CABA · WhatsApp 11 2462-3183 · proyectos@pointwebglobal.com