Cambiar de proveedor de web sin perder posiciones en Google

Diagnóstico inicial y objetivos

Cuando un cliente me dice que quiere cambiar de proveedor web, lo primero que hago es un diagnóstico exhaustivo del sitio actual. Reviso la arquitectura de URL, el rendimiento técnico y, sobre todo, la distribución de tráfico que llega desde los buscadores. Con ocho años de oficio y más de 200 proyectos a mis espaldas, sé que una visión global evita sorpresas cuando se migra el hosting o el CMS.

Para construir una hoja de ruta concreta, sigo estos pasos:

• Auditoría de SEO completa, con foco en posiciones de palabras clave críticas.
• Análisis de tráfico orgánico y de fuentes de conversión.
• Inventario de URLs y de contenidos que ya generan autoridad.
• Revisión de backlinks y de señales de experiencia de usuario.
• Identificación de posibles cuellos de botella técnicos (tiempo de carga, mobile‑first, etc.).

Con la información anterior defino los objetivos de la migración. El objetivo principal suele ser mantener las posiciones de las palabras clave críticas y evitar cualquier caída de tráfico durante las primeras 48 horas. Para ello establezco métricas de referencia (ranking, impresiones y clics) y un plan de pruebas que incluye redirecciones 301 y comprobaciones de errores 404. Si el cliente tiene una campaña activa de SEO, indico que la transición no debe interrumpir los anuncios ni los rastreos de Google Search Console.

Un caso que ilustra bien el proceso fue el de un restaurante del Eixample que dependía de la frase local “restaurante catalán Eixample”. Llegó preocupado porque la competencia había ganado posiciones en los últimos meses. Tras el diagnóstico descubrí que esa keyword aparecía en cinco URLs principales y que algunas de ellas tenían redirecciones rotas. Definí como objetivo conservar al menos el 90 % del tráfico orgánico asociado a esa frase y, en caso de pérdida, recuperar la posición en 30 días. Ejecuté el plan de redirecciones, validé cada URL en un entorno de pruebas y, una vez en producción, monitoricé los rankings día a día. En la segunda semana la posición volvió a su nivel anterior y el restaurante mantuvo su flujo de reservas sin interrupciones.

Inventario completo de URLs y contenidos

Cuando me piden cambiar de proveedor web, lo primero que hago es crear un inventario exhaustivo de todas las URLs que existen en el sitio. En mis ocho años de oficio, he visto que la falta de una lista clara es la causa más frecuente de caídas de tráfico tras la migración. Por eso, dedico una sesión completa a mapear cada página, cada categoría y cada recurso estático antes de mover nada.

Abro una hoja de cálculo y defino columnas que me permiten filtrar y comparar rápidamente. Entre las filas incluyo:

• URL completa: la dirección tal cual aparece en el navegador.
• Tipo de contenido: producto, categoría, blog, página estática, archivo, etc.
• Meta título y meta descripción (para validar que no se pierden).
• Visitas mensuales (último mes): extraídas de Search Console o Analytics.
• Posición media en SERP (si está disponible).
• Estado: activo, archivado, pendiente de revisión.

Para rellenar esas columnas utilizo dos métodos que siempre me funcionan: exportar el sitemap XML del sitio y, si el gestor es WordPress o una tienda Shopify, usar plugins que generan un CSV con URLs y metadatos. En una tienda online que gestioné, con más de 300 páginas de producto, el CSV me dio la lista completa en menos de diez minutos; después revisé manualmente las URLs que no aparecían en el sitemap (páginas generadas por filtros) y las añadí a mano.

Un caso concreto que ilustra bien la utilidad del inventario es el de un restaurante del Eixample que quería renovar su web sin perder las reservas que llegaban desde Google. Tras crear la hoja, detectamos que tenían una sección de menús en PDF y varias entradas de blog que ya no se actualizaban. Con esa visión clara, planificamos redirecciones 301 sólo donde era necesario y mantuvimos intactas las URLs de reserva, evitando cualquier pérdida de posicionamiento.

