Antes de actualizar WordPress, prepara un plan para recuperar tu sitio

Antes de autorizar una actualización, pide tres cosas: un respaldo completo y reciente, una prueba de recuperación fuera del sitio público y un acuerdo sobre qué hacer si fallan las funciones que sostienen tu negocio. Un mensaje de “copia completada” no demuestra, por sí solo, que podrás volver a operar.

Esta guía está pensada para negocios con WordPress, incluidas tiendas con WooCommerce. Te ayuda a conversar con quien mantiene el sitio y dejar por escrito una decisión que suele quedar implícita: cómo recuperarlo sin pasar por alto pedidos, consultas o cambios recientes.

Empieza por lo que necesitas recuperar

En una instalación típica de WordPress, el respaldo completo requiere archivos y base de datos. Descargar las carpetas del sitio no suele incluir la base de datos; ahí viven contenidos y configuraciones que también necesitas. La documentación de respaldos de WordPress explica esta separación.

Pide que tu proveedor identifique qué cubre la copia: tema, plugins, imágenes, configuración y datos. También debe registrar fecha, hora y zona horaria del respaldo, dónde está guardado y quién puede restaurarlo. Evita una respuesta como “el hosting se encarga” sin confirmar el procedimiento y el acceso.

Después, dibuja el límite del sitio. Un CRM, una plataforma de reservas o un servicio de correo pueden conservar información fuera de WordPress. Nuestra recomendación es anotarlos por separado y preguntar cómo se comprobará su conexión después de recuperar la web. No des por hecho que una copia del sitio incluye todos esos servicios.

Una copia guardada y una recuperación probada son dos entregables

Pide una prueba en un entorno separado del sitio público. El responsable técnico debe recuperar la copia allí y comprobar que las funciones acordadas siguen operando. Registra cuánto tardó la prueba y qué falló; ese tiempo observado sirve para planear, pero no garantiza que una incidencia real dure lo mismo.

Para WooCommerce, la guía oficial de actualización recomienda contar con un respaldo reciente, probar los cambios en una copia de pruebas y revisar recorridos como producto, carrito, pago y correos de pedido antes de aplicar el mismo conjunto de actualizaciones al sitio público.

Para esa prueba, acuerda un entorno de acceso restringido y revisa las conexiones externas: pagos, correos, reservas, CRM y automatizaciones. Usa los modos de prueba que correspondan y datos de prueba; clonar el sitio no debe convertirse en un motivo para cobrar o enviar mensajes a clientes reales. El proveedor debe explicar cómo evitará esos efectos en tu configuración concreta.

El punto delicado: qué pasó después del respaldo

Restaurar una base de datos completa puede devolverla al estado que tenía cuando se creó la copia. Así lo describe la documentación de restauración de WordPress. Por eso, antes de hacerlo, hay que identificar la información registrada después de ese momento.

Ejemplo hipotético: una tienda crea una copia a las 09:00, recibe dos pedidos y a las 10:00 detecta que una actualización rompió el proceso de compra. Si reemplaza toda la base de datos con la copia de las 09:00, esos pedidos posteriores no estarán en ella. Que exista un registro del pago en otro servicio no reconstruye automáticamente el pedido, sus productos ni su estado en la tienda.

El acuerdo debe indicar quién preserva y revisa la información reciente, qué registros externos se pueden contrastar y quién decide si conviene corregir el fallo o restaurar. No hay un método universal para reincorporar pedidos: depende de los plugins, integraciones y forma de almacenamiento. Esa decisión corresponde al responsable técnico, con el negocio informado del posible impacto.

Si el cambio requiere detener temporalmente compras o consultas, acuerda la ventana y un canal alternativo. No confundas “tenemos una copia de ayer” con “podemos recuperar todo lo que entró hoy”.

Copia esta ficha antes de dar luz verde

Completa la ficha con tu proveedor. Un campo sin respuesta es una tarea pendiente, no una condición ya resuelta.

• Cambio previsto: ___ . Componentes y versiones que se actualizarán: ___ . Persona responsable: ___ .
• Ventana de trabajo: ___ . Zona horaria: ___ . Quién autoriza el inicio y quién puede detenerlo: ___ .
• Respaldo: fecha y hora ___ . Archivos y datos incluidos ___ . Ubicación y persona con acceso ___ .
• Prueba de recuperación: fecha ___ . Entorno ___ . Tiempo observado ___ . Evidencia y fallos pendientes ___ .
• Información posterior al respaldo: qué puede seguir entrando ___ . Cómo se preservará y comprobará ___ . Responsable ___ .
• Criterio para detener el cambio: ___ . Quién decide entre corregir y restaurar ___ . Cómo se avisará al negocio ___ .
• Revisión posterior: recorridos que se probarán ___ . Resultado esperado ___ . Evidencia ___ . Persona que confirma la reapertura ___ .
• Seguimiento: cuándo se revisará otra vez ___ . Canal de soporte ___ . Trabajo incluido y trabajo que requiere cotización adicional ___ .

Como criterio de planificación, no autorices una actualización rutinaria si nadie puede explicar cómo recuperar el sitio o cómo tratar los datos recientes. Una corrección urgente de seguridad puede requerir otro calendario: pide que el responsable técnico valore la urgencia y documente las medidas disponibles, en lugar de posponerla indefinidamente.

Comprueba el recorrido completo al terminar

Define las pruebas según tu negocio. Estas son propuestas de aceptación, no una certificación de que todo el sitio está libre de errores:

• Sitio de servicios: enviar una consulta de prueba, ver la confirmación y comprobar su llegada al destinatario o sistema acordado. Que el formulario muestre “enviado” no basta.
• Tienda: revisar un producto y su variante, añadirlo al carrito y verificar envío, total y flujo de pago con el método de prueba autorizado. Confirmar después el registro del pedido y sus notificaciones, según el alcance.
• Sitio con reservas: comprobar disponibilidad y registrar una reserva de prueba sin bloquear por accidente un horario real.
• En todos los casos: revisar los recorridos acordados en móvil y escritorio, anotar el resultado y cerrar los registros de prueba para que no se confundan con actividad comercial.

Si la actualización forma parte de un rediseño con cambios de URL, añade una revisión específica de redirecciones. La guía sobre planificación de URLs para un relanzamiento, disponible en inglés, aborda esa tarea distinta.

Lleva la ficha al alcance de mantenimiento

El resultado útil es un acuerdo comprobable: qué cambia, qué se puede recuperar, qué información requiere cuidado y quién verifica que el negocio puede seguir operando.

Si necesitas ayuda para convertir la ficha en un alcance de trabajo, puedes compartirla al consultar nuestro servicio de mantenimiento web y de tiendas. Branding Bull evalúa la plataforma y acuerda actualizaciones, revisiones y responsabilidades; el hosting, los respaldos, la intervención de especialistas y las ventanas de soporte se definen en el plan. No se presupone monitoreo permanente ni disponibilidad garantizada.