What to Check Before Changing WordPress DNS

Before changing WordPress DNS, it is important to confirm that the site is ready to move and that every critical service will continue to work after the switch. A DNS update may look like a simple change, but in practice it controls where visitors, email clients, SSL checks, and other domain services are sent. If you change the records too early, too late, or without checking the target hosting environment, you can create avoidable downtime, broken email delivery, certificate warnings, or missing content during propagation.

This checklist explains what to review before you update DNS for a WordPress site, especially during a migration to a new hosting platform, cPanel account, or Plesk environment. It is designed to help you move a live site safely, reduce risk, and make sure the new hosting setup is ready before traffic begins to resolve to it.

Confirm that the WordPress site is fully copied

Before touching DNS, make sure the full WordPress installation exists on the new server. The most common mistake during migration is pointing the domain to the new host while files, database content, or configuration settings are still incomplete.

Check the following items

  • All WordPress files have been transferred, including wp-content, themes, plugins, uploads, and any custom code.
  • The database has been imported successfully and matches the live site.
  • wp-config.php has the correct database name, user, password, and host.
  • Table prefix values are correct if the site uses a non-standard prefix.
  • Custom files outside the standard WordPress structure have been copied if needed.

If you are using a managed hosting platform, check whether the migration tool completed all steps or whether any files were skipped due to permissions, size limits, or timeouts. Large media libraries and WooCommerce stores often need extra verification.

Test the new hosting account before the DNS switch

A DNS change should happen only after you have tested the site on the target server. This allows you to compare the old and new environments before the public domain starts resolving to the new location.

What to verify on the new server

  • The homepage loads correctly.
  • Key pages, posts, and archive pages display as expected.
  • Login works in /wp-admin.
  • Permalinks return the correct pages and do not produce 404 errors.
  • Images, CSS, and JavaScript files load without missing paths.
  • Forms, search, checkout, and any membership functions operate normally.

In many hosting control panels, such as cPanel or Plesk, you can preview the site by using a temporary URL, a hosts file entry, or a staging domain. This is useful because it lets you test the full stack before changing live DNS.

Check the DNS records you actually need to change

WordPress migration often involves changing only some DNS records, not every record for the domain. Before making any updates, identify which services are hosted where. The wrong assumption here can disrupt email, subdomains, or third-party tools.

Common DNS records to review

  • A record or AAAA record for the root domain and www
  • CNAME record for www if it points to the root domain or another host
  • MX records for email delivery
  • TXT records for SPF, DKIM, DMARC, verification, or ownership checks
  • SRV records if used by specific services
  • Subdomain records such as shop, mail, or staging

For many WordPress migrations, only the A record for the domain and the www hostname needs to be updated. However, if your email is also moved or hosted separately, you must be careful not to overwrite MX or TXT records accidentally.

Lower the DNS TTL in advance

If you have access to the domain DNS zone, reduce the TTL before the migration. TTL, or Time to Live, tells DNS resolvers how long to cache a record. A shorter TTL helps the new record take effect sooner after you switch it.

Recommended approach

  • Lower TTL 24 to 48 hours before the planned change.
  • Use a value such as 300 seconds or 600 seconds if your DNS provider allows it.
  • After the migration is complete and stable, you can raise TTL again if needed.

Lowering TTL does not make DNS changes instant, but it can reduce the amount of time users see the old server after the cutover. This is especially useful for active websites with ongoing content updates or online orders.

Confirm the new server IP address and hostname details

Before you edit DNS, verify the exact destination IP address or hostname from the new hosting account. A small mistake here can send traffic to the wrong machine or create a configuration mismatch.

Check these details carefully

  • The correct IPv4 address for the new site.
  • The IPv6 address, if your hosting platform uses one and your DNS zone supports it.
  • Whether the domain should point directly to an IP or to a CNAME target.
  • Whether the control panel has assigned a dedicated IP or a shared IP.

If you are using Plesk or cPanel, the panel may show a web hosting IP, a mail server IP, and possibly a temporary preview host. Make sure you know which value should be used for the public DNS record.