El resultado es siempre el mismo: una migración ordenada, sin sorpresas de 404 inesperados y con la tranquilidad de que cada URL importante está bajo control. Si alguna página no aporta tráfico o conversiones, el inventario también sirve para decidir si es mejor eliminarla o fusionarla antes de la mudanza. Cada proyecto que he entregado sigue este proceso, y la diferencia se nota en la estabilidad del SEO durante las primeras semanas.

Mapeo de redirecciones 301

Cuando un cliente me pide cambiar de proveedor y le preocupa el SEO, lo primero que reviso es el mapa de redirecciones 301. Sin una asignación clara de cada URL antigua a su nuevo destino, Google puede perder el rastro de las páginas y el tráfico se desvanece. Yo suelo comenzar con una hoja de cálculo donde listo todas las URLs del sitio actual, su posición en la arquitectura y el objetivo de la nueva estructura.

El proceso que sigo consta de cuatro pasos esenciales:

• Identificar la URL origen. Copio la dirección completa, incluyendo parámetros que realmente aportan valor.
• Definir la URL destino. La nuevo enlace debe quedar dentro de la misma jerarquía temática; si la categoría cambia, ajusto la ruta pero mantengo la palabra clave principal.
• Comprobar bucles y cadenas. Verifico que ninguna URL redirija a otra que a su vez vuelva a la primera, ni que una cadena de redirecciones supere dos saltos.
• Generar el fichero de redirecciones. En Apache o Nginx exporto las reglas 301 en formato Redirect 301 /vieja /nueva y lo pruebo en un entorno de staging.

Un caso típico que he gestionado recientemente fue la reestructuración del blog de un restaurante del Eixample que quería agrupar sus servicios de “catering”, “eventos privados” y “menús degustación” bajo una sola categoría. Antes tenía URLs como /blog/catering-empresarial y /blog/catering-familias. Decidimos crear la nueva sección /servicios/catering. El mapeo quedó así:

• /blog/catering-empresarial → /servicios/catering
• /blog/catering-familias → /servicios/catering
• /blog/eventos-privados → /servicios/eventos-privados
• /blog/menus-degustacion → /servicios/menus-degustacion

Con estas redirecciones directas evitamos cadenas y garantizamos que cualquier enlace externo o interno conserve su autoridad.

Al final, siempre corro una auditoría de redirecciones con herramientas como Screaming Frog para detectar errores 404 y validar que no haya bucles. Si alguna página no tiene un equivalente claro, prefiero mantenerla como página de aterrizaje temporal y, después, crear contenido que cubra esa intención. ¿Necesitas una revisión de tu arquitectura antes de migrar? Puedes consultar nuestro servicio de auditoria seo barcelona y asegurarte de que el mapa de redirecciones quede perfectamente alineado con tus objetivos.

Configuración del entorno de pruebas (staging)

Cuando un cliente me pide cambiar de proveedor, lo primero que hago es montar un entorno de pruebas, también llamado staging, antes de tocar el sitio en producción. Ese espacio aislado me permite montar la nueva infraestructura, instalar el CMS y los plugins sin que el tráfico real se vea afectado. Así evito sorpresas en medio del lanzamiento y tengo tiempo para comprobar que todo funciona como debe.

El proceso empieza con una copia fiel de los archivos del sitio y de la base de datos. En mi caso suelo crear un subdominio temporal, por ejemplo staging.tusitio.com, y apuntarlo al nuevo servidor. Desde el panel de control del hosting bajo, exporto la base de datos con phpMyAdmin o mediante WP‑CLI y la importo en una base nueva. Después sincronizo los ficheros mediante rsync o FTP, respetando los permisos. Una vez allí reviso el archivo wp‑config.php para apuntar a la base de datos de pruebas y desactivo cualquier caché agresiva que pueda devolver contenido antiguo.

En la fase de revisión de plugins y del tema, sigo una lista de control que me ayuda a no olvidar nada:

