Cómo rehacer una web de WordPress sin perder el SEO

Rehacer una web merece la pena cuando la actual es lenta, insegura o demasiado difícil de cambiar. Es un riesgo de búsqueda cuando el proyecto se trata como un refresco visual y las URLs se dejan para la semana del lanzamiento. Esta es la secuencia que usamos, y el punto en el que le decimos a un cliente que se quede en WordPress.

Por qué las empresas se van de WordPress

WordPress es un CMS capaz. Los equipos se quedan pequeños para una instalación concreta, que no es lo mismo.

Las razones habituales son prácticas:

• El maquetador y los plugins se han vuelto más lentos de lo que el negocio acepta, sobre todo en móvil.
• Las actualizaciones dan miedo porque nadie sabe de qué plugin depende el sitio.
• Quien edita no puede cambiar las páginas que importan sin romper el diseño.
• El sitio necesita varios idiomas y el plugin multidioma pelea con el tema.
• Un formulario, un feed de empleo o un portal necesita lógica de aplicación que los plugins solo aproximan.

Son buenas razones para cambiar de plataforma. “WordPress está pasado de moda” no lo es.

Cuándo merece la pena migrar, y cuándo no

Un rediseño que además reescribe todas las URLs, borra la mitad del contenido y se lanza un viernes es la versión que pierde tráfico. Separa “hacerlo rápido y editable” de “cambiar lo que dice la empresa” si no puedes hacer las dos cosas con cuidado.

Elegir la tecnología

Elige la base según quién va a editar el sitio dentro de un año.

• Next.js, u otro framework parecido, con una capa de contenido pequeña. Encaja cuando importan el rendimiento, las plantillas a medida y las integraciones, y sigue habiendo alguien técnico. El contenido puede vivir en MDX, en un flujo con git o en un CMS headless como Sanity. Es lo que usamos en la reconstrucción de AAMC Abogados desde WordPress, y en Aston Education, que necesitaba ofertas desde la API de un sistema de selección.
• Una instalación de WordPress más tranquila. Encaja cuando un equipo no técnico tiene que publicar a menudo y el dolor es el tema, no WordPress. Menos plugins, un tema moderno, un hosting decente.
• Otro CMS que el equipo ya conozca. La familiaridad es una virtud si mantiene las páginas actualizadas.

Next.js es nuestra base habitual para sitios nuevos a medida porque las páginas pueden servirse como HTML, el despliegue es simple y las funciones de aplicación pueden vivir en el mismo código. No es la opción correcta para todas las organizaciones. Dilo en la propuesta.

Audita el sitio actual antes de diseñar el nuevo

Exporta pruebas, no opiniones.

• Rastrear el sitio en vivo y el sitemap XML. Guarda código de estado, indexabilidad, canónica, título, meta description, H1 y extensión.
• En Google Search Console, exporta páginas y consultas que ya reciben impresiones. Esas URLs son las que un plan de redirecciones no puede adivinar.
• Haz lo mismo en Bing Webmaster Tools si Bing importa en ese mercado.
• Lista enlaces entrantes a URLs concretas, aunque sea una lista aproximada del informe de enlaces de Search Console. Una URL con enlaces externos necesita un destino concreto.
• Anota los tipos de contenido: entradas, landings, sedes, autores, PDF, URLs de campaña, variantes con parámetros.
• Registra los tipos de datos estructurados y si coinciden con la página visible.
• Lista integraciones: formularios, CRM, reservas, empleo, analítica, consentimiento, búsqueda.

Acuerda qué se conserva, se fusiona, se reescribe o se retira. Retirar no significa “redirigir a la home”. Significa un destino pensado, o un 404 de verdad para URLs que nunca debieron indexarse.

Conserva la intención de búsqueda, no solo el texto

Si una página posiciona porque responde una pregunta concreta, la página nueva tiene que responder esa pregunta al menos con la misma claridad. Una página más corta y más bonita que ya no explica el servicio no va a “heredar” el rendimiento antiguo solo porque la redirección esté puesta.

Para cada URL que piensas conservar, anota:

• Los temas de consulta que ya se gana.
• La promesa del título y del H1 actuales.
• Qué tiene que seguir siendo cierto en la página nueva.
• Qué estás cambiando a propósito, para que una caída de tráfico no sea una sorpresa.

Fusionar dos artículos que se pisan suele ser lo correcto. Se hace eligiendo la URL más fuerte como destino, juntando las partes útiles y redirigiendo la otra URL allí. Di que las has fusionado. No dejes las dos publicadas con el mismo texto.

Mapea las URLs antiguas a las nuevas

Un mapeo es una hoja con una fila por URL antigua.

Reglas que evitan los errores de siempre:

• Un solo salto. De la URL antigua a la final, no de la antigua a una intermedia y luego a la nueva.
• HTTPS y el host correcto, incluida la decisión de www, forman parte del mapa.
• Las reglas de minúsculas y de barra final son coherentes, y las otras variantes redirigen una vez.
• Las URLs con parámetros usadas en anuncios se conservan o tienen su propia fila.
• La paginación, los feeds y las páginas de adjuntos son decisiones explícitas, no restos.