Make sure SSL is ready before traffic arrives

SSL should be in place before or immediately after DNS is changed, especially if the site forces HTTPS or contains login, checkout, or contact form pages. When DNS starts pointing to the new host, browsers will expect a valid certificate on that server.

Review the SSL setup

  • Confirm that a certificate is issued for both the root domain and www if both are used.
  • Check that the certificate is installed on the new hosting account.
  • Verify that auto-renewal is enabled, if supported.
  • Ensure the site will redirect correctly from HTTP to HTTPS.

If the site uses a managed hosting platform, certificate provisioning may happen automatically, but it is still worth checking the status before the DNS switch. A domain that resolves to a new server without SSL can show browser warnings and reduce user trust immediately.

Verify email is not affected by the web migration

DNS changes for WordPress often focus on the website, but the domain may also be used for email. If your email still runs on another service, do not modify MX or related records unless the mail service is also moving.

Email-specific checks

  • Confirm the current MX records and where they point.
  • Preserve SPF, DKIM, and DMARC TXT records unless mail hosting is changing.
  • Check whether mailbox authentication depends on custom hostnames such as mail.example.com.
  • Review any webmail links, autoconfig records, or mail client settings.

It is common for users to migrate the website but leave email on the previous provider. In that case, the DNS zone should be edited with care so that only the web traffic is redirected while mail continues to work unchanged.

Review WordPress-specific settings before the cutover

WordPress can store domain-related values in multiple places. If these values do not match the new environment, the site may load but still behave incorrectly after DNS changes.

Key items to check

  • The site URL and home URL values in WordPress are correct.
  • Hard-coded links in the database are updated if the domain or protocol changes.
  • Plugins that depend on absolute URLs are tested.
  • Cache plugins and server-side cache are cleared.

Search and replace tasks should be done carefully, especially on production databases. If the site uses serialized data, use a migration tool or a method that supports safe URL replacement. This is particularly important for page builders, ecommerce plugins, and membership systems.

Check for CDN, proxy, and security service dependencies

If the domain uses a CDN, reverse proxy, firewall, or security layer, DNS changes may require additional updates. The website may point to the new host, but traffic could still pass through another service that needs its own configuration.

Services to review

  • CDN records and origin settings
  • Proxy services that mask the real server IP
  • WAF or security filters that whitelist the new IP
  • Bot protection or caching rules tied to the old server

Make sure the new host is allowed through any protection layer and that the origin server settings match the migrated site. If you use a CDN, you may need to update origin hostname, SSL mode, or cache rules to avoid stale content or certificate issues.

Check the current DNS zone for hidden records

Some domains have older records that are easy to miss, especially if the DNS zone has been managed over time by different teams or tools. Before you switch the site, scan the full zone for entries that could still affect the domain.

Look for these common issues

  • Old A records for www or the root domain
  • Legacy subdomains still used by plugins or redirects
  • Conflicting CNAME and A records on the same hostname
  • Old TXT verification records that can be left in place safely, or removed if obsolete
  • Wildcard records that might override specific hostnames

A clean DNS review helps avoid surprises after propagation. Conflicting records can lead to inconsistent resolution between devices, browsers, and regions.

Test the site using a hosts file or temporary preview

One of the safest ways to validate the new hosting account before changing public DNS is to test through a local hosts file update or a private preview URL. This lets your browser resolve the domain to the new server while everyone else still sees the current live site.

Why this matters

  • You can test the exact domain name on the new server.
  • You can confirm SSL, redirects, and mixed content issues.
  • You can compare new and old versions side by side.
  • You can spot template, plugin, or PHP compatibility problems early.

This type of test is especially helpful when moving from one hosting control panel to another, because differences in PHP version, caching, or Apache configuration can affect how the site behaves.

Check PHP version, extensions, and server configuration

DNS is only the final step. The new hosting environment must also support the site’s technical requirements. Before switching, confirm that the new account is using the right PHP version and has the necessary modules enabled.

