Migrar WordPress a desarrollo personalizado sin perder SEO

Cómo migrar un sitio web de WordPress a desarrollo personalizado sin perder tráfico SEO

Dejar WordPress no es solo un proyecto de diseño. Si el tráfico de búsqueda importa, la migración empieza por las páginas que ya generan clics, leads y enlaces. La frase “cómo migrar un sitio web de WordPress a desarrollo personalizado sin perder tráfico SEO” suena larga, pero el trabajo detrás es práctico: proteger lo que ya posiciona y luego reconstruir el sitio alrededor de esas páginas primero. Ese orden evita problemas más adelante, y es la base para migrar WordPress sin perder tráfico SEO.

Un error común es tratar todas las URLs como si valieran lo mismo. Un archivo del blog con 200 visitas al mes no merece la misma atención que una página de producto que atrae 2.000 visitas y una docena de backlinks. Elige las 10, 20 o 50 URLs que más importan y anótalas antes de que empiece cualquier cambio de código. Lista pequeña, gran impacto.

1. Mapea las páginas que realmente impulsan el tráfico de búsqueda

Empieza con tres fuentes: analítica, Search Console y tus datos de backlinks. Desde la analítica, identifica las páginas de destino con tráfico orgánico durante los últimos 12 meses. En Search Console, anota las consultas que generan impresiones y clics para esas URLs. En los datos de backlinks, marca las páginas con los enlaces externos más sólidos, porque una página con 5 buenos enlaces puede superar a 50 débiles.

No te fíes de la memoria. Una página que “parece” importante no siempre es la que más confianza inspira a los motores de búsqueda. A veces la página que casi borras es la que sostiene un grupo de consultas de long tail que, sin hacer ruido, apoya los ingresos. Eso pasa con suficiente frecuencia como para merecer una hoja de cálculo.

Haz una tabla sencilla con cuatro columnas: URL actual, tráfico orgánico, consultas principales y notas sobre su valor para el negocio. Si una página tiene valor estacional, marca el mes. Si una página alimenta la navegación interna, márcalo también. Luego ordena la lista. El nivel superior recibe el tratamiento de migración más cuidadoso.

2. Congela la base SEO actual antes de tocar el código

Antes de que un desarrollador cambie plantillas, exporta el estado SEO actual. Guarda capturas de rankings, el número de páginas indexadas, errores de rastreo, canonicals, metadatos, enlaces internos y las URLs del sitemap XML. Si puedes, rastrea el sitio WordPress con una herramienta que registre códigos de estado y títulos de página. Quieres una foto del antes, no un recuerdo difuso; por eso conviene preparar una guía migración WordPress a desarrollo personalizado SEO antes de mover una sola plantilla.

Captura los datos de Search Console del periodo más reciente. Si el sitio tiene un patrón diario de tráfico, usa el mismo día de la semana para comparar. De lunes a lunes es mejor que de lunes a sábado. Esa pequeña decisión evita falsas alarmas.

Guarda también una copia del archivo robots.txt y del índice actual del sitemap. Estos archivos parecen aburridos hasta que bloquean a los motores de búsqueda una sección que querías conservar. Una línea en robots.txt puede afectar a cientos de URLs. Un solo elemento faltante en el sitemap puede ocultar una sección entera durante semanas.

Si el sitio ya tiene etiquetas canonical, regístralas. Si tiene títulos duplicados, anota qué plantillas los generan. Estos detalles ayudan a distinguir entre daños de la migración y problemas antiguos que ya existían. Sin esa base, investigar después del lanzamiento se convierte en adivinar.

3. Diseña un plan de equivalencia de URLs para cada página importante

Ahora asigna cada URL importante de WordPress a una nueva URL personalizada. Mantén la relación uno a uno siempre que sea posible. Si la página antigua es /services/seo-audit/, la nueva no debería convertirse en /what-we-do/consulting/audit/ salvo que haya una razón de negocio sólida. Las correspondencias limpias reducen la complejidad de los redireccionamientos y facilitan la revisión de la migración.

Los casos especiales merecen líneas extra en el plan. Las páginas paginadas, archivos de categorías, vistas filtradas, páginas de etiquetas, archivos de autor y URLs de archivos multimedia pueden comportarse de forma distinta. Algunas deberían redirigirse a una página principal. Otras deberían seguir siendo indexables. Otras deberían eliminarse por completo de la búsqueda. Revisa cada una en lugar de suponer.

