Inventario técnico
URL, código de respuesta, indexabilidad, canonical, hreflang, plantilla, enlaces entrantes internos y presencia en sitemap.
Planificación y control de migraciones
Servicios de migración SEO
Convierta el cambio de plataforma, dominio o arquitectura en un plan por URL, con responsables, controles de lanzamiento y criterios de respuesta si algo falla.
Decisiones antes del despliegue
La tabla de URLs convierte el lanzamiento en trabajo verificable
Un mismo cambio puede dejar la redirección en una URL, la etiqueta canonical en otra y el enlace interno en la antigua. El nuevo sitio también puede omitir páginas con demanda o conservar el bloqueo que protegía staging. Cada error afecta a un conjunto distinto de URLs y requiere otro responsable.
El trabajo asigna a cada URL una decisión antes de publicar. El inventario conserva el punto de partida, el mapa registra qué ocurre con cada recurso y el plan de lanzamiento distribuye los controles entre SEO, desarrollo, contenido y analítica. Si las señales cambian después, el equipo puede distinguir una fluctuación esperable de un defecto que necesita intervención.
Inventario y línea base
El sitio anterior debe quedar documentado antes de cambiarlo
El rastreo de producción aporta URLs, estados HTTP, etiquetas canonical, directivas de robots, hreflang, datos estructurados y enlaces internos. Se combina con sitemaps, Search Console, analítica y registros del servidor porque ninguna fuente contiene el inventario completo. Google recomienda empezar por las URLs importantes y también incluir imágenes, vídeos y otros recursos que puedan recibir enlaces o tráfico.
La línea base guarda las consultas, páginas de entrada y conversiones disponibles, junto con las plantillas que las producen. Su función no es fijar una cifra que el nuevo sitio deba replicar cada día. Sirve para comparar grupos equivalentes y localizar dónde apareció una diferencia.
Registro previo
Una referencia independiente de la plataforma
Demanda orgánica
Consultas, clics, impresiones y páginas de entrada dentro de un periodo que considere estacionalidad y cambios anteriores.
Funciones del negocio
Plantillas, formularios, seguimiento, navegación, búsqueda interna y recorridos que deben continuar después del despliegue.
Dependencias externas
Feeds, campañas, perfiles, enlaces de alto uso y archivos que todavía apuntan a rutas antiguas.
Mapa de URLs
Cada página antigua necesita una decisión explícita
La correspondencia se define por contenido e intención, no por la similitud del slug. Una categoría antigua puede conservarse, fusionarse con otra, recibir una URL nueva o retirarse sin sustituto. Esa decisión precede a la regla de redirección.
Conservar
La URL y el propósito continúan. Se comprueba que el contenido, los metadatos y los enlaces necesarios aparezcan en la nueva plantilla.
Mover
La URL cambia y mantiene un equivalente. El mapa asigna un destino final único y una redirección permanente del servidor.
Consolidar
Varias páginas se consolidan en un destino que cubre sus intenciones. La revisión confirma que esa página contiene la información que justifica cada redirección.
Retirar
El contenido deja de existir y no tiene reemplazo. Un 404 o 410 puede describir mejor esa decisión que enviar a la persona a una página sin relación.
Redirecciones hacia el destino final
Google recomienda 301 o 308 del lado del servidor para movimientos permanentes. También aconseja evitar cadenas y dirigir la URL antigua al destino definitivo. Las redirecciones temporales cumplen otra función, ya que indican que la URL de origen puede seguir siendo la que aparezca en búsqueda.
Paridad entre staging y producción
Una página parecida puede enviar señales técnicas diferentes
La comparación se hace por plantilla y con una muestra de URLs reales. El HTML renderizado, los encabezados y los códigos de respuesta importan tanto como la presentación. Un staging protegido puede esconder reglas que pasan inadvertidas hasta publicar.
Rastreo e indexación
Se preparan robots.txt y meta robots para producción, con una lista concreta de bloqueos temporales que deben retirarse durante el lanzamiento.
Canonical y hreflang
Cada página indexable apunta a la URL pública que corresponde. Los conjuntos de idioma usan las rutas nuevas y conservan reciprocidad.
Enlaces y navegación
Menús, migas de pan, listados, contenido y componentes dejan de enlazar rutas antiguas. La redirección queda como respaldo, no como arquitectura interna.
Contenido y marcado
Títulos, texto visible, imágenes y datos estructurados se comparan con producción para encontrar campos perdidos o valores genéricos.
Estados HTTP
Las páginas válidas devuelven 200, los movimientos siguen el mapa y las rutas inexistentes responden con un error real en lugar de una portada con 200.
Medición y funciones
El seguimiento conserva definiciones, consentimiento y eventos. Formularios, filtros, paginación y búsqueda interna se prueban junto con SEO.
Google considera las redirecciones y la etiqueta canonical señales fuertes, mientras que la inclusión en sitemap es una señal más débil. Las señales contradictorias dejan la selección final en manos de sus sistemas. Consultar la documentación de canonicalización.
Secuencia de lanzamiento
El orden de los controles limita las variables abiertas
Google aconseja cambiar una cosa a la vez cuando sea viable. Combinar dominio, CMS, arquitectura y rediseño en el mismo instante aumenta lo que debe diagnosticarse. Para sitios grandes, una sección estable puede servir como prueba, aunque nunca representa todos los riesgos del resto del inventario.
1
Cierre de cambios
El mapa, las reglas, las plantillas y el procedimiento de rollback se cierran con responsables antes de decidir si el lanzamiento avanza.
2
Despliegue coordinado
Se publica el sitio y se activan las redirecciones dentro de la ventana acordada, con ingeniería disponible para corregir errores críticos.
3
Controles inmediatos
La muestra prioritaria valida estados HTTP, destinos, robots, canonical, hreflang, renderizado, enlaces y medición.
4
Descubrimiento
Se publica el sitemap con URLs canónicas nuevas y se revisa su procesamiento. En un cambio de dominio elegible se utiliza Cambio de dirección.
5
Traspaso operativo
Los hallazgos, decisiones y tareas pendientes quedan en un registro común para SEO, contenido, desarrollo y analítica.
Google recomienda mantener las redirecciones todo el tiempo posible y, por lo general, al menos 1 año. Los enlaces internos y los enlaces externos de alto uso se actualizan para que no dependan permanentemente de ese salto.
Cambio de dirección
La herramienta tiene un alcance específico
Search Console la reserva para movimientos entre dominios o subdominios y exige propiedad verificada en ambos lados. Se usa después de mover y redirigir. Un cambio de rutas dentro del mismo dominio, un traslado de HTTP a HTTPS o un nuevo hosting con las mismas URLs siguen otros procedimientos.
Sitemap nuevo
Enviar el archivo no garantiza el rastreo
El sitemap contiene las URLs canónicas que deben descubrirse. Google lo describe como una pista, no como garantía de descarga, rastreo o indexación. Search Console permite comprobar cuándo fue leído y si hubo errores de procesamiento.
Observación y rollback
La respuesta depende de la causa, la escala y el responsable
Google anticipa fluctuaciones mientras procesa un cambio importante y aclara que no hay una frecuencia fija de rastreo. Por eso una caída diaria no activa por sí misma un rollback. Un bloqueo de rastreo, redirecciones rotas a gran escala, páginas críticas inaccesibles o medición inutilizable describen otra clase de incidente.
Registros del servidor
Errores 5xx, 404 inesperados, actividad de Googlebot y rutas con demanda muestran si el problema comienza antes de la indexación.
Search Console
Sitemaps, páginas indexadas, inspecciones y rendimiento se comparan entre propiedades y grupos de URLs, sin esperar una curva uniforme.
Analítica y negocio
Páginas de entrada, eventos, formularios y conversiones ayudan a separar una falla de seguimiento de un cambio en el comportamiento orgánico.
Muestras técnicas repetibles
El mismo conjunto de URLs se prueba después de cada corrección. Así se confirma el cambio antes de cerrar el incidente.
Corregir en producción
Problemas acotados con una solución conocida
Una regla de robots incorrecta en una plantilla, un sitemap desactualizado o un grupo de redirecciones mal generado puede repararse sin revertir el sitio completo. La decisión exige impacto localizado, causa confirmada y una comprobación posterior.
Revertir el despliegue
Fallas críticas con un retorno técnicamente seguro
El rollback se reserva para condiciones definidas antes del lanzamiento. También debe contemplar datos creados después del despliegue, cambios de DNS, cachés y reglas de redirección. Volver sin esa preparación puede añadir otra migración encima de la primera.
Propiedad del trabajo
Cada control necesita una persona que pueda actuar
Si una fila del plan carece de responsable, el equipo sabe que existe el riesgo pero nadie puede cerrar el control. Por eso cada decisión que puede bloquear el lanzamiento recibe una persona responsable, una fecha y una prueba de aceptación.
Producto y contenido
Deciden qué páginas se conservan, consolidan o retiran, y aprueban la equivalencia editorial de los destinos.
Desarrollo y plataforma
Implementan códigos HTTP, redirecciones, renderizado, plantillas, capacidad del servidor y procedimiento de rollback.
SEO
Construye la línea base, revisa el mapa, define muestras de QA y convierte las señales posteriores en incidencias comprobables.
Analítica
Confirma que la medición mantiene definiciones y que cualquier diferencia procede del sitio, no de una etiqueta ausente.
Responsable del lanzamiento
Reúne los estados, decide si el despliegue avanza y activa la ruta de escalamiento cuando aparece una condición acordada.
Francisco
Dirige la revisión SEO, cuestiona las correspondencias débiles y entrega criterios que el equipo puede comprobar antes y después de publicar.
Buen encaje
Migraciones que necesitan revisión antes de publicar
- Cambio de CMS, plataforma de ecommerce o arquitectura headless.
- Cambio de dominio, subdominio, protocolo o estructura de URLs.
- Rediseño que modifica navegación, contenido o plantillas indexables.
- Consolidación de sitios, mercados, catálogos o idiomas.
- Lanzamiento ya realizado con errores técnicos que todavía pueden reproducirse.
Límites
Resultados que el servicio no promete
El alcance no garantiza tráfico, posiciones ni una fecha de recuperación. Google vuelve a rastrear y procesa cada URL según sus propios sistemas, mientras la demanda, los competidores y el contenido también pueden cambiar durante el proyecto.
Una mejora del diseño tampoco se atribuye por adelantado a SEO. Primero se conserva la capacidad de comparar, luego se observa el resultado y se investiga cualquier diferencia antes de declarar éxito o fracaso.
Preguntas frecuentes
Decisiones habituales antes de definir el alcance
¿Una migración SEO puede garantizar que no habrá pérdida de tráfico?
No. Google advierte que un cambio importante puede producir fluctuaciones mientras vuelve a rastrear e indexar las URLs. El trabajo reduce errores evitables, conserva las señales que pueden trasladarse y permite responder con evidencia, pero no controla la velocidad de procesamiento ni las posiciones.
¿Todas las URLs antiguas deben redirigirse a la página de inicio?
No. Cada URL que se retira debe apuntar a un destino equivalente cuando exista. Una página sin reemplazo puede responder con 404 o 410. Enviar muchas URLs diferentes a la página de inicio oculta decisiones de contenido y ofrece un destino poco útil.
¿Qué tipo de redirección corresponde a un cambio permanente?
Google recomienda redirecciones permanentes del lado del servidor, como 301 o 308, siempre que sea posible. El mapa debe enviar cada URL antigua directamente a su destino final y evitar cadenas innecesarias.
¿Cuándo se utiliza Cambio de dirección en Search Console?
La herramienta se utiliza después de mover y redirigir un sitio de un dominio o subdominio a otro. No corresponde a cambios de rutas dentro del mismo sitio, movimientos de HTTP a HTTPS ni cambios de hosting sin una URL visible nueva.
¿Cuánto tarda una migración en estabilizarse?
No existe un plazo fijo. Google procesa el cambio por URL y la velocidad depende, entre otros factores, de la cantidad de URLs y de la capacidad del servidor. El seguimiento se acuerda según el tamaño del sitio y continúa mientras haya decisiones abiertas.
¿Qué debe estar listo antes del lanzamiento?
Como mínimo, el inventario y mapa de URLs, las reglas de redirección, la comparación entre producción y staging, las señales canónicas y hreflang, los enlaces internos, el sitemap, la medición, los responsables y un procedimiento de rollback probado.
¿Hay una migración en el calendario o un lanzamiento que necesita diagnóstico?
La consulta permite revisar el alcance, el inventario disponible, los responsables y la decisión que debe cerrarse antes del siguiente cambio.