Cómo clonar una web WordPress en local

Cuando estás empezando a tocar en serio una web -en WordPress o en cualquier otro sistema- tienes que interiorizar una regla básica antes de empezar: no experimentes en producción.

Por varios motivos:

1. Porque los resultados pueden ser catastróficos si no sabes bien lo que estás tocando o no tienes backup.
2. Porque a causa de lo anterior y mientras restauras todo, puedes sufrir un pico de estrés nada deseable.
3. Y porque montar una copia en local te llevará solo media hora y lo agradecerás eternamente.

Repito:

Primero montas una copia local. Luego tocas. No al revés.

Estos días que estoy cambiando a fondo mi web me ha tocado hacerlo, así que he aprovechado y he creado este tutorial.

Mi web tenía varios años de contenido, 250 entradas, imágenes acumuladas desde 2013 y el tamaño suficiente para que Duplicator se quedara a medias dos veces antes de funcionar.

Eso también está aquí. Los fallos -y sus soluciones- incluidos.

Para qué sirve tener un clon local de WordPress

Una copia local te permite trabajar en tu ordenador sin tocar la web real.

Útil para: probar plugins, cambiar de tema, revisar base de datos, preparar una migración, hacer una auditoría técnica, instalar Polylang, modificar CSS o romper cosas sin que Google, tus usuarios o tu cliente lo noten.

En mi caso el objetivo era doble:

1. Cambiar el diseño completamente, pasando de una web de captación de leads a una revista digital.
2. Preparar la web para traducción asistida por IA. Un desarrollo propio con cierto nivel de riesgo, ya que implica tocar varias cosas a la vez.

En cualquier caso el proceso es el mismo si quieres recategorizar de forma automatizada, cambiar de tema, añadir un plugin grande tipo WooCommerce o simplemente tener un entorno de pruebas antes de tocar algo serio.

Herramientas que he usado

• LocalWP: para crear el entorno WordPress local.
• Duplicator: para exportar la web de producción.
• cPanel:  el panel de control del hosting para descargar manualmente la carpeta de imágenes.
• WP-CLI: incluido en LocalWP, para corregir opciones internas de WordPress.

Todo gratuito. 

Guía paso a paso para clonar tu WordPress en local

Ahora que conoces las herramientas, vamos con el paso a paso, que es un poco más largo de lo habitual.

De todas formas, para que te hagas una idea, en 30 minutos más o menos tendrás todo listo, en función de los problemas que se te presenten. Porque si tu web es pequeña y no da ningún fallo, es posible que lo tengas en menos de diez minutos.

Pocas inversiones más rentables que ésta.

Paso 1: instalar LocalWP

LocalWP crea instalaciones de WordPress en local sin tener que configurar Apache, MySQL y PHP a mano. No necesitas XAMPP, ni WAMP, ni LAMP.

Lo instalas, creas un nuevo sitio y en dos minutos tienes un WordPress limpio funcionando en tu ordenador.

En mi caso lo llamé yg, así que LocalWP le asignó el dominio local https://yg.local con este entorno:

Campo	Valor
Servidor	nginx
PHP	8.2
Base de datos	MySQL
WordPress	Instalación limpia

Con eso es suficiente para empezar.

Paso 2: comprobar que el WordPress local abre

Antes de importar nada, abre el sitio local y entra al panel:

• https://yg.local
• https://yg.local/wp-admin

Si carga y puedes entrar, el entorno está listo. No instales nada todavía. No toques ajustes. Solo comprueba que funciona.

Paso 3: instalar Duplicator en la web real

Entra en el WordPress de producción (no en el local) e instala Duplicator:

Plugins > Añadir nuevo > Duplicator

Instálalo y actívalo.

Importante: Duplicator se instala en producción. La idea es generar un paquete de la web real para luego importarlo en LocalWP.

Paso 4: crear una copia con Duplicator

Desde el panel de producción ve a:

Duplicator > Packages

Crea un paquete nuevo con un nombre que identifique para qué es. Yo usé:

yagogonzalez-copia-local-fase0

La exploración inicial avisó de que el sitio era grande. Nada raro en webs con años de contenidos.

El problema llegó al construir el paquete:

Couldn’t close zip archive

El servidor no pudo cerrar el archivo ZIP. 

No significa que la web se haya roto. Significa que el hosting no pudo completar la operación, probablemente por tamaño, tiempo de ejecución o límites de memoria.

Primer problema a resolver.

Paso 5: probar DupArchive si el ZIP falla

Duplicator ofrece una alternativa cuando el ZIP falla: DupArchive.

Para eso hace falta cambiar el motor de archivo de ZIP a DupArchive. El paquete pasa a generarse como .daf en lugar de .zip.

Se cambia desde:

Duplicator > Ajustes > Copias de seguridad > Archivo

Ahí busca Archive Engine y cambia ZipArchive por DupArchive.

Luego guarda los cambios.

¿Todo listo?

Pues no. Nuevo error:

El tamaño total de los archivos y la base de datos supera el límite de 500 MB

La copia pesaba aproximadamente 1,33 GB. Tampoco servía cambiar todo per sé.

La solución: no meter todo dentro del paquete.

Paso 6: crear el paquete sin la carpeta uploads

La carpeta que dispara el peso de cualquier WordPress con años de vida es wp-content/uploads/. 

Ahí están imágenes, PDFs, miniaturas, WebP y todo lo que se ha subido desde el primer día.

Para reducir el paquete de descarga, En Duplicator activé los filtros de archivos y excluí:

• wp-content/uploads/
• wp-content/cache/
• wp-content/upgrade/
• wp-content/backups-dup-lite/
• wp-content/plugins/duplicator/backups/

Con esto, el paquete incluye lo importante para reconstruir la web: base de datos, WordPress, tema, plugins, configuración, entradas, páginas, taxonomías, ACF, Yoast y ajustes internos. 

Las imágenes las descargamos aparte. Luego te explico cómo en el paso 8.

Paso 7: descargar los archivos de Duplicator

Una vez generado el paquete, Duplicator crea dos archivos:

• installer.php
• archivo .zip o .daf

Descarga los dos. 

Son los que permiten reconstruir la web en local. El instalador se encarga de extraer el paquete, importar la base de datos, sustituir URLs y ajustar rutas.

Paso 8: descargar la carpeta uploads

Como uploads no iba dentro del paquete, toca descargarlo manualmente desde el hosting.

La ruta habitual en un WordPress:

/public_html/tudominio.com/wp-content/uploads/

Si tienes un hosting normal puedes descargarla desde las opciones del gestor de archivos del cPanel. Es lo que hice yo.

Si no puedes por esta vía, tendrás que hacerlo a vieja usanza, descargándola por FTP o SFTP directamente al ordenador con Filezilla o similar.

Consejo: no comprimas la carpeta en el servidor. Eso volvería a meter carga al hosting y podría fallar igual que Duplicator. La descarga directa es más lenta, pero más segura.

Paso 9: preparar LocalWP para importar la copia

Con los dos archivos de Duplicator descargados, vuelve a LocalWP:

1. Para el sitio local: botón Stop site.
2. Abre la carpeta del sitio: botón Site folder.
3. Entra en app > public.
4. Borra el contenido de public (el WordPress limpio que creó LocalWP).
5. Copia ahí los dos archivos de Duplicator.

Importante: hay que borrar el contenido de public, no la carpeta public.

La carpeta debe existir y dentro sólo tienen que estar los dos archivos descargados:

• installer.php
• copia-local.daf

Después arranca el sitio: botón Start site.

Paso 10: ejecutar el instalador de Duplicator en local

Abre el instalador en el navegador:

https://yg.local/installer.php

El instalador detecta el paquete y empieza el proceso.

Para conectar con la base de datos local usa los datos de LocalWP:

Campo	Valor
Database Host	localhost
Database Name	local
User	root
Password	root

Como era una instalación local vacía (la que te monta por defecto el programa al principio), dale a que aceptas que Duplicator borre la base de datos anterior. 

No pasa nada: solo estaba borrando el WordPress limpio de LocalWP, no la web real.

Después Duplicator hace el reemplazo de URLs:

• Old URL: https://yagogonzalez.com
• New URL: https://yg.local

Al terminar, ya puedes entrar en el WordPress local.

Importante: tras importar la base de datos, el usuario y contraseña son los de la web real, no los creados inicialmente en LocalWP.

Paso 11: limpiar los archivos de instalación

Duplicator elimina normalmente los archivos del instalador al finalizar:

• installer.php
• archivo .daf
• carpeta dup-installer
• logs de instalación

En producción es importante por seguridad. En local es menos crítico, pero conviene dejarlo limpio.

Revisa que no existan tras la instalación antes de continuar.

Paso 12: copiar uploads en el WordPress local

Con el sitio parado (Site Stop) en LocalWP, entra en app > public > wp-content y copia ahí la carpeta uploads que descargaste.

La estructura correcta:

wp-content/
├── plugins/

├── themes/

└── uploads/

    ├── 2013/

    ├── 2014/

    ...

    └── 2026/

Lo que no debe pasar:

wp-content/uploads/uploads/2026/

Ese doble uploads/uploads es un error clásico de comprimir en zip antes de descargar y rompe todas las rutas de las imágenes.

Paso 13: corregir el problema de las imágenes rotas

En mi caso, aquí llegó el problema más gordo (por inesperado): la web cargaba, pero las imágenes no se veían. Y no era por la ruta con doble upload.

El problema estaba en la URL que WordPress generaba para las imágenes:

https://yg.local/C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads/2026/06/imagen.webp

Todo lo que está marcado en negrita sobraba. La URL correcta tenía que ser:

https://yg.local/wp-content/uploads/2026/06/imagen.webp

WordPress tenía guardada en la opción upload_path una ruta absoluta de Windows:

