Free tools Windows power users keep installed
One-click scans. No signup required.
If WordPress generates links with a server IP address instead of your domain, correct the site’s canonical URL at every layer that can supply it. Check DNS and the server’s virtual host, set both the WordPress Address and Site Address, remove or update any WP_HOME and WP_SITEURL overrides, replace old IP strings stored in the database, then regenerate rewrite rules. Saving the Permalinks screen alone will not remove IP addresses embedded in content or configuration.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
A permalink is the web address used to link to WordPress content. When that address is built from an IP, the problem is usually a stale home or siteurl value, a configuration constant, hard-coded URLs left after migration, or a web server that still treats the IP as canonical.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Identify which layer is producing the IP
Start by comparing the behavior of the homepage, an older post, an image, and the login page. The pattern usually points to the layer that needs correction.
| What you observe | Most likely location of the old IP | First check |
|---|---|---|
| The homepage and every generated link use the IP | WordPress home/siteurl values or a configuration override |
Settings → General, then wp-config.php |
| The homepage uses the domain but posts or media use the IP | URLs saved in post content, widgets, theme settings, or other database fields | A serialized-data-aware search and replacement |
| The domain opens but pretty URLs return 404 errors | Rewrite rules, Apache mod_rewrite, or Nginx server configuration |
Save Settings → Permalinks and inspect the server rewrite setup |
| The domain redirects back to the IP | DNS, the virtual host, a server redirect, a cache, or an old canonical setting | DNS records, virtual-host configuration, and response redirects |
Do not change the permalink structure while repairing the host name. A structure change creates a separate redirect and search-engine problem and can obscure whether the domain repair worked.
#1 Best Overall
Back up before changing URLs or rewrite files
Make a current backup of the WordPress files and database before editing URL values, wp-config.php, or .htaccess. Keep a copy of any custom rewrite or redirect rules in .htaccess; the standard WordPress rules may not be the only directives your site needs. A backup gives you a rollback if a replacement affects an unexpected table or a rewrite edit causes a loop.
- Save a database dump that can be restored independently of the files.
- Copy the complete WordPress directory, including
wp-config.php, themes, plugins, uploads, and.htaccess. - Record the current permalink structure and the current values of
homeandsiteurl. - If a host provides snapshots, retain one from immediately before the change.
Confirm DNS and the server accept the domain
WordPress cannot make the domain canonical if the domain does not reach the intended server. Confirm that the domain’s DNS records resolve to the server hosting this WordPress installation. If both IPv4 and IPv6 records exist, check that each points to a working endpoint or remove an incorrect record.
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 →Repair Windows errors before they cause bigger problemsFix Now →The web server must also have a virtual host (Apache) or server block (Nginx) that accepts the domain and routes it to this installation. A request can reach the correct IP yet still be served by a default site that redirects to the IP. The host name configured at the server should match the domain and its www/non-www choice.
Complete HTTPS setup before selecting an HTTPS canonical URL. The certificate must cover the chosen host name, and the server must be able to serve that name over HTTPS. If HTTP is the canonical scheme, use that consistently instead; mixing schemes can cause redirects or an administration login loop.
When WordPress is running on a cloud instance, associate the domain with the instance address and configure the web server for that host. A correct DNS record by itself does not create the required virtual-host mapping.
Change both WordPress URL settings in the dashboard
If you can reach the dashboard, this is the least invasive correction for the two primary URL options.
- Sign in to WordPress.
- Open Settings → General.
- Set WordPress Address (URL) to the canonical domain and scheme. This is the
siteurloption and identifies where the WordPress core files are located. - Set Site Address (URL) to the canonical domain and scheme. This is the
homeoption and identifies the public address visitors use. - Save the changes, then open the dashboard again using the domain rather than the IP.
Use the exact same host spelling and scheme that your server is configured to serve. If your site intentionally uses different locations for its core files and public address, preserve that distinction; otherwise, set both fields to the same canonical domain.
Changing these fields does not rewrite old text in posts, widgets, theme options, or plugin data. It also does not regenerate Apache or Nginx rules. Those tasks are handled separately below.
Fix the values when wp-admin is inaccessible
Use a temporary wp-config.php override
If the IP causes a redirect loop or prevents login, define the canonical values in wp-config.php so WordPress can load on the domain:
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Replace the example host and scheme with your actual canonical values. WP_HOME and WP_SITEURL override the corresponding database values, so they can restore access even when the rows still contain the IP. Treat this as a temporary recovery measure: once the database values are corrected, remove the constants or they will continue to override future edits made in Settings → General.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Edit the home and siteurl rows
As an alternative, edit the database directly with the database tool supplied by your host. In the WordPress options table (often named wp_options, although the installation may use a different prefix), locate the rows whose option names are home and siteurl. Replace the IP-based values with the canonical domain and scheme, preserving the rest of each value. Change both rows in the same maintenance window.
Do not leave conflicting values in the file and database. If a WP_HOME or WP_SITEURL constant remains, WordPress will keep using it even after the rows are correct. Remove the temporary constants only after confirming that the domain loads and the dashboard remains accessible.
Replace IP addresses stored throughout the database
After the two URL options are fixed, search for the old IP in content and settings. Posts, pages, image fields, widgets, theme options, and plugin settings may still contain complete links such as http://OLD-IP. Those links can make individual pages or media requests continue to expose the IP even though the homepage is correct.
For a site with shell access, use WP-CLI’s search-replace command. Run a dry run first:
Recommended Free Tools
wp search-replace 'http://OLD-IP' 'https://example.com' --dry-runReview the reported tables, fields, and replacement count. If the preview is appropriate, run the same command without --dry-run:
wp search-replace 'http://OLD-IP' 'https://example.com'Use the actual old scheme, IP, and canonical scheme in your command. If the site contains another old form, such as the same IP under a different scheme, run a separate reviewed replacement for that exact form rather than making a broad, blind substitution.
WP-CLI states that its search-replace operation intelligently handles PHP serialized data and does not change primary-key values. That matters because a raw text replacement can corrupt serialized option or metadata values. Keep the database backup until the site has been tested and verified.
Multisite caution
On a multisite installation, identify whether the IP appears in the network’s domain settings, an individual site’s options, or shared content before running a replacement. A network-wide command can affect every site, while a site-level correction may leave another site generating the old host. Confirm the intended scope in the dry-run report and take a network backup first.
Regenerate permalink rewrite rules
Once the host values and stored URLs are corrected, regenerate the rewrite rules without changing the selected structure.
- Open Settings → Permalinks.
- Leave the existing permalink structure selected.
- Click Save Changes, even if you did not alter the selection.
- Open a post and a page using their normal pretty URLs.
Saving this screen flushes and rebuilds WordPress’s rewrite rules. It does not search the database for IP strings, so perform the database cleanup separately.
With WP-CLI, wp rewrite structure --hard can update the structure and write the corresponding .htaccess rules. Preserve your backup and custom directives before using a hard rewrite operation.
Rank #4
Check Apache or Nginx rewrite configuration
Apache
Apache needs mod_rewrite enabled for normal WordPress pretty permalinks. The site directory must also permit the relevant .htaccess directives through its override policy. If the module is disabled or overrides are not allowed, the homepage may work while post URLs return 404 errors after the domain is corrected.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Ask the server administrator or hosting provider to verify the virtual host, mod_rewrite, and .htaccess permissions. Do not replace custom redirect rules with a default WordPress block without first saving them.
Nginx
Nginx does not read .htaccess. Its equivalent front-controller rules must be present in the server configuration, and the server block must point the domain to the correct WordPress document root. A WordPress dashboard save cannot create or repair those Nginx rules.
Have the administrator update the Nginx configuration, test it, and reload the service. If you cannot edit virtual-host configuration or enable rewrite modules, a managed WordPress provider or server administrator may need to perform this part.
| Server | Where rewrites are controlled | Typical owner of the change |
|---|---|---|
| Apache | .htaccess and mod_rewrite, subject to override permissions |
Site administrator or host with Apache access |
| Nginx | Server-block configuration and front-controller rules | Server administrator or hosting provider |
Clear caches and test every important URL
Old redirects can survive in page caches, reverse proxies, or a browser. Purge the caches you control after the URL and rewrite changes, then test in a private browser window.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problems- Open the homepage using the canonical domain.
- Open several existing posts and pages, including an older URL.
- Load representative media files and inspect their addresses.
- Sign in and sign out through the domain.
- Test the selected HTTP or HTTPS scheme and confirm that redirects end at the canonical host.
- View the page source or generated HTML if a redirect still points to the IP.
If the IP remains in generated HTML, search the database again and inspect theme, widget, and plugin settings. If the browser is redirected before WordPress renders anything, inspect DNS, the virtual host, server redirects, and cache rules instead.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choose the repair method that fits your access
| Method | Dashboard access | Serialization safety | Rollback and scope | Required privileges |
|---|---|---|---|---|
| Settings → General | Required | Changes only the two URL options; it does not perform a database-wide replacement | Easy to reverse by entering the previous values; affects the current site’s URL options | WordPress administrator access |
wp-config.php plus database rows |
Not required | Direct edits to home and siteurl avoid a broad replacement, but manual database changes do not provide WP-CLI’s serialized-data handling |
File and database backups provide rollback; temporary constants override database values until removed | File and database access |
| WP-CLI search-replace | Not required | Handles PHP serialized data and preserves primary-key values | Dry-run preview and database backup support rollback; replacement scope is defined by the command and installation | Shell access and a working WP-CLI installation |
For most migrations, use the dashboard or direct URL-row correction for the canonical values, then WP-CLI for reviewed content replacement. If you lack shell or server access, provide the backup and exact old and new URLs to the host or administrator rather than attempting an unreviewed SQL-wide replacement.
Best Value
Common failure modes and precise fixes
The homepage is correct, but every post still shows the IP
The main URL options are probably fixed, while old links remain in post content, menus, widgets, media metadata, or plugin settings. Run a dry-run WP-CLI replacement for the exact old URL, review the result, execute it, and then clear caches.
The dashboard keeps redirecting between the IP and domain
Check for a mismatch between home, siteurl, WP_HOME, and WP_SITEURL. Confirm that the selected scheme matches the certificate and server redirects. Remove temporary constants after the database rows are corrected.
Pretty links return 404 while the homepage works
Save Settings → Permalinks to flush rules. If the problem continues, verify Apache mod_rewrite and override permissions, or have the Nginx administrator install the equivalent front-controller configuration.
Only images or downloads use the IP
Those URLs are likely stored in content or metadata rather than generated from the current home value. Search for the old IP with a dry run, replace the reviewed matches safely, and test media URLs after cache clearing.
The IP returns after a successful replacement
Inspect the server’s canonical redirect and virtual-host settings, then check for an old cache. If the generated HTML contains the IP again, identify which database field or configuration file is recreating it. A permalink save cannot correct a server redirect or an untouched hard-coded value.
Migration details that prevent a second URL problem
Moving WordPress to a new server or a different location does not require reinstalling it. The safe sequence is to back up, make DNS and virtual-host changes, correct the two WordPress URL options, replace stored IP references with serialization-aware tooling, regenerate rewrites, and test before removing the old endpoint.
Keep the existing permalink structure during the host-name repair. If you also want to change dates, categories, or another URL pattern, treat that as a separate migration with its own redirect map and testing plan. Combining both changes makes it difficult to distinguish a host-name error from a missing redirect.
Retain custom rewrite and redirect rules during the move. A new default .htaccess block or Nginx configuration may omit rules for legacy paths, downloads, or application routes that are unrelated to WordPress’s standard front controller.
Quick Recap
Final verification checklist
- DNS resolves the domain to the intended server.
- The Apache virtual host or Nginx server block accepts the domain.
homeandsiteurlcontain the canonical domain and scheme.- No temporary
WP_HOMEorWP_SITEURLconstant conflicts with the database. - A dry-run search found and reviewed remaining old URLs.
- Serialized data was replaced with a serialization-aware method.
- The existing permalink structure was saved without being changed.
- Apache or Nginx rewrite handling is active.
- Caches were cleared and the homepage, posts, pages, media, login, HTTPS, and redirects were tested.
- The old IP no longer appears in generated links, page source, or final redirect locations.
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.