• Desactivar plugins que no son compatibles con la versión de PHP del nuevo servidor.
• Actualizar todos los plugins y el tema al último release disponible.
• Comprobar que los plugins de SEO (por ejemplo Yoast) conservan sus ajustes y que los sitemaps se generan correctamente.
• Ejecutar pruebas de velocidad con PageSpeed Insights en el entorno de staging.
• Verificar que los formularios de contacto y los widgets de reserva envían datos a las direcciones de correo correctas.

En un proyecto reciente para una trattoria del Eixample que quería renovar su imagen, instalé el nuevo tema en staging y probé la integración con el plugin de reservas online que usan. Durante la revisión descubrí que el plugin no era compatible con la versión de PHP 8.1 del nuevo hosting, así que opté por cambiar a una alternativa que sí lo era, evitando que el día del cambio el sistema de reservas dejara de funcionar. Con la versión de pruebas validada, migramos a producción sin perder tráfico ni posiciones en Google.

Traspaso de dominio y ajustes DNS

Cuando me piden cambiar de hosting manteniendo el mismo dominio, lo primero que reviso es el registrador actual y el nuevo. No basta con apuntar el dominio al nuevo servidor; hay que asegurarse de que todos los registros DNS (A, CNAME, MX, TXT…) lleguen al mismo punto antes de que el sitio vuelva a estar activo. Por eso creo una copia idéntica de la zona DNS en mi panel de pruebas y la comparo con la producción para evitar sorpresas.

Los pasos que sigo son los siguientes:

1. Exportar la zona DNS completa desde el registrador actual.
2. Recrear esa zona en el nuevo registrador o en el panel de DNS del nuevo hosting.
3. Verificar que los registros críticos (A para la IP del servidor, CNAME para subdominios, MX para el correo y TXT para verificación de Google) coincidan al 100%.
4. Configurar un TTL bajo (por ejemplo 300 s) unos días antes de la migración para acelerar la propagación.
5. Actualizar los registros con la nueva IP y, si procede, cambiar los servidores de nombres (NS) al nuevo proveedor.
6. Comprobar que la resolución DNS funcione con herramientas como dig o nslookup antes de cortar el tráfico.

Una vez que los cambios están listos, planifico una ventana de propagación de entre una y cuatro horas, dependiendo del TTL que haya dejado. Durante ese lapso mantengo el sitio anterior activo y monitorizo los logs del servidor para detectar peticiones que todavía lleguen a la IP antigua. Si aparecen errores, ajusto los registros y vuelvo a comprobar. Al terminar la ventana, vuelvo a subir el TTL a un valor estándar (por ejemplo 86400 s) para evitar consultas innecesarias.

Un caso reciente fue el de el restaurante "Sabores del Eixample", que quería pasar de un hosting compartido a un servidor VPS sin perder su posición en Google. Tras seguir los pasos descritos, la migración se completó en menos de dos horas y no se registraron caídas ni pérdidas de tráfico. El cliente pudo seguir recibiendo reservas online y mantuvo su ranking en los resultados locales de búsqueda.

Migración de contenidos y metadatos

Cuando me llaman para migrar una web, lo primero que reviso es que todo el contenido –texto, imágenes, fichas de producto o artículos – y, sobre todo, las metaetiquetas que Google ya ha indexado, estén perfectamente replicados en el nuevo entorno. Si falta una descripción meta o una etiqueta H1, el algoritmo lo interpreta como una página nueva y pierde la autoridad acumulada. Por eso, antes de tocar cualquier fichero, exporto una copia completa de la base de datos y del CMS, y creo una hoja de cálculo donde registro cada URL, su título, la meta descripción y los atributos alt de las imágenes.

El proceso de migración se desglosa en los siguientes pasos:

• Exportar contenidos: utilizo las herramientas nativas del CMS (WordPress, Joomla…) o scripts SQL para obtener todo el texto y los campos personalizados.
• Extraer metadatos: mediante plugins o consultas directas extraigo títulos, descripciones, palabras clave y datos estructurados (JSON‑LD).
• Normalizar imágenes: copio los archivos al nuevo servidor manteniendo la misma estructura de carpetas y verifico que los atributos alt estén presentes.
• Importar al nuevo sitio: importo la base de datos y, si el CMS es diferente, mapeo los campos para que la información quede en los mismos lugares.
• Validar: corro un rastreo interno con Screaming Frog o Sitebulb para confirmar que cada página conserva su título y descripción.