La guía de Google sobre cambios de sitio con cambio de URL es la referencia de esta fase. Léela antes de escribir las reglas de redirección.

Redirecciones permanentes

Usa un 301 o un 308 de servidor cuando el traslado es permanente. La documentación de redirecciones de Google trata esos códigos como una señal de que el destino debe ser canónico. Un 302 es para un traslado temporal y le dice a Google que siga teniendo en cuenta la URL antigua.

No uses una redirección de JavaScript ni un meta refresh como plan. Son recursos de último recurso cuando el servidor no puede redirigir.

Evita:

• Cadenas de redirección que quedaron de un rediseño anterior.
• Un comodín que envía las URLs desconocidas a la home.
• Redirigir un servicio eliminado a otro servicio que no tiene que ver porque “conserva el link juice”. Quien visita, y a menudo Google, habría estado mejor con una página relevante o con un 404 honesto.

Prueba el mapa con un rastreador contra el sitio de pruebas y otra vez en producción la hora del lanzamiento. Comprueba una muestra de las URLs que tienen impresiones, no solo la home.

Si cambia el propio dominio, usa la herramienta Cambio de dirección de Search Console después de que las redirecciones funcionen. Un rediseño en el mismo dominio no necesita esa herramienta.

Títulos, metadatos y canónicas

Lleva el significado y después mejóralo. La mañana del lanzamiento es un mal momento para renombrar todos los títulos por un tono nuevo.

• Cada URL nueva indexable tiene un título y una meta description únicos.
• La canónica de la página nueva apunta a sí misma, en la URL nueva, no a la URL antigua de WordPress.
• El noindex usado para esconder el sitio de pruebas se quita en producción. Es la forma más habitual de lanzar un sitio invisible.
• El hreflang, si hay varios idiomas, referencia las URLs nuevas en cada idioma. Una entrada que sigue apuntando a WordPress crea un bucle de confusión.
• Los títulos e imágenes Open Graph coinciden con las páginas nuevas para que al compartir no salga la marca antigua.

El entorno de pruebas debe estar cerrado por autenticación o por una regla de host, no por un noindex que alguien copie a producción.

Datos estructurados

Vuelve a implementar solo los tipos que coinciden con las plantillas nuevas. Un plugin SEO de WordPress suele emitir varios tipos en cada página, incluidos algunos que el diseño ya no sostiene.

Conserva el marcado de organización, migas, artículo y servicio cuando la página muestra esas cosas. Quita el marcado de reseñas salvo que las reseñas sean visibles y reales. Valida las plantillas, no cada URL a mano, y después comprueba una página de cada tipo en la prueba de resultados enriquecidos y en Search Console tras el lanzamiento.

El marcado no conserva posiciones. Un marcado incorrecto puede dejarte fuera de los resultados enriquecidos. La guía de búsqueda con IA explica ese límite con más detalle.

Enlaces internos

Las redirecciones arreglan los enlaces externos y los internos antiguos. Las plantillas nuevas no deberían depender de eso.

• La navegación, el pie, los enlaces relacionados y los enlaces dentro del texto apuntan directamente a las URLs nuevas.
• Las anclas describen el destino. “Haz clic aquí” sobrevive a una migración y sigue siendo un mal enlace.
• Los mapas HTML o las páginas hub, si los tienes, se regeneran.
• El sitemap XML lista solo URLs canónicas que responden 200. No lista las rutas antiguas ni las URLs redirigidas.

Rastrea el sitio nuevo y busca enlaces que aún contengan /wp-content, ?p= o la estructura antigua de enlaces permanentes. Eso está sin terminar.

Idiomas

Una web multidioma en WordPress suele codificar el idioma en un subdirectorio (/es/), un subdominio o un parámetro del plugin. Elige un patrón para el sitio nuevo y mapea cada URL de idioma.

• Traduce de verdad. Una URL en español con el cuerpo en inglés no debe presentarse como página en español.
• Da a cada idioma su propia canónica.
• Confirma que el hreflang es recíproco.
• No redirijas todos los idiomas al inglés porque la traducción es “la fase dos”. Si la página en español no está lista, no anuncies su URL.

En MRS Climatización la reconstrucción incluyó castellano, catalán e inglés, porque el público usa los tres. La web de la consultoría que estás leyendo está solo en inglés y castellano. El conjunto correcto es una decisión de contenido, tomada antes de congelar el mapa de URLs.

Rendimiento

Una migración es el momento más barato para arreglar lo que WordPress había acumulado.

• Sirve las páginas como HTML. No reconstruyas el sitio como una aplicación renderizada solo en el cliente y lo llames más rápido.
• Redimensiona y comprime las imágenes. No subas el hero original de 4000 píxeles del tema.
• Carga menos fuentes, con una alternativa sensata.
• Controla los scripts de terceros: un gestor de etiquetas, un modo de consentimiento que coincida con el banner de cookies, y ningún widget de chat en todas las plantillas salvo que alguien lo haya pedido.
• Mide LCP, INP y el desplazamiento de diseño en las plantillas, en un teléfono, antes del lanzamiento.

