{"id":1137,"date":"2026-03-12T17:24:48","date_gmt":"2026-03-12T14:24:48","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1137"},"modified":"2026-08-04T21:56:29","modified_gmt":"2026-08-04T21:56:29","slug":"change-wordpress-urls-after-migration","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/change-wordpress-urls-after-migration\/","title":{"rendered":"Change WordPress URLs After Migration Safely"},"content":{"rendered":"

A staging site has moved from a temporary subdomain to the production domain. The home page looks correct after changing two options, but images, page-builder buttons, widgets, canonical tags, and login cookies still reference the temporary address.<\/p>\n

This guide shows how to identify which URLs actually need changing, update serialized WordPress data safely, and verify the references that are easy to miss after a migration.<\/p>\n

\nTable of contents<\/strong><\/p>\n
    \n
  1. What it means<\/a><\/li>\n
  2. A realistic WordPress example<\/a><\/li>\n
  3. Why it matters and when to use it<\/a><\/li>\n
  4. A straightforward route for beginners<\/a><\/li>\n
  5. The advanced route<\/a><\/li>\n
  6. Risks, common mistakes, backup, and rollback<\/a><\/li>\n
  7. How AIOWS helps: AIOWS Backup Manager<\/a><\/li>\n
  8. Related AIOWS articles<\/a><\/li>\n
  9. Conclusion and recommended route<\/a><\/li>\n
  10. Official sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    What changing WordPress URLs involves<\/h2>\n

    A URL change may affect the public site address, the location of WordPress application files, and absolute links stored in content, metadata, widgets, or plugin tables. The home<\/code> option controls the public address; siteurl<\/code> identifies where WordPress itself is installed. They are usually the same, but they serve different purposes.<\/p>\n

    Many WordPress values are serialized and include the length of each stored string. A raw SQL replacement can change the text without correcting that length and make the value unreadable. DNS, TLS, proxy rules, server redirects, caches, and third-party callback URLs are separate from the database operation.<\/p>\n

    A realistic WordPress example<\/h2>\n

    A staging site moves from preview.example.com<\/code> to the production domain. Updating home<\/code> and siteurl<\/code> fixes the main navigation, but a page builder still stores the preview host in serialized metadata. Images load from the old address, canonical tags disagree with the browser URL, and password-reset links point back to staging. A scoped, serialization-aware replacement is needed for those database values; the mail service callback must be changed in its own configuration.<\/p>\n

    Why it matters and when to use it<\/h2>\n

    Replace stored URLs when the canonical domain, protocol, subdirectory, or installation path truly changed. If only DNS moved to a new server and the public address stayed the same, a database-wide replacement is unnecessary. Diagnose redirect loops separately: an old database value, a reverse proxy, the web server, WordPress, or a CDN can each issue a redirect.<\/p>\n

    A straightforward route for beginners<\/h2>\n
      \n
    1. Back up the destination database and record old URL, new URL, scheme, path, table prefix, network scope, and excluded columns.<\/li>\n
    2. Confirm the intended home and siteurl values first, using a temporary configuration override only when dashboard access must be recovered.<\/li>\n
    3. Run a serialization-aware dry run, review affected tables and counts, then execute the exact replacement without changing GUID values unless a documented case requires it.<\/li>\n
    4. Clear relevant WordPress, object, page, browser, and CDN caches only after the stored values and server routing are correct.<\/li>\n
    5. Crawl representative pages and test media, menus, page-builder content, widgets, REST, login, password reset, canonicals, sitemap, redirects, forms, and callbacks.<\/li>\n<\/ol>\n

      The advanced route<\/h2>\n

      Use WP-CLI search-replace<\/code> or another tool that understands serialized data. Start with a dry run, limit the table scope, review hit counts, and record the exact command, exclusions, output, and exit status. Avoid changing GUID values unless a documented migration case specifically requires it.<\/p>\n