Un error frecuente es confiar en una copia “visual” de la web y olvidar las etiquetas meta robots o los canonical. Cuando eso ocurre, Google interpreta que hay contenido duplicado y la posición de las palabras clave puede desplomarse en unas semanas. Otro problema típico es subir las imágenes sin comprimirlas, lo que ralentiza la carga y afecta al Core Web Vitals, penalizando indirectamente al SEO.

Ejemplo concreto: el restaurante “Can Vinyet” en el Eixample me pidió cambiar de proveedor porque el hosting anterior limitaba la velocidad. La web tenía 120 páginas, cada una con título y descripción optimizados para términos como “cocina catalana” y “menú del día”. Tras exportar la base de datos y las imágenes, recreé la misma estructura de URLs en el nuevo servidor, importé los metadatos y ajusté los alt de más de 300 fotos de platos. En la fase de validación detecté tres URLs sin canonical y las corregí antes de lanzar la versión definitiva. El tráfico orgánico se mantuvo estable y, al cabo de un mes, el restaurante empezó a recuperar posiciones perdidas por la lentitud anterior.

Comprobación de redirecciones y detección de errores 404

Comprobación de redirecciones y detección de errores 404

Una vez migrada la web, el primer paso es verificar que todas las redirecciones 301 que mapeaste en la fase inicial funcionan correctamente. Esto es crítico. He visto webs de clientes que, por una mala configuración, perdían la mitad de su tráfico orgánico porque Google se encontraba con montones de páginas que ya no existían. No te la juegues aquí.

Para esta tarea, utilizo herramientas como Screaming Frog. Rastreo la web entera y busco específicamente los códigos de estado. Me interesa ver que las URLs antiguas redirigen a las nuevas sin pasar por cadenas de redirecciones, que no haya bucles y, sobre todo, que no aparezcan errores 404 de páginas que antes existían y ahora no. Es un trabajo minucioso, pero indispensable. También compruebo los logs del servidor para ver cómo están respondiendo las peticiones de Googlebot y otros robots.

Un ejemplo que siempre recuerdo es el de un portal de noticias de Barcelona, con miles de artículos. Cuando hicieron una migración interna sin nosotros, se encontraron con que el 30% de sus noticias más antiguas, que seguían generando visitas desde Google, de repente daban error 404. El problema era que el nuevo CMS había cambiado la estructura de las URLs de forma radical y no se habían implementado las redirecciones. Tuvimos que hacer una auditoría post-migración y generar un archivo de redirecciones masivo. Lo ideal es prevenir esto.

Además de Screaming Frog, también recurro a Google Search Console. En el informe de 'Rastreo' y 'Errores', verás las URLs que Google no puede encontrar. Son errores 404 que el propio buscador ha detectado y que debes corregir cuanto antes. Si no quieres que tu SEO se resienta, atiende a:

• Errores 404: Páginas que ya no existen y no redirigen a ningún sitio.
• Redirecciones rotas: Redirecciones que apuntan a una página que tampoco existe o a un error.
• Cadenas de redirecciones: URLs que pasan por varias redirecciones antes de llegar a la página final. Esto ralentiza la carga y puede confundir a Google.

Corregir estos errores es un trabajo continuo en las primeras semanas tras la migración. Si necesitas ayuda para revisar tu web o planificar una migración, te invito a que eches un vistazo a nuestros servicios de SEO. Desde WebsBarcelona, nos encargamos de que tu cambio de proveedor web sea lo más suave posible para tu posicionamiento.

Monitorización de rendimiento SEO en las primeras semanas

Una vez que la web está en producción, lo que más me preocupa es que el posicionamiento no se desmorone. Por eso dedico los primeros 30‑40 días a una vigilancia constante, mirando cada señal que indique que Google sigue reconociendo la nueva dirección como la misma que antes. Así evito sorpresas desagradables cuando Google empieza a rastrear la nueva arquitectura.

