How to Install WordPress Locally

A local WordPress install is the same software running on your own computer. It needs no hosting, no domain and no internet connection. It is the correct place to learn WordPress, develop a theme, test an update that frightens you, and break things without consequence.

It is not a substitute for staging, because it does not match your production server. More on that limit at the end.

Pick your approach

A dedicated app is the right default. It installs PHP, MySQL and a web server, creates the site, and gives you a one-click admin login and often a one-click PHP version switch. If your goal is to have WordPress running in ten minutes, stop reading and use one.

XAMPP or MAMP is the classic route and still the best way to understand what a WordPress host actually provides. Everything below covers this path.

Docker is what you want when local must match production — same PHP version, same web server, same database engine — or when a team needs identical environments.

The manual install, step by step

1. Install the stack. Install XAMPP (Windows, Linux) or MAMP (macOS), start Apache and MySQL from its control panel, and confirm http://localhost shows the welcome page. If Apache will not start, something else owns port 80 — Skype, IIS and other web servers are the usual culprits; change Apache's port to 8080 and use http://localhost:8080.

2. Create a database. Open http://localhost/phpmyadmin, create a database called wordpress_local, and choose the utf8mb4_unicode_ci collation. Note the name; the default local credentials are usually user root with an empty password on XAMPP.

3. Download and place WordPress. Get the archive from wordpress.org and extract it into your web root — htdocs/mysite for XAMPP. The site is then at http://localhost/mysite.

4. Run the installer. Load that URL. WordPress asks for the database name, user and password from step 2, then for a site title and an admin account.

If it cannot write the configuration, create wp-config.php from wp-config-sample.php yourself and fill in:

define('DB_NAME', 'wordpress_local');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');

What else belongs in that file is covered in wp-config.php explained.

5. Turn on debugging immediately. This is the whole point of a local site — you want to see errors, not hide them:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

Details in how to enable WordPress debug mode.

Set it up to be useful

• Match your production PHP version. A site developed on PHP 8.3 that deploys to 7.4 will fail in ways you never saw — this is a common cause of a site breaking after a PHP update.
• Raise the memory limit in wp-config.php, because local machines have plenty and the default causes confusing failures — increasing the memory limit.
• Install WP-CLI, which makes local work dramatically faster.
• Catch email instead of sending it. A local site cannot send mail and will either fail silently or hang. A mail-catching tool shows you what would have been sent.
• Use a real hostname, such as mysite.local, via your hosts file. Working at localhost/mysite in a subdirectory produces path problems that do not exist on the real site.

Copying a live site down

The reliable order:

1. Export the live database and download the files, or use a migration plugin.
2. Import the database locally and put the files in your web root.
3. Point wp-config.php at the local database.
4. Rewrite the URLs — the step everyone forgets:

wp search-replace 'https://example.com' 'http://mysite.local' --all-tables --dry-run
wp search-replace 'https://example.com' 'http://mysite.local' --all-tables

Use wp search-replace, not SQL: it understands PHP serialisation, and a raw replace corrupts serialised options silently.

5. Flush permalinks, then disable anything that talks to the outside world — payment gateways, analytics, backup schedules, and outgoing email.

That last point matters more than it sounds. A local copy of a live store contains real customer data and real order records. Treat it accordingly.

What local cannot test

This is the important limitation, and it is why local is not staging:

• Server configuration — Nginx rules, server-level caching, firewalls.
• Real HTTPS behaviour, certificates and mixed content.
• Email deliverability, which is entirely about the sending server.
• Real performance. Your laptop is faster than your shared host, and there is no network latency.
• Cron reliability, which depends on real traffic or a real system cron.
• CDN and DNS behaviour, which do not exist locally.

Anything in that list has to be verified on a staging copy on the actual host before it goes live.

Common mistakes

• Forgetting the URL rewrite after importing a live database, then wondering why the local site redirects to production.
• A subdirectory install producing path quirks that do not exist live.
• Running a PHP version production does not have.
• Leaving live plugins connected to real payment or email services.
• Treating local as a backup. It is a copy from a moment, not a backup.
• Trying to show a client the local site. It is not reachable; use staging.

Verify

Load the front page, log into the admin, publish a test post and confirm it appears at a pretty permalink, upload an image and confirm it lands in wp-content/uploads, and check that wp-content/debug.log is being written when you deliberately trigger a notice. If all five work, the environment is sound and you can start actually building.