Aquí es donde una buena hoja de cálculo vale oro. Añade columnas para la URL antigua, la nueva URL, el código de estado, el tipo de redirección, el destino canonical y la decisión de indexabilidad. Luego asigna un responsable a cada decisión. Un desarrollador, un responsable SEO y un editor de contenido deberían poder leer el mismo archivo y saber qué ocurrirá el día del lanzamiento.

En sitios grandes, la equivalencia puede revelar sorpresas incómodas. Una página de etiquetas de WordPress puede posicionar por un tema útil, aunque nadie lo haya planeado. Un archivo multimedia puede seguir atrayendo visitas desde la búsqueda de imágenes. El plan de migración también debe incluir esas páginas, porque a los motores de búsqueda no les importará que la página fuera “solo un resto”.

4. Planifica redirecciones, canonicals y señales de indexación juntos

Las redirecciones por sí solas no bastan. Si una página redirige a una nueva URL pero la etiqueta canonical apunta a otro sitio, las señales se vuelven confusas. Si una página está bloqueada en robots.txt pero incluida en el sitemap, también es confuso. Los motores de búsqueda prefieren una historia clara. Dales una.

Define redirecciones 301 para cada URL antigua que necesite un nuevo destino. Evita las cadenas de redirección en el plan. Un salto está bien. Dos saltos son tolerables en caso de apuro. Tres saltos es cuando el tráfico y la eficiencia de rastreo empiezan a caer. Para una lista técnica más completa, consulta cómo configurar redirecciones 301.

Los canonicals deben apuntar a la versión preferida de cada página en el nuevo sitio. Si una página filtrada debe seguir siendo indexable, deja esa decisión explícita. Si una página con parámetros no debe indexarse, haz que la directiva robots y el canonical coincidan con esa intención. Las señales mezcladas desperdician presupuesto de rastreo y diluyen la relevancia de la página.

Los sitemaps XML deberían listar solo las URLs que deben indexarse y devolver respuestas 200. Quita las antiguas URLs de WordPress del sitemap en el lanzamiento, no una semana después. Un sitemap con URLs muertas es como un mapa con carreteras que terminan en una pared. Los robots de búsqueda se dan cuenta.

Una regla práctica ayuda: si la página importa, envíale una sola ruta clara. Redirige las URLs antiguas, aplica canonical a la URL final y publica esa URL final en el sitemap. Tres señales que coinciden ganan siempre a tres señales que se contradicen.

5. Conserva los elementos SEO on-page durante la recreación de plantillas

La recreación de plantillas es donde muchas migraciones pierden tracción. Un diseñador cambia la jerarquía de encabezados porque “se ve mejor”, o un desarrollador recorta las metadescripciones porque parecen invisibles. Los motores de búsqueda siguen leyendo esos elementos. Los usuarios también, de forma indirecta, a través de snippets y sitelinks.

Reconstruye los títulos para que sigan siendo específicos de cada página. Conserva las metadescripciones cuando todavía encajen con el contenido. Mantén una estructura clara de H2 o H3 por página en lugar de saltos aleatorios entre encabezados. Si la plantilla antigua de WordPress usaba un H1 descriptivo con H2 de apoyo, reproduce esa lógica en el desarrollo personalizado.

Los datos estructurados merecen el mismo cuidado. Si el sitio antiguo marcaba artículos, productos, migas de pan o FAQs, revisa qué tipos de schema siguen siendo relevantes en la nueva versión. No tener schema no siempre hunde rankings, pero eliminar un tipo de página válido puede reducir la elegibilidad para resultados enriquecidos. Ese es un coste real, aunque cueste medirlo.

El texto alternativo de las imágenes también importa. Si una página de WordPress tenía imágenes con nombre que generaban impresiones en la búsqueda de imágenes, conserva un alt descriptivo y concreto. No sustituyas “Reunión del equipo en Berlín” por “imagen1”. Ese cambio por sí solo puede borrar rápido la visibilidad en imágenes.

Los enlaces internos también forman parte del panorama on-page. Si una página de servicio de alto valor estaba enlazada desde la página de inicio, el footer y tres artículos relacionados, conserva esos enlaces donde tenga sentido. Una migración que olvida los enlaces internos suele perder relevancia incluso cuando el contenido se copia correctamente.

6. Gestiona los casos especiales de contenido y medios que WordPress oculta

WordPress oculta una cantidad sorprendente de elementos innecesarios. Las páginas de adjuntos son un ejemplo clásico. Pueden crear URLs poco útiles que los motores rastrean, indexan y luego ignoran. Las páginas de autor y las de etiquetas pueden hacer lo mismo. Si no son útiles, elimínalas de la indexación o consólidalas en páginas más fuertes.