Los indicadores que controlo son tres:

• Tráfico orgánico: visitas procedentes de búsquedas en los últimos 7 y 30 días, comparándolas con la media del mes anterior a la migración.
• Posiciones de palabras clave: ranking de los términos principales en los SERP, con especial atención a los que estaban en la primera página.
• Errores en Search Console: 404 inesperados, problemas de cobertura e indexación, y alertas de cambios de URL.

Reviso esos datos cada dos días durante la primera semana y, si todo marcha bien, paso a una revisión semanal. Cuando detecto una caída de tráfico superior al 15 % o un aumento de errores 404, actúo de inmediato: reviso el mapa de redirecciones, corrijo los enlaces rotos y envío una nueva solicitud de indexación. En un caso reciente, un e‑commerce de moda que había cambiado de proveedor mostró una caída del 25 % el día 3. Tras ajustar unas 12 redirecciones olvidadas, el tráfico volvió a subir y recuperó su nivel anterior en apenas 10 días. Una revisión rápida del archivo robots.txt también ayuda a prevenir bloqueos inesperados.

El ejemplo que más me ilustra es el de “La Tapa del Eixample”, un restaurante del barrio que necesitaba una web más rápida y con reservas online. Después de migrar, monitoricé los tres indicadores y descubrí que algunas fichas de platos habían quedado sin la etiqueta title. Corrigí los metadatos y, con la monitorización diaria, vi cómo el tráfico orgánico pasó de 1 200 visitas semanales a 1 500 en dos semanas, sin perder ninguna posición importante. Esa vigilancia temprana fue la clave para que el negocio mantuviera su flujo de clientes mientras la nueva web se estabilizaba.

Ajustes finales y recomendaciones post‑migración

Una vez que la nueva web está online y las redirecciones 301 funcionan, el trabajo no termina. Lo que realmente garantiza que el tráfico orgánico se mantenga es repasar los detalles que quedan pendientes: los backlinks que apuntan a la antigua URL, el sitemap.xml y la comunicación directa con Google a través de Search Console. Cuando un cliente me llama después de la migración, lo primero que reviso son esos puntos porque, si se dejan en el aire, el algoritmo puede considerar que hay contenido desaparecido y penalizar la posición.

Para cerrar el proceso, sigo una checklist que cubre los ajustes imprescindibles.

• Audito los backlinks existentes y contacto a los propietarios de los sitios que enlazan para solicitar la actualización a la nueva URL.
• Genero un nuevo sitemap, lo reviso manualmente y lo envío a Google Search Console y a Bing Webmaster Tools.
• Compruebo que todas las etiquetas canonical apunten al dominio definitivo y que no haya versiones duplicadas.
• Reviso el archivo robots.txt para asegurarme de que no bloquee recursos críticos como CSS, JS o imágenes.
• Configuro alertas en Search Console y en Google Analytics que me avisen de caídas de tráfico o de errores 404 inesperados.

Con todo eso actualizado, la web está lista para seguir compitiendo sin perder autoridad.

Un caso que recuerdo con claridad es el de un restaurante del Eixample que me pidió cambiar de proveedor porque necesitaba un hosting más rápido. En la fase de pruebas descubrimos que las imágenes del menú estaban sin optimizar y que el servidor anterior las entregaba con un peso excesivo. Tras migrar al nuevo entorno, implementé una compresión con WebP y activé la carga diferida; la velocidad de carga bajó de 5 s a menos de 2 s. Gracias a esa mejora, el tiempo medio de permanencia aumentó y, como consecuencia, el posicionamiento de sus platos estrella subió sin perder visitas. Puedes ver más ejemplos de diseño web que hemos realizado.

Para no perder el impulso, programo una revisión de métricas cada siete días durante el primer mes y, una vez estabilizada la posición, paso a tareas de expansión como la creación de contenido nuevo o la mejora de la experiencia móvil. Si sigues estos ajustes finales, la migración se convierte en una oportunidad para afinar la presencia online sin sacrificar el SEO que tanto te ha costado construir.