Los Core Web Vitals no son el plan de migración. Son una de las cosas que la plataforma nueva debería hacer más fáciles. La documentación de Google sobre cambios de sitio sigue siendo el documento que protege las URLs.

Prueba antes de cambiar el DNS o de publicar

En un host de pruebas que los buscadores no puedan indexar:

• Rastrea cada URL del mapa y compara los códigos de estado con la hoja.
• Comprueba canónicas, títulos, meta robots y hreflang en una URL de cada plantilla.
• Envía un formulario de prueba, un pago de prueba si lo hay, y una prueba de cada integración.
• Comprueba que la página 404 devuelve un 404 de verdad.
• Comprueba analítica y consentimiento en pruebas con un filtro, para que los datos de producción sigan limpios.
• Lee el sitio en un teléfono. Pulsa la acción principal.

Después lanza en una ventana en la que haya alguien que pueda volver atrás.

Después del lanzamiento

Espera movimiento. Busca el daño que has causado y no “optimices” al azar en las dos primeras semanas.

• Mira el informe de indexación de páginas y las estadísticas de rastreo. Un pico de 404 o una caída de páginas rastreadas es un fallo del mapa hasta que se demuestre lo contrario.
• Inspecciona las URLs que antes tenían impresiones. Confirma que Google ve el 301 y después la canónica nueva.
• Deja el sitemap antiguo disponible solo si ayuda, durante un periodo corto, a descubrir las redirecciones. El sitemap que envías debe ser el nuevo.
• Deja las redirecciones puestas. Un año es el mínimo del que se habla en los cambios de sitio. Muchas deberían quedarse de forma indefinida.
• Anota la fecha de lanzamiento en analítica para que una comparación posterior tenga una marca.
• Vuelve a mirar la lista de preguntas manuales y lo básico de búsqueda con IA solo cuando el índice se haya puesto al día. La semana de una migración es una mala semana para juzgar citas.

Si caen las posiciones en URLs cuyo contenido y cuya intención no cambiaron, y las redirecciones están limpias, espera al nuevo rastreo antes de reescribir otra vez. Si caen porque borraste la respuesta, devuelve la respuesta.

Errores que vemos en reconstrucciones que salen mal

• Diseñar la arquitectura nueva sin una exportación de Search Console.
• Cambiar los enlaces permanentes por estilo (/nuestros-servicios/ a /lo-que-hacemos/soluciones/) sin un motivo que notaría quien visita.
• Lanzar el sitio nuevo con el noindex de pruebas todavía puesto.
• Apuntar las canónicas al dominio antiguo.
• Redirigir el archivo del blog a la home y asumir que las entradas “se arreglarán solas”.
• Traducir la navegación y no los metadatos.
• Medir el éxito como “la home sigue posicionando por la marca”. Las consultas de marca son lo último que se pierde. Las que no son de marca son las que pagan el proyecto.

Lista de la migración

• Rastrea y exporta URLs, indexabilidad, títulos, canónicas y H1.
• Exporta páginas y consultas de Search Console. Anota las URLs con enlaces externos.
• Decide conservar, fusionar, reescribir o retirar cada URL con impresiones o enlaces.
• Elige la tecnología para los editores que de verdad tienes, no la de un informe de tendencias.
• Escribe un mapa de 301 de un solo salto, con host, protocolo, barra y archivos.
• Reconstruye el contenido para que las páginas que sobreviven sigan cubriendo la intención antigua.
• Implementa títulos únicos, descriptions y canónicas que apunten a sí mismas.
• Reconstruye los datos estructurados desde las plantillas nuevas. Quita lo que la página no muestra.
• Apunta los enlaces internos a las URLs finales.
• Mapea cada idioma. Añade hreflang solo para páginas que existen.
• Prueba redirecciones, formularios, integraciones y directivas de indexación en un sitio de pruebas no indexable.
• Quita el noindex de pruebas en producción. Envía el sitemap nuevo.
• Vigila la indexación y las URLs que ya traían visitas. Conserva las redirecciones.

AAMC Abogados es el ejemplo público de una web de WordPress reconstruida sobre una base moderna, con la arquitectura de la información y los cimientos de búsqueda rediseñados juntos. No publicamos un delta de posiciones de ese proyecto porque no vamos a poner en esta página un número que el caso no sostiene.

El servicio detrás de este trabajo es reconstrucción de webs y migración de plataforma. Si el sitio nuevo también tiene que ser entendible para los motores de respuesta, eso es SEO y búsqueda con IA, hecho en las plantillas nuevas y no añadido después.

Fuentes

• Cambios de sitio con cambio de URL, Google Search Central.
• Redirecciones y Google Search, Google Search Central.
• Cambio de dirección, ayuda de Search Console, solo para cambios de dominio.
• Directrices para webmasters de Bing, para indexación, canónicas y controles de grounding.

Estas páginas eran la referencia en noviembre de 2026. Usa el documento en vivo si un detalle se ha movido.