Rehacer la web o arreglar la que tienes: cómo decidirlo

«Está hecha con un constructor y va lenta» es de las razones que más se dan para rehacer, y la que más conviene mirar despacio: a veces es verdad y a veces es una factura evitable.

Lo que casi nunca justifica rehacer: imágenes de tres megas sin comprimir, un alojamiento compartido saturado, quince extensiones que hacen lo mismo o una caché mal configurada. Todo eso se arregla sobre la web actual y se nota en días. Acelerar un WordPress sin cambiar de tema es el camino barato, y hay que descartarlo antes de hablar de presupuestos grandes.

Lo que sí lo justifica: que la plantilla no sea adaptable de verdad, que el tema lleve años abandonado por su autor, que cada página cargue media biblioteca para pintar tres párrafos o que el gestor no se pueda actualizar sin romper algo. Ahí no se remienda, porque cada arreglo dura hasta la siguiente actualización.

La diferencia entre las dos listas es sencilla: lo primero son cosas que alguien fue poniendo encima y se pueden quitar; lo segundo son decisiones tomadas el día que se construyó la web. Lo que cuesta un constructor cuando se usa mal está en Elementor y el SEO. En un WordPress, las extensiones repetidas y la caché mal puesta de la primera lista se quitan sin rehacer nada: de eso me ocupo como consultor SEO para WordPress.

Arreglar no significa tocarlo todo a la vez. El orden sensato va de lo que más bloquea a lo que más se ve, y casi nunca coinciden:

1. Lo que pone la web en riesgo. Actualizar el gestor, retirar los plugins abandonados y activar HTTPS va antes que nada, porque cualquier otra mejora se pierde si la web cae o la infectan.
2. Lo que impide que Google la vea. Un noindex olvidado, un robots.txt cerrado o páginas clave fuera del índice. Para comprobarlo página a página, sigue los pasos de cómo saber si Google tiene indexada tu web.
3. Lo que echa a quien ya ha llegado. El teléfono que no se puede pulsar, el formulario que no envía o una carga eterna en el móvil. Si lo que falla es la velocidad, el artículo sobre Core Web Vitals separa las métricas que importan de las que no.
4. Lo que dice cada página. Títulos genéricos, servicios sin página propia y dos páginas peleando por la misma búsqueda. Esto último se llama canibalización y se corrige sin rehacer nada.

Si no tienes claro en cuál de los cuatro puntos está tu web, para eso sirve un diagnóstico. Antes de pagar uno, repasa qué debe incluir una auditoría SEO para recibir eso y no una lista de avisos.

Rehacer una web es donde se pierde dinero de verdad, y casi siempre por lo mismo: auditar después en lugar de antes. Google, en su página sobre cuándo te conviene un SEO, pone el momento en el mismo sitio: «un buen momento para contratar estos servicios es cuando vayas a cambiar el diseño de tu sitio web (cuanto antes, mejor)».

En septiembre de 2026 pasé una web mía de consultoría técnica de WordPress a un sitio estático; el cambio se hizo el día 3. Antes de escribir las redirecciones, un metadato del propio sitio decía que los artículos vivían en /blog/nombre-del-articulo/. Lo comprobé sobre la web publicada con curl, una herramienta que pide cada página directamente al servidor: vivían en la raíz, en /nombre-del-articulo/. Una auditoría que se había fiado de ese metadato contaba 156 «enlaces rotos» que no lo estaban. Con la ruta ya medida, escribí una redirección 301 para cada uno de los 50 artículos. WordPress no lo borré: lo saqué de la carpeta pública, con la base de datos volcada y una nota para volver atrás si hacía falta.

La lección que me quedo cabe en una línea: antes de redirigir, mide dónde vive cada dirección. Un metadato no es una medición.

Es la pregunta que nadie hace y que decide media partida, porque una web nueva no se hace en un fin de semana: son semanas o meses en los que la actual sigue siendo la que recibe a tus clientes.

La web actual sigue viva y se sigue tocando. Congelarla «porque va a cambiar» es regalar esos meses. Si hay un título malo o falta una página de servicio, se arregla ahora y se hereda después: el contenido viaja al sitio nuevo, el diseño no.

