Bringing a production WordPress site into local development takes more than copying the database and uploads. Domains, caches, settings, generated files, and serialized data can leave an apparently correct copy that only half loads or fails in hard-to-trace ways. Importing a WordPress site isn't copying it. It's rebuilding its environment without dragging along the original's problems.
The database isn't just text
One of the classic mistakes when moving WordPress is replacing the old domain with the new one using a direct search-and-replace on SQL. Sometimes it works. Sometimes it breaks serialized data. WordPress and many plugins store settings in serialized structures that also record the length of each value. If we swap a URL for one of a different length without respecting that structure, the data stops being valid.
That's why it's worth using tools that understand how WordPress stores those values. WP-CLI, for example, lets you run a search-replace that respects serialized data. Changing the domain stops being a text operation and becomes a data operation.
Uploads are the easy part
In most cases, copying wp-content/uploads isn't much of a mystery. The problem shows up when the site depends on generated files, such as Elementor CSS or caches.
The same applies to thumbnails, plugin-compiled assets, temporary files, and settings with absolute paths. Not everything inside wp-content should be copied as-is: some files should come across, some should be regenerated, and others should stay in production.
Plugins have context too
A local site doesn't need to behave exactly like production. Caching, security, CDN, backup, or email-sending plugins can create unnecessary problems in development. WP Rocket, for example, can leave files and settings meant for production that add nothing locally. Other plugins might try to connect to external services, run syncs, or send real emails.
After importing, it's worth reviewing what should stay active. A local copy doesn't have to be a blind replica. It has to be a safe environment to work in.
Elementor needs extra attention
On sites built with Elementor, moving the database isn't always enough. The plugin generates CSS and other files based on the stored configuration. After changing domain or environment, you may need to regenerate those files to avoid stale styles, broken references, or components that look broken without actually being broken.
Often the site "imported fine." What stayed stale was the generated layer on top.
Production and local shouldn't share external services
This point is easy to forget. An imported WordPress site can keep:
- API keys
- SMTP credentials
- Webhooks
- CRM integrations
- Analytics services
- Scheduled tasks
- Third-party endpoints
If we spin up the local site as-is, some of those connections might keep working. That means a local test could create real data, send emails, trigger automations, or modify information in an external system. Before starting to work, it's worth knowing which connections exist and which ones need to be blocked or replaced.
The local domain should be predictable
Every project should have a stable local URL. Something like:
https://my-site.localhost seems like a small detail, but it helps make the environment repeatable. If we also use valid HTTPS, we avoid differences from production around secure cookies, redirects, mixed content, and services that expect an encrypted connection. The closer the basic behavior between local and production, the fewer surprises show up later.
Importing should be a repeatable operation
If copying a site requires a mental checklist of fifteen steps, sooner or later someone will forget one. The operation includes exporting, creating the database, and copying files, among other tasks.
You also need to change the domain, preserve serialization, disable caching, regenerate CSS, block email, and review external services. All of that can be documented, and much of it can be automated.
The goal isn't just saving time on the first import. That repeatable workflow is also part of a reliable WordPress environment on WSL2. It's being able to do it again six months later without depending on remembering exactly what you did last time.
A local site should be ready to break
That's part of the point. Local is where we can update a plugin, tweak an integration, change data, or test a migration without fear of affecting real users. But for that to be true, the copy has to be isolated from production and complete enough for the tests to actually mean something.
We don't need a perfect replica. We need a useful one. Bringing the site over is the first step. The import is complete when the copy is isolated, repeatable, and useful for testing changes with confidence.