C:/Users/pcadmin/Local Sites/yg/app/public/wp-content/uploads

Para corregirlo, abre Site shell en LocalWP y ejecuta estos tres comandos uno detrás de otro:

wp --url=https://yg.local option delete upload_path

wp --url=https://yg.local option delete upload_url_path 

wp --url=https://yg.local cache flush

Una vez hecho, al recargar, las imágenes ya aparecían.

El problema es que también aparecían varios Warnings (avisos).

Paso 14: corregir warnings visibles

Como te decía, aparecía este warning en la web local:

Constant WP_POST_REVISIONS already defined

Aquí tiré de ChapGPT, porque no tenía ni idea de cómo solucionarlo.

El problema venía de functions.php del tema, que definía WP_POST_REVISIONS sin comprobar si ya estaba definida en otro sitio.

La corrección:

if ( ! defined( 'WP_POST_REVISIONS' ) ) {
    define( 'WP_POST_REVISIONS', false );
}

Si en tu caso el valor es distinto, simplemente respeta el tuyo:

if ( ! defined( 'WP_POST_REVISIONS' ) ) {
    define( 'WP_POST_REVISIONS', 5 );
}

Lo cambié, desde el gestor de archivos del tema de WordPress (Apariencia > Editor de archivos de temas) guardé el archivo y listo.

Paso 15: limpiar producción

Con la copia local funcionando, vuelve a la web real y elimina los rastros de Duplicator:

1. Duplicator > Packages:  borra los paquetes creados.
2. Plugins > Plugins instalados: desinstala Duplicator.

Esto no afecta a la copia local. Solo evita dejar paquetes pesados e instaladores innecesarios en producción.

No es obligatorio pero sí recomendable.

Paso 16: probar el clon local

Comprueba varias URLs antes de seguir. 

En mi caso revisé:

• La portada.
• Una entrada.
• Una categoría.
• Una subcategoría.
• Una etiqueta.

Lo hice así porque cada una utiliza una plantilla diferente:

• https://yg.local
• https://yg.local/ruta-de-escape
• https://yg.local/tecnologia
• https://yg.local/ocio/series
• https://yg.local/negocio

Cuatro cosas a revisar:

1. La web carga.
2. Las imágenes se ven.
3. El diseño es igual que en producción.
4. Los enlaces internos apuntan a yg.local, no a yagogonzalez.com.

Este último punto es clave. Si haces clic en un artículo y te manda a producción, todavía tienes URLs mal reemplazadas.

Paso 17: crear un punto de restauración antes de seguir

Este paso de nuevo es opcional, pero recomendable.

Antes de ponerte a hacer los cambios que necesites en local o a tocar cualquier cosa seria, crea un punto de restauración.

En LocalWP puedes clonar el sitio:

Clone site

En mi caso creé una copia llamada yg-pre-polylang.

La lógica:

• yg = sitio local de trabajo.
• yg-pre-polylang = copia limpia antes de tocar nada.

Si algo peta, no hay que repetir toda la migración de producción desde cero, sino que cojo esta copia limpia y trabajo sobre ella. No sin antes haberla vuelto a clonar, claro.

Problemas habituales en este proceso

Las migraciones locales casi nunca salen perfectas a la primera. Te agrupo aquí los que aparecieron en este caso.

El ZIP de Duplicator falló

Error: Couldn’t close zip archive

Causa: límites del servidor (tamaño, tiempo de ejecución, memoria).

Solución: probar DupArchive o excluir carpetas pesadas del paquete.

DupArchive tenía límite de tamaño

Error: el paquete superaba los 500 MB.

Solución: excluir wp-content/uploads/ y descargar esa carpeta aparte.

Las imágenes no cargaban

Causa: WordPress usaba una ruta absoluta de Windows como si fuera una URL pública.

Solución:

wp option delete upload_path

wp option delete upload_url_path

Warning de PHP por constante ya definida

Causa: WP_POST_REVISIONS definida dos veces en functions.php.

Solución: envolver la definición con if ( ! defined(…) ).

Conclusión

Si tu web pesa poco, Duplicator lo hace todo solo. Pero si tiene años de contenido e imágenes acumuladas, lo habitual es partir el proceso en dos:

• Duplicator = base de datos + WordPress + tema + plugins
• FTP/SFTP = carpeta uploads

Y después revisar rutas, imágenes, warnings y enlaces internos antes de tocar nada serio.

La copia local no vale de nada si no funciona de verdad.

Y si vas a tocar algo delicado -multidioma, rediseño, plugins grandes, migraciones SEO- hacerlo directamente en producción es correr riesgos innecesarios. 

Tienes las herramientas. Son gratis. Y el proceso, aunque no sea automático, se hace en media hora.

Recuerda:

Primero local. Luego pruebas. Después producción. En ese orden.

Como Bale y el golf, pero aplicado a WordPress.

Por cierto, aquí te dejo la continuación de este artículo: cómo optimizar la velocidad de WPLocal.