La web en construcción no puede indexarse. Es el accidente más común de todos, y deja a Google con dos copias del mismo sitio compitiendo entre ellas. Se evita con una casilla y se paga caro cuando se olvida: staging indexado.

El día del cambio no es el final, es el principio de la vigilancia. Las dos semanas siguientes valen más que los dos meses anteriores, y conviene tener a alguien mirando: cómo preparar el lanzamiento de una web nueva.

Conviene reconocer el guion, porque se repite con pocas variaciones.

Empieza por «tu web está anticuada», que es una opinión estética y no un diagnóstico. Sigue con «Google penaliza las webs viejas», que es falso: Google penaliza las webs que no responden o que no se pueden rastrear, tengan la edad que tengan. Y termina con «con la web nueva posicionarás mejor», que solo es verdad si de paso se arregla lo que de verdad fallaba, y eso se podía haber arreglado sin rehacer.

Nada de esto implica mala fe. A menudo quien lo propone hace webs y no SEO, y ofrece lo que sabe hacer. Pero es tu dinero, y la pregunta que desmonta el guion es sencilla: ¿cuál de las cinco preguntas de arriba justifica rehacer en mi caso?

Aunque la decisión sea rehacer, hay cuatro cosas que viajan intactas o la web nueva empieza con desventaja.

Las direcciones que reciben visitas, o su redirección exacta. Los textos que posicionan, aunque no gusten. Los enlaces que otras webs te han puesto, que apuntan a direcciones concretas y se pierden si esas direcciones mueren. Y los datos de contacto tal cual están en la ficha de Google, para que no dejen de coincidir.

Todo lo demás —⁠diseño, estructura del menú, fotos, colores⁠— se puede cambiar sin miedo.

Entre arreglar y rehacer hay una opción intermedia que resuelve la mayoría de los casos: rediseñar sin migrar.

Se cambia el aspecto —⁠plantilla, colores, tipografía, disposición⁠— manteniendo las mismas direcciones y el mismo contenido. No hay redirecciones que hacer, no hay nada que se pierda, y la web se ve nueva.

Es más barato que una web nueva, no tiene riesgo de caída y, si después hace falta cambiar la estructura, se hace con calma y con datos. Lo que no permite es arreglar un gestor inseguro o una arquitectura que no deja crecer: para eso sí hay que rehacer. En ese caso, las direcciones y lo que se indexa se deciden al construir la web nueva, y es lo que cuido cuando hago una web a medida.

Sea cual sea la decisión, conviene poder contestarlo con datos y no con sensaciones. Para eso hay que guardar el punto de partida antes de tocar nada: clics, impresiones y posiciones de los últimos doce meses, y la lista de las páginas que traían visitas.

Después, lo que se compara no es el total del sitio: es página a página. El total sube y baja por la marca, por la temporada y por tus propias visitas, así que sirve para discutir pero no para decidir. Lo que dice la verdad es si las diez direcciones que traían clientes siguen trayéndolos, y si las que perdieron tienen algo en común.

Y un plazo para no asustarse ni relajarse: tras un cambio de web es normal que las primeras semanas se muevan. La guía de Google para traslados de sitio, tal como estaba en septiembre de 2026, lo dice así: el posicionamiento «puede fluctuar mientras Google lo rastrea y lo indexa de nuevo», y en una web mediana puede tardar «varias semanas o más» en empezar a enseñar las direcciones nuevas en lugar de las antiguas. Lo que importa es la tendencia del segundo mes, no la del primero. Si a las cuatro semanas la caída sigue creciendo, eso ya no es el ajuste: es algo roto, y se busca por orden en qué hago si mi web pierde visitas de golpe.

Si dudas, arregla. Es más barato, es reversible y en dos meses sabrás si el problema era ese. Rehacer siempre estará disponible después, y llegarás con mucha más información sobre qué necesitas de verdad.

Y si tras arreglar sigue haciendo falta rehacer, habrás llegado con la web auditada, el listado de URLs guardado y el mapa de lo que posiciona hecho. Que es exactamente lo que hace que una migración salga bien.