Qué guardar antes de migrar un sitio web: la lista completa
Una copia de la base de datos no basta: antes de migrar, también hay que guardar los archivos, la configuración del servidor, las redirecciones existentes, los datos de medición y los accesos. Esta es la lista, con un enlace a cada procedimiento.
Antes de cualquier migración, se piensa en hacer una copia de seguridad de la base de datos. Es necesario, pero no suficiente: una migración bien hecha necesita poder volver atrás si la puesta en línea sale mal, comparar el nuevo sitio con el antiguo y saber con precisión lo que contenía el sitio antiguo, incluido lo que ya nadie mira.
Esta página es la lista de control de lo que hay que guardar, durante la fase de preparación de la migración. Cada elemento remite, cuando existe, al procedimiento detallado.
Por qué guardar algo más que la base de datos
Una copia de seguridad antes de migrar sirve para tres cosas:
- volver atrás: si la nueva versión tiene un problema grave el día de la puesta en línea, hay que poder volver a poner en servicio la antigua, con sus archivos, su base de datos y su configuración;
- comparar: los datos de tráfico y visibilidad anteriores a la migración son la referencia que dirá, dentro de tres meses, si la migración ha costado visitas;
- no olvidar nada: las URL antiguas, las redirecciones ya existentes y los metadatos de cada página son la materia prima del plan de redirección. Una vez apagado el sitio antiguo, ya no se pueden recopilar.
La lista de lo que hay que guardar
1. Los archivos del sitio y los medios
El código, el tema, las extensiones o módulos y, sobre todo, los medios: imágenes, vídeos, documentos descargables (en WordPress, la carpeta wp-content). Cópielos con un cliente SFTP o pida a su proveedor de alojamiento un archivo completo. Los medios cuentan doblemente: a menudo están indexados en Google Imágenes y citados por otros sitios, y sus direcciones tendrán que redirigirse si cambian (véase la redirección de imágenes).
2. La base de datos
Páginas, artículos, productos, cuentas, pedidos, ajustes: en un sitio dinámico, casi todo está en la base de datos. Una exportación SQL (con phpMyAdmin o mysqldump) solo contiene la base: se guarda junto con la copia de los archivos, y ambas forman la copia de seguridad completa. Los métodos (manual, panel de administración, nube, rsync, servicios automatizados) se detallan en nuestro artículo sobre la copia de seguridad de la base de datos.
3. La configuración del servidor y las redirecciones existentes
Lo que no está ni en los archivos del CMS ni en la base de datos, y cuya falta se descubre después:
- el archivo
.htaccesso la configuración de nginx, con las redirecciones ya existentes. Hay que incluirlas en el nuevo plan y actualizarlas para que apunten directamente a las nuevas direcciones: si no, una URL antigua redirigida en 2019 acaba al final de una cadena de dos o tres redirecciones; - las redirecciones gestionadas por una extensión (como Redirection en WordPress) o en la administración del CMS, que viven en la base de datos y desaparecen con él;
- el
robots.txty los sitemaps XML, para comparar lo que se ofrecía a Google antes y después; - las tareas programadas (cron), las reglas de caché y la zona DNS del dominio (registros A, CNAME, MX del correo, TXT de verificación), que hay que anotar antes de cualquier cambio de alojamiento.
4. Los contenidos y sus metadatos SEO
La base de datos contiene los textos, pero también conviene guardar una fotografía de lo que está realmente en línea: un rastreo completo del sitio antiguo, con, para cada URL, su código de respuesta, su title, su meta description, su etiqueta canonical y sus enlaces internos. Este registro permite comprobar, después de la migración, que no se ha perdido ningún metadato por el camino. Es el tema de nuestro artículo sobre la migración de los contenidos editoriales.
5. Los datos de medición: Google Analytics y Search Console
El historial de Google Analytics 4 y de Google Search Console no se migra: se conserva y se exporta. Search Console solo guarda 16 meses de datos, y Google Analytics 4 borra el detalle de los eventos más allá del periodo de conservación elegido. Las exportaciones que hay que hacer, y los ajustes que hay que revisar, están en nuestro artículo para guardar los datos de Google Analytics 4 y Search Console.
6. Las cuentas y los accesos
Una migración se bloquea más a menudo por un acceso perdido que por una dificultad técnica. Haga la lista, con su titular, de los accesos al alojamiento, al registrador del dominio y a la zona DNS, a la administración del CMS, a Search Console, a Google Analytics, a Google Tag Manager y a los servicios conectados al sitio (pago, transportistas, CRM, herramienta de envío de correos). Compruebe que cada cuenta pertenece a la empresa y no a un antiguo proveedor o empleado. Guarde estos accesos en un gestor de contraseñas, nunca en un documento compartido en texto plano.
Dónde y durante cuánto tiempo conservar las copias
Una copia de seguridad guardada en el servidor que se va a abandonar no es una copia de seguridad. Aplique la regla 3-2-1: tres copias, en dos soportes distintos, una de ellas fuera del servidor y de la oficina. Feche cada copia y anótela en el diario de la migración.
Consérvelas más allá de la puesta en línea, hasta que el nuevo sitio esté estabilizado y el tráfico haya recuperado su nivel: varios meses, no unos días. También servirán para recuperar una página o una redirección olvidada.
Comprobar que una copia se puede restaurar
Una copia que nunca se ha restaurado es una apuesta. Antes de la migración, restáurela al menos una vez en un entorno de pruebas: el sitio debe mostrarse, la base de datos debe responder y los medios deben estar. Es también la mejor manera de cronometrar una posible vuelta atrás y, por tanto, de decidir hasta cuándo sigue siendo posible el día D.
Los procedimientos detallados
¿Ha guardado las URL antiguas y las redirecciones existentes? Swan rastrea el sitio antiguo y su preproducción, y le propone el plan de redirección.
