Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →If WordPress uses your server’s IP address in post links, correct the site’s canonical URL settings first, then remove old IP references, regenerate rewrite rules, and verify DNS and web-server configuration. The IP can be stored in WordPress’s home and siteurl options, forced by WP_HOME or WP_SITEURL in wp-config.php, embedded in database content, or made canonical by the server itself. Fixing only one visible link will not repair all four sources.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Why WordPress is showing an IP address
WordPress builds most front-end URLs from two options:
As an Amazon Associate I earn from qualifying purchases.
Recommended Free Tools
siteurl(shown as WordPress Address (URL)) identifies where the WordPress core files are installed.home(shown as Site Address (URL)) identifies the public address visitors should use.
If either value contains an IP address, WordPress can generate IP-based links for posts, pages, feeds, canonical tags, stylesheets and scripts. A constant in wp-config.php takes precedence over the database, so changing the values in the dashboard has no lasting effect while that override remains.
Migration can also leave the old address in post content, widgets, theme settings, serialized options, attachment metadata or redirect rules. Finally, a correctly configured WordPress installation can still redirect to an IP when DNS points elsewhere or the web server’s virtual host treats the IP as the canonical host.
#1 Best Overall
Before you change anything
URL changes affect every request, so prepare a rollback path.
- Back up the database and files. Keep a downloadable database export and a copy of
wp-config.php, themes, plugins and uploads. Preserve any custom rewrite or redirect rules in.htaccessor the server configuration. - Keep the permalink structure unchanged. Repairing the host name is separate from changing dates, categories or post-name formats. A structure change creates a new redirect and SEO problem.
- Confirm the intended domain and scheme. Decide whether the canonical address is
https://example.comorhttp://example.com. Do not mix schemes while repairing the host name. - Confirm DNS and the virtual host. The domain must resolve to the server that actually hosts this WordPress site, and Apache or Nginx must accept that domain for the correct site.
- Record the old IP. You may need it for a complete search-and-replace and for identifying stale redirects.
Fix the URLs in the WordPress dashboard
Use this method when you can sign in as an administrator and no configuration constant is overriding the database.
- Open Settings → General.
- Set WordPress Address (URL) to the canonical domain and scheme, for example
https://example.com. - Set Site Address (URL) to the same canonical address unless WordPress is intentionally installed in a subdirectory. If it is installed in a subdirectory, preserve that path in the WordPress Address while using the public path for the Site Address.
- Save the changes. WordPress may sign you out; sign in again at the new domain.
These fields update the siteurl and home rows in the options table. They do not rewrite old IP strings inside posts, menus, widgets or plugin settings, and they do not repair DNS or server redirects. Continue with the database cleanup and rewrite steps below.
If wp-admin is inaccessible
Temporarily override the URLs in wp-config.php
Add the following lines above the comment that says to stop editing, replacing the example domain with the real canonical address:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Use this as an access-and-recovery measure, not as the final database fix. These constants override the values in wp_options; the dashboard fields may appear locked or may seem to save without changing the effective URL. Once the database is corrected, remove the temporary constants and test again. Keep the file’s PHP syntax and quotes intact, and make a backup before editing.
Update home and siteurl directly in the database
Use your database administration tool or a documented SQL console. The table prefix may not be wp_, so substitute the prefix used by this installation:
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallUPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name IN ('home', 'siteurl');Run the update only after checking the selected database and the existing option values. A wrong database or prefix can make the site appear unchanged or damage another installation. If the site uses a subdirectory, preserve that path in the appropriate value. After the update, remove any temporary WP_HOME and WP_SITEURL definitions so the database values become authoritative.
Replace IP addresses stored elsewhere
Correcting home and siteurl changes the URLs WordPress generates, but old IP strings can remain in content and settings. Typical locations include post and page HTML, navigation menus, widgets, theme customizer values, plugin options, attachment URLs and redirect rules.
Use a serialization-aware tool rather than a blind text replacement. WordPress options and some plugin data are stored as PHP serialized values; changing string lengths without updating serialization metadata can corrupt those values.
Use WP-CLI when available
From the WordPress installation directory, begin with a dry run:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorswp search-replace 'http://OLD-IP' 'https://example.com' --dry-runReview the reported tables, columns and number of replacements. If the old site also used HTTPS, or if URLs appeared without a scheme, run separate, carefully reviewed replacements for those exact forms. When the dry run is correct, execute the replacement without --dry-run:
wp search-replace 'http://OLD-IP' 'https://example.com'WP-CLI’s search-and-replace command handles PHP serialized data and does not change primary-key values. That makes it safer for WordPress tables than a raw SQL string replacement. It still changes real data, so retain the backup and avoid replacing a short IP fragment that could occur as part of an unrelated value.
On a multisite network, establish the scope before running the command. Network-wide data, individual site tables and domain-mapping settings may contain different hosts. A replacement intended for one site can affect every site if run with network-wide scope; a single-site replacement can leave other mapped domains untouched. Test on a staging copy when the network is large or the old IP is shared by several sites.
Check content that search-and-replace may not cover
- Review theme and plugin fields that contain full URLs, especially logo, API callback, webhook and image settings.
- Inspect custom JavaScript and CSS for absolute IP references.
- Check scheduled jobs, import feeds and external integrations that may call the old address.
- Search server configuration, deployment files and redirect maps; database cleanup cannot remove an IP redirect defined outside WordPress.
Flush WordPress permalink rules
After changing the host name, regenerate rewrite rules without changing the selected structure.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Open Settings → Permalinks.
- Leave the current structure selected.
- Click Save Changes, even if you made no visible change.
Saving this screen flushes WordPress’s rewrite rules and commonly rebuilds .htaccess on Apache. It does not replace IP strings in the database, change DNS or fix a server-level redirect.
With WP-CLI, wp rewrite structure --hard can update the permalink structure and write the hard rules where supported. Use it only when you understand the existing structure and have preserved custom rules; a command that overwrites a customized file can remove necessary redirects or security directives.
Make the web server serve the domain
Apache
Apache must have a virtual host whose ServerName (and any intended aliases) includes the domain. The site’s document root must point to this WordPress installation. Pretty permalinks also require mod_rewrite and permission for directory-level overrides if the site relies on .htaccess. WordPress’s standard front-controller rules route unknown paths to index.php; if those rules cannot run, post URLs may return 404 errors even after the host name is fixed.
Check that the active virtual host is the one receiving requests for the domain, that the IP-only host is not issuing a forced redirect, and that the .htaccess file has not been replaced with an incomplete copy. Preserve custom rules when regenerating it.
Rank #4
Nginx
Nginx does not read .htaccess. The server block for the domain must list the correct server_name, use the WordPress document root and pass non-file requests to the front controller, normally index.php. Configure the equivalent rewrite and PHP handling in the server configuration, then reload Nginx using the procedure appropriate to your host. Saving the Permalinks screen alone cannot create Nginx rules.
Clear caches and test the complete request path
Old redirects can survive in several cache layers. Purge the page cache, object cache, reverse proxy or CDN cache, and any host-level cache you control. Then use a private browser window so an old permanent redirect is not reused from the browser cache.
Test more than the home page:
- The home page at the canonical domain and scheme.
- Several existing posts and pages, including a URL copied before the repair.
- Category, tag, author, date and feed URLs if the site uses them.
- Images, stylesheets, scripts and downloadable files.
- The login URL, password reset flow and an authenticated dashboard session.
- Both HTTP and HTTPS behavior, including the intended single redirect to HTTPS if HTTPS is canonical.
- An IP request, which should not become the public canonical address unless you deliberately retain a controlled redirect.
View the page source and browser network requests if a redirect persists. Search for the old IP in canonical tags, og:url, JSON-LD, image sources and script URLs. A command-line header check can reveal which layer redirects first:
curl -I http://example.com/sample-post/Run equivalent checks for the old IP and the HTTPS version. The first Location header identifies whether WordPress, the web server, a proxy or a cache is making the decision.
Which repair method should you use?
| Method | Dashboard access | Serialization safety | Rollback | Multisite scope | Required privileges |
|---|---|---|---|---|---|
| Settings → General | Required | Safe for the two URL options; does not search other tables | Restore the two values or use the backup | Usually one site at a time | Administrator access |
wp-config.php constants |
Not required | Does not alter stored data | Remove the constants | Depends on the configuration file and network setup | File access |
| Direct database update | Not required | Safe for the two plain option values; unsafe for broad serialized replacement | Restore the database backup | Must select the correct site tables | Database access |
| WP-CLI search-replace | Not required | Handles PHP serialized data | Restore the backup or reverse a reviewed replacement | Can be targeted or network-wide; verify scope | Shell and WordPress file access |
Use the dashboard for a straightforward single-site correction. Use a temporary configuration override when the dashboard is unreachable. Use WP-CLI for a migration with many stored URLs, provided you can make and verify a backup. Treat direct SQL as a narrow option-value repair unless you have a serialization-safe process.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Diagnose common failure patterns
The dashboard fields keep reverting to the IP
Look for WP_HOME and WP_SITEURL in wp-config.php, an environment variable injected by the host, or a deployment script that rewrites the file. Remove or update the override, then set the database values. Also check whether a staging or container configuration is being restored after each deployment.
Best Value
The home page uses the domain but posts still use the IP
The two URL options may be correct while old absolute links remain in post content, menus or plugin settings. Run a dry-run WP-CLI search for each old URL form, inspect the results, perform the replacement, and then clear caches. If only certain templates are affected, inspect theme files and custom fields for hard-coded URLs.
The domain redirects to the IP before WordPress loads
This indicates DNS, the virtual host, a load balancer, a reverse proxy or a server redirect rather than a WordPress option. Confirm the domain’s DNS records, the active virtual host’s host-name directives and any HTTP-to-HTTPS or IP-to-domain rules. Check response headers to identify the first redirecting layer.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Post URLs return 404 after the host change
Save the Permalinks screen to flush rules. On Apache, verify mod_rewrite and directory override permissions. On Nginx, add or restore the server-level front-controller rule because .htaccess is ignored. Confirm that the virtual host points to the same document root and that the rewrite file was not overwritten without its custom directives.
Some assets still load from the IP or trigger mixed-content warnings
Search the database for both http://OLD-IP and https://OLD-IP, then inspect theme, plugin and custom-code settings. If the domain is HTTPS, replace insecure HTTP domain references where appropriate and purge caches. Do not replace protocol-relative or third-party URLs blindly; review each match before changing it.
The site loops between the IP and domain
Conflicting canonical rules commonly cause loops: one layer redirects the domain to the IP while another redirects the IP back to the domain, or WordPress believes the request is HTTP while the proxy reports HTTPS. Remove duplicate redirects, make one layer authoritative for HTTPS, and ensure proxy HTTPS headers are handled consistently. Test with a private window and header checks after each change.
Migration and multisite cautions
Moving WordPress to another server or location does not require reinstalling it, but the host name, database values, stored content and server rules must agree. During a migration, keep the old permalink structure and plan redirects separately from the URL correction. If the old IP served several applications, replace only the references belonging to this WordPress site.
Multisite installations add network and per-site domains. Check the network’s main URL, each site’s home and siteurl, domain-mapping settings and any sunrise or proxy configuration. Run replacements with an explicitly chosen scope and verify one site before changing the rest. A network-wide backup is essential because a mistaken host replacement can affect every site simultaneously.
When you should involve your hosting provider
Ask the provider to help when you cannot edit the virtual-host configuration, enable Apache rewrite support, reload Nginx, change DNS records or purge a managed cache. Give them the exact canonical domain, the old IP, the intended HTTPS behavior and a sample URL that redirects or returns 404. A managed WordPress service can perform these server-level changes, but you should still keep your own database and file backups and verify the resulting URLs yourself.
Quick Recap
Final verification checklist
- WordPress URLs: both
homeandsiteurlshow the canonical domain and scheme. - Overrides: no stale
WP_HOMEorWP_SITEURLvalue forces the IP. - Database: posts, menus, widgets and relevant settings contain no unintended old-IP URLs.
- DNS and host: the domain resolves to the intended server and the correct virtual host answers.
- Rewrites: permalink rules are flushed; Apache or Nginx handles front-controller requests.
- Redirects: HTTP/HTTPS and old-address behavior are intentional and do not loop.
- Caches: page, object, proxy and browser caches have been cleared or allowed to expire.
- Testing: posts, pages, media, feeds, login, source HTML and network requests all use the expected domain.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
