Un WordPress lleva su dirección escrita por dentro. Trasladarlo es saber dónde, y qué no se toca

Depende menos del tamaño de la web que del tipo de traslado. Cambiar de servidor manteniendo la dirección no exige lo mismo que cambiar a la vez de dominio, de estructura de enlaces o de tema. También pesan el número de plugins, si hay un constructor de páginas, si la web tiene varios idiomas y si es una tienda con pedidos. Para comparar presupuestos, pregunta si incluyen la traducción de la base de datos, el mapa de redirecciones y la vigilancia posterior. En Daimatics el precio y las condiciones se hablan en la reunión.

No, y la misma documentación de Google avisa de que, en cualquier cambio importante de una web, puede haber fluctuaciones de posiciones mientras vuelve a rastrearla e indexarla. Sí que se puede controlar todo lo que depende del traslado: que cada dirección antigua tenga destino, que la base de datos se traduzca sin romper nada y que Search Console se vigile las semanas siguientes. Daimatics no garantiza posiciones ni tráfico. Si alguien lo hace, vale la pena leer qué pasa exactamente si no se cumple.

No debería ser necesario. El WordPress se prepara entero en el servidor nuevo mientras el antiguo sigue sirviendo las visitas, y el cambio se hace cuando todo se ha probado. La guía de Google recomienda bajar antes el TTL de los registros DNS para que el cambio se propague más rápido. El punto delicado es lo que pasa entre la copia y el cambio: comentarios, formularios o pedidos que llegan a la web antigua. En una tienda, se resuelve deteniendo las compras durante el cambio o sincronizándolas justo antes.

No a ciegas. La documentación de WordPress advierte de que hacerlo sobre toda la base de datos puede romper los datos serializados, porque algunos temas y widgets guardan cada valor con su longitud: si la dirección nueva es más larga, el valor deja de ser legible. Hace falta una herramienta que entienda la serialización, como el comando search-replace de WP-CLI, que además permite hacer una simulación sin guardar cambios. Y hay una columna que no se debe tocar nunca: el guid de las entradas.

Normalmente viajan enteros, pero no siempre funcionan igual. Los motivos habituales son la versión de PHP del servidor nuevo, licencias que se validan según el dominio, plugins de caché o de seguridad que guardan rutas del servidor antiguo y servicios externos que tienen registrada la dirección antigua. Por eso se hace un inventario antes y se prueba todo en un entorno de pruebas con la configuración de destino. También es un buen momento para retirar los plugins que ya no se usan.

Con una comprobación más: las etiquetas hreflang. Cada plugin de traducción guarda las traducciones a su manera, en tablas propias, en términos o en opciones, y el traslado tiene que incluirlas todas. Si cambia el dominio o la estructura de las direcciones, las versiones de cada idioma tienen que seguir señalándose entre ellas: Google pide que cada versión de idioma se enumere a sí misma y a todas las demás. Y cada idioma necesita sus propias redirecciones en el mapa.

La base es la misma, pero hay más en juego. Una tienda recibe pedidos y pagos, y ninguno se debe perder entre la copia y el cambio. Las pasarelas de pago suelen tener registrada la dirección donde avisan de cada cobro, y si el dominio cambia hay que actualizarla. También hay que probar en el servidor nuevo los correos de pedido, los envíos y los impuestos, y las direcciones de productos y categorías entran en el mapa de redirecciones como cualquier otra.

Depende sobre todo del tamaño de la web. Según la guía de Google sobre traslados, en una web mediana pueden pasar unas cuantas semanas o más antes de que empiece a mostrar las direcciones nuevas en lugar de las antiguas, y en las grandes, más tiempo. Enviar el mapa del sitio nuevo a Search Console ayuda a que las descubra antes. Si solo cambia el servidor y no las direcciones, Google explica que es normal una bajada temporal del ritmo de rastreo justo después del cambio.

Solo si hay un motivo, y haciéndolo entero. El prefijo no es solo el nombre de las tablas: WordPress también lo usa en el nombre de la opción donde guarda los roles y en la clave de los permisos de cada usuario. Si se renombran las tablas y se olvidan estas claves, los administradores pueden entrar pero pierden los permisos. Además, mezclar este cambio con el traslado añade una variable por si algo falla. A menudo es mejor hacerlo por separado.