WordPress site URL changed accidentally recovery can feel urgent because one small setting may affect the entire website. The wrong address can create redirect loops, missing images, login failures, or a blank-looking site. In many cases, the files and content remain intact.
This guide explains how to restore the correct address safely. It covers the database, configuration files, hosting tools, redirect rules, cache layers, and follow-up checks. The right path depends on what access still works and where the incorrect URL was saved. WordPress site URL changed accidentally recovery should begin with identifying that source, not with repeated edits.
First, identify what changed
WordPress commonly uses two URL values. The siteurl value identifies where the WordPress core files expect to live. The home value identifies the public address visitors use. They often match, but not always.
An accidental change may affect one or both values. Someone might enter a staging address, add “www,” remove “www,” change HTTP to HTTPS, or include an extra path. Each variation can produce a different symptom.
- Wrong redirect: visitors go to an old, temporary, or unrelated address.
- Login failure: the login page redirects repeatedly or never loads.
- Broken assets: stylesheets, scripts, and images still reference the wrong address.
- Mixed behavior: the homepage works, but admin pages or internal links do not.
Write down the intended canonical address before changing anything. Include the protocol, hostname, and path. For example, decide whether the correct form uses HTTPS, a www hostname, and a subdirectory. Do not guess based only on what one browser displays.
Protect the site before making a repair
Pause automated changes while you investigate. Disable deployment jobs, scheduled search-and-replace tasks, and hosting tools that may overwrite the same settings. Preserve the current state before editing it.
Take a database backup and a copy of the WordPress files if your hosting platform allows it. A backup gives you a rollback option if the first repair exposes a second problem. Review your website backup retention plan if you are unsure which restore point is available.
Also record the visible error, the URL in the browser, and the time of the change. Test in a private browser window. Existing browser redirects and cached resources can make a repaired site appear broken.
Do not use a broad database replacement as your first action. WordPress stores URLs in several places, including serialized data. A simple text replacement can damage serialized values and create a larger recovery job.
Recovery path one: correct the database values
The database is the usual source of the public URL. If you can open a control panel database tool such as phpMyAdmin, select the database used by the affected WordPress installation. Confirm the correct database by checking its table prefix or comparing it with the site configuration.
Open the options table. Its name may not be exactly wp_options because WordPress can use a custom prefix. Find the rows named siteurl and home. Change only their values to the intended full address.
For example, both values might need to change from http://example.test to https://www.example.com. Use the real address for the site. Do not copy this example literally.
Save the change, then test the homepage and login page in a private window. If the dashboard loads, check Settings > General without saving it immediately. Confirm that both displayed addresses match the planned format. This database step is often the central part of WordPress site URL changed accidentally recovery.
Database access can also work through a hosting restore tool. However, restore only the relevant database when possible. Restoring the whole account may remove newer content, orders, uploads, or mail changes.
Recovery path two: use wp-config.php as a temporary control
If database access is difficult, the wp-config.php file can override the stored URL values. Use the hosting file manager, SFTP, or another approved file access method. Download a copy before editing.
Add these definitions above the line that says WordPress has stopped editing:
define( 'WP_HOME', 'https://www.example.com' );
define( 'WP_SITEURL', 'https://www.example.com' );Replace the example address with the verified canonical address. Keep the protocol and hostname consistent. If WordPress lives in a subdirectory, the core URL may need a path while the public URL does not. That situation requires careful verification.
This method is useful for regaining access, but it is often temporary. The database may still contain the wrong values, and some plugins may read those values directly. After the site works, update the database deliberately, confirm the result, and remove the temporary definitions when appropriate.
Check file permissions and ownership after editing. Avoid changing permissions broadly just to make the file writable. If your host provides a configuration editor, use it only after confirming which installation it controls.
Recovery path three: use hosting tools and controlled restores
Many hosts provide a WordPress manager, database editor, backup browser, or command-line access. These tools can shorten recovery, but their labels and behavior vary. Confirm the domain, document root, and database before applying a change.
A hosting WordPress manager may offer a URL repair option. Treat it as a convenience rather than proof that every reference changed. It may update core settings without correcting plugin options, cached pages, hard-coded links, or redirect rules.
If the URL change followed a failed deployment or bulk edit, restore a known-good backup to staging first. Compare the database and files before replacing production. The guide on failed WordPress update recovery explains why controlled restoration is safer than repeated live edits.
When command-line access is available, a technician may use WordPress-aware tools to inspect and replace values safely. Those tools still require a database backup and a review of serialized data. Never run an unreviewed search-and-replace command against production.
Check redirects and server configuration
Correct URL values cannot overcome a redirect that sends visitors elsewhere. Review redirect rules in the hosting panel, CDN, web server configuration, and .htaccess file. Look for rules added during a domain move, HTTPS change, staging setup, or marketing campaign.
On Apache hosting, a malformed or overly broad .htaccess rule can cause loops or unexpected destinations. On Nginx, redirects may exist in the site configuration instead. Ask the host which layer controls redirects before editing server files.
Use a redirect checker or browser developer tools to observe each response. A normal canonical redirect may send HTTP to HTTPS or non-www to www. It should not bounce between two forms. Check the response chain from a private window and from a second network.
If the site redirects to an unfamiliar website, stop treating the event as a simple URL mistake. Preserve evidence and investigate administrator accounts, plugins, theme files, and injected database content. Follow the containment guidance in this WordPress redirect malware investigation.
Clear every relevant cache layer
Cache systems can preserve the wrong address after the database is fixed. Clear caches in a deliberate order, starting with the application and ending with the visitor’s browser.
- Clear the WordPress caching plugin or hosting page cache.
- Purge the CDN cache if the domain uses one.
- Clear server-side object caching when the host provides that option.
- Test without browser extensions, then clear browser cache if needed.
Some caches store redirect responses. A browser may therefore continue following an old redirect even after the server responds correctly. Test with a private window and a command-line request where practical.
Do not confuse DNS caching with page caching. DNS controls which server a hostname reaches. Page caches store responses from that server. If the domain points to the wrong host, a WordPress database edit will not fix the routing problem.
After the immediate recovery, review the official WordPress performance guidance. It explains why caching and optimization require measurement rather than indiscriminate cache changes.
Run post-recovery checks
Once the correct address loads, test the site as a visitor and as an administrator. Use a private window first, then test from another device or network.
- Open the homepage, several pages, and a representative post.
- Sign in and sign out of the WordPress dashboard.
- Check images, stylesheets, scripts, forms, and downloadable files.
- Test menus, search, pagination, and important calls to action.
- Confirm that HTTPS shows no certificate or mixed-content warning.
- Review canonical links, sitemap settings, and robots controls.
- Check web server and application logs for repeated redirects or errors.
Inspect page source or browser network requests for the old hostname. A few historical links may be intentional, but current assets and canonical URLs should use the planned address.
If the site changed domains, update integrations separately. Payment services, analytics, webhooks, SMTP settings, security plugins, and external APIs may each store an allowed URL. Record every change so another administrator can understand the final state.
Prevent another accidental URL change
Limit who can edit production settings, and use separate staging and production credentials. Require a backup before domain, HTTPS, or database changes. Keep the canonical URL documented in the hosting account and deployment notes.
Consider monitoring the homepage, login page, certificate, and redirect chain. Alerts should lead to human review, not automatic database edits. Automated remediation can make a small mistake harder to unwind.
Finally, define a recovery plan with the site owner. It should identify the host, database, backup location, DNS provider, CDN, and person authorized to approve a restore.
When to request help
If you lack database access, see a redirect loop after editing, or suspect a compromise, pause before making more changes. WordPress site URL changed accidentally recovery may involve several connected layers, so Tech Rescue Ops LLC can help trace the URL across WordPress, hosting, redirect, and cache systems, then verify the result with a controlled recovery plan.