Las URLs de medios necesitan un tratamiento cuidadoso. Un archivo de imagen puede haber ganado tráfico por sí solo, sobre todo si el sitio tiene años de contenido publicado. Comprueba si esas URLs de recursos deben seguir accesibles o redirigirse a la página que las usa. Si un archivo tiene enlaces entrantes, dejarlo romperse es una mala decisión.

El contenido huérfano es otra trampa. En WordPress, una página puede seguir viva en la base de datos mucho después de desaparecer de la navegación. Durante la migración, esa página puede olvidarse porque nadie la ve en el menú. Pero los motores de búsqueda aún pueden verla. Crea una exportación de contenido que incluya todas las URLs publicables, no solo las páginas que recuerdas de memoria.

En sitios editoriales grandes, el paso de limpieza también puede revelar publicaciones duplicadas o casi duplicadas. Algunas pueden merecer una consolidación. Otras pueden necesitar una etiqueta noindex. Toma la decisión en función del tráfico, los enlaces y la relevancia, no solo de la preferencia editorial. Los motores de búsqueda no son sentimentales.

Si necesitas más contexto sobre seguridad en esta etapa, seguridad web merece la pena revisarla antes del lanzamiento. Una migración no es el momento de dejar archivos antiguos, subidas expuestas o permisos débiles sueltos.

7. Valida el lanzamiento con QA centrado en los motores de búsqueda

La QA debe hacerse dos veces: en staging y después del lanzamiento. Rastrea el sitio de staging con las mismas reglas que piensas exponer públicamente. Revisa códigos de estado, canonicals, enlaces internos, metadatos y la salida del sitemap. Confirma que las antiguas URLs de WordPress devuelven la redirección 301 prevista y que la página de destino devuelve 200.

Busca bucles de redirección, protocolos mezclados y etiquetas noindex accidentales. Una página que debería posicionar pero tiene noindex no se recuperará por casualidad. Una página que redirige de HTTP a HTTPS y luego a otra ruta puede seguir funcionando para los usuarios, pero añade riesgo. Un solo redireccionamiento limpio es el objetivo.

Compara staging con la base que congelaste antes. ¿Cambió de forma significativa el número de URLs indexables? ¿La página de inicio perdió su canonical? ¿Los enlaces internos seguían apuntando a los slugs antiguos? Estas comprobaciones son tediosas. Pero salen mucho más baratas que una caída de tráfico.

Ayuda revisar la QA con un rastreador y con una persona. El rastreador detecta etiquetas que faltan. La persona detecta plantillas extrañas, títulos raros y orden de contenido roto. Un desarrollador puede pensar que una página está bien porque carga. A los motores de búsqueda les importa mucho más que simplemente cargar.

8. Supervisa las señales SEO tras el lanzamiento y corrige rápido las pérdidas

Después del lanzamiento, revisa Search Console a diario durante las primeras 2 a 4 semanas. Controla la cobertura de indexación, los errores de rastreo, los cambios de posicionamiento y el tráfico de las páginas de destino. Si una página que antes posicionaba desaparece de los resultados, revisa primero el destino de la redirección, el título, el canonical y los enlaces internos.

Algunas pérdidas son simples. Una página puede haberse redirigido al destino equivocado. Otras no. Una sección puede haberse devaluado porque demasiadas URLs antiguas apuntan a la página principal genérica en lugar de a un reemplazo relevante. Los motores de búsqueda prefieren la especificidad, no los atajos.

Las páginas de destino rotas merecen atención prioritaria porque pueden perder tráfico y conversiones a la vez. Si una página con backlinks sólidos empieza a devolver 404, restáurala o redirígela bien. Si la URL de una página cambió pero la dirección antigua aún posiciona, actualiza los enlaces internos para que el sitio deje de reforzar el camino incorrecto.

También conviene vigilar el comportamiento de rastreo. Si Googlebot dedica tiempo a URLs de poco valor, ajusta el sitemap y revisa las reglas de indexación. Si quieres una visión más amplia de los costes de medición después del lanzamiento, cuánto cuesta la analítica web ayuda a encuadrar el presupuesto de seguimiento. Para los equipos que quieren mantener el nuevo sitio en buen estado con el tiempo, cuánto cuesta el mantenimiento web es una lectura complementaria útil.

Un último hábito compensa: mantén un registro de cambios de cada redirección, ajuste canonical y actualización de plantilla después del lanzamiento. Si los rankings caen el día 9, querrás saber qué cambió el día 6. Ese registro convierte el pánico en diagnóstico y el diagnóstico en una solución en la que puedes confiar.