Verify compatibility

  • PHP version matches the site’s needs.
  • Required extensions are installed, such as mysqli, curl, mbstring, or gd.
  • Upload limits are sufficient for media or plugin updates.
  • Memory limits support the theme and plugins.
  • Apache or Nginx configuration works with existing rewrite rules.

If the site uses custom .htaccess rules, check that they were copied and are compatible with the new server stack. A DNS change will expose any server-side misconfiguration immediately.

Prepare a rollback plan

Even when everything is tested, it is sensible to prepare a rollback plan before updating DNS. If the new host has an unexpected issue after the switch, you should be able to restore the old record quickly.

Rollback checklist

  • Keep the old DNS values recorded.
  • Note the time when TTL was lowered.
  • Know who has access to the DNS provider.
  • Keep a backup of the site files and database.
  • Confirm that the old hosting account remains active long enough to revert if needed.

A clear rollback process reduces stress during migration and makes it easier to recover if a plugin conflict, certificate problem, or misdirected DNS record appears after propagation begins.

Step-by-step checklist before changing WordPress DNS

Use this practical checklist immediately before the cutover:

  • Confirm the WordPress files and database are fully migrated.
  • Test the site on the new server using a preview method.
  • Verify the correct destination IP or hostname.
  • Lower TTL in the DNS zone in advance.
  • Check SSL status for the domain and www.
  • Preserve email records if email stays on another service.
  • Review CDN, firewall, and proxy dependencies.
  • Check for conflicting or outdated DNS records.
  • Confirm PHP and server configuration compatibility.
  • Prepare a rollback plan.

What to check after changing DNS

Once you update DNS, do not assume the move is finished. DNS propagation can take time, and you should monitor the website closely during the transition period.

Post-change verification

  • Load the site from multiple networks or devices.
  • Confirm the SSL certificate is valid.
  • Check the homepage, posts, forms, and login page.
  • Verify that images and static assets load correctly.
  • Check that email still sends and receives as expected.
  • Monitor server logs for 404, 500, or permission errors.

If the old server remains active during propagation, you may need to keep both environments aligned for a short period so that visitors are not shown inconsistent content. This is especially relevant for busy WordPress sites and ecommerce stores.

FAQ

How long should I wait before changing WordPress DNS?

Ideally, you should wait until the site is fully copied, tested, and confirmed to work on the new server. If possible, lower TTL 24 to 48 hours before the change, then switch DNS only after you have verified the migration.

Will changing DNS affect my WordPress database?

No, DNS does not change the database itself. It only tells browsers and other services where to find the domain. However, if the new server has the wrong database configuration, the site may appear broken after the switch.

Do I need to change MX records when moving WordPress?

Only if your email is also moving. If email stays on the current provider, leave MX, SPF, DKIM, and DMARC records unchanged. The website and email can be hosted separately.

Can I test the new site before changing DNS?

Yes. You can use a hosts file entry, a staging domain, or a preview URL in your hosting control panel. This is the best way to confirm that the new server is ready before the public domain points to it.

What if DNS propagation is slow?

Propagation time depends on TTL values and caching by resolvers. Lowering TTL in advance helps, but some users may still see the old site for a period. Keep the old hosting active until the majority of traffic has moved.

What is the most common mistake during WordPress DNS changes?

The most common mistake is updating the A record too early, before the new site has been properly tested. Another frequent problem is accidentally changing email-related records when only the website should move.

Conclusion

Changing WordPress DNS is a small technical action with a wide impact. The safest approach is to confirm the new hosting environment first, test the site thoroughly, preserve email and service records, and lower TTL before the cutover. If you work through the checklist above, the migration is far less likely to cause downtime or user-facing errors.

For WordPress migrations in a hosting control panel environment, the key is to treat DNS as the final step, not the starting point. Once the new site is proven ready, the DNS update becomes a controlled switch instead of a risky guess.

  • 0 Users Found This Useful
Was this answer helpful?