You’re at the last step of a migration. The new platform is ready, SSL is pending, and the DNS instructions look simple enough. Add an A record or use a CNAME. That choice looks minor until the cutover starts and something odd happens: email verification fails, checkout feels slower, or the edge layer isn’t shielding the origin the way you expected.
Many WordPress and WooCommerce teams get tripped up. They treat DNS as a one-time setup task instead of an operational control point. The site isn’t always “down” when DNS is wrong. It’s often just unstable, harder to secure, and leads to a subtle rise in running costs.
Table of Contents
- The DNS Choice That Can Make or Break Your Migration
- The Core Mechanic A Record vs CNAME Lookups
- Technical Comparison Where the Differences Matter
- Real-World Use Cases for WordPress and CDNs
- The Onboarding Checklist Migrating DNS Without Downtime
- Common Pitfalls and Troubleshooting Tips
The DNS Choice That Can Make or Break Your Migration
A common migration pattern goes like this. A store owner moves from a basic host to an edge-backed setup because login abuse is spiking, fake orders are getting through, and cache misses are pushing too much traffic into PHP and MySQL. The platform asks for DNS changes. Someone sees “A record” and “CNAME,” picks one fast, and assumes it’s interchangeable.
It isn’t.
Your DNS choice affects how the root domain resolves, how flexible the setup is when infrastructure changes, and whether other records can coexist cleanly. For WordPress, that shows up as more than a naming detail. It affects whether the edge can sit in front of the site cleanly, whether email-related records stay intact, and how predictable the cutover will be.
If you manage WooCommerce, this matters even more. Checkout is sensitive to delay, and operational mistakes don’t always fail loudly. A bad DNS decision can leave the storefront online while background problems pile up: certificate renewal friction, verification issues, or traffic reaching places it shouldn’t.
DNS mistakes rarely look dramatic at first. They usually show up as slow checkouts, flaky validation, and origin traffic that should never have reached WordPress.
Agency owners run into a second problem. A setup that feels convenient for one domain becomes fragile across twenty or fifty. What works in a quick test environment can become painful when client mail records, subdomain sprawl, and future migrations all have to coexist.
The right choice depends on what you’re pointing, how much control you need, and whether the target changes underneath you. For most production WordPress environments, that means thinking in terms of root domain versus subdomain, not just “which one works.”
The Core Mechanic A Record vs CNAME Lookups
The easiest way to understand a record vs cname is to stop thinking about DNS as a settings page and start thinking about request path.
An A record is direct. A CNAME adds another hop. That simple difference explains most of the main trade-offs.
A record is direct
An A record maps a domain name straight to an IPv4 address. Resolver asks a question, gets the address, and moves on. There’s no alias to chase.
That directness is why A records are usually the cleanest option when you need predictability. Fewer moving parts means fewer places for resolution to get delayed or confused. In WordPress terms, that matters most on the main domain where you want the least ambiguity.
Operationally, A records feel more manual because they tie you to a specific destination. If the underlying infrastructure changes, someone has to update the DNS. That’s not always bad. It gives you explicit control, which many teams prefer for apex records and tightly managed environments.
Practical rule: If the hostname is your main domain and several critical records need to live there, direct mapping is usually the safer shape.
A short explainer helps here:
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/ZXCQwdVgDno" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>CNAME is an alias
A CNAME doesn’t point to an address. It points to another hostname. The resolver then has to look up that target to get the final destination.
That alias model is useful when a provider manages changing infrastructure for you. If the service shifts traffic behind the scenes, your DNS doesn’t need to change as long as the canonical hostname remains valid. This is why CNAMEs show up so often on www, shop, blog, staging domains, and CDN-connected hostnames.
The extra flexibility comes with trade-offs:
- More resolution steps: The client has to follow the alias before reaching the final address.
- Less coexistence: A hostname that is a CNAME can’t also carry unrelated records at that same label.
- More hidden complexity: Long chains make troubleshooting harder because the visible record isn’t always the actual endpoint.
Teams often misread the problem. They see “alias” and think “simpler.” In production, aliasing is only simpler when the hostname is the right one for it.
For WordPress, the practical takeaway is straightforward. Use direct records where you need stability and record coexistence. Use aliases where provider-managed flexibility is the bigger win.
Technical Comparison Where the Differences Matter
The big DNS arguments usually happen in the wrong place. People talk about A records and CNAMEs as if they’re abstract preferences. They’re not. They shape what you can place at a hostname, how fast resolution happens, and how easy the environment is to operate months later.
A records map a domain directly to an IPv4 address with a single lookup, while CNAMEs alias one domain to another and require at least two lookups. ICANN standards prohibit CNAMEs at the apex because they conflict with essential records like MX and TXT, which is why root domains typically need A records during onboarding to edge platforms. Real-world benchmarks cited by Valimail’s breakdown of A records and CNAMEs note that A records resolve about 20 to 50ms faster in real scenarios.
A Record vs CNAME Key Differences
| Attribute | A Record | CNAME Record |
|---|---|---|
| Target | Direct IPv4 destination | Another hostname |
| Lookup path | Single lookup | At least two lookups |
| Root domain use | Works at apex | Not suitable at apex where other records must coexist |
| Record coexistence | Can live alongside other required records | Blocks coexisting records on the same hostname |
| Performance shape | More direct | Adds alias resolution overhead |
| Infra changes | Requires manual DNS update if target changes | Follows provider-managed target changes |
| Best fit | Main domain, controlled routing, multi-record hostnames | Subdomains tied to SaaS, CDN, or managed services |
What matters in production
The apex rule is the one that causes the most damage because it breaks things outside the website itself. When someone tries to force a CNAME onto the root domain, the website setup might look fine at first, but mail and verification records become the casualty. That’s how teams end up “fixing performance” and breaking deliverability.
Performance is the second issue. A few milliseconds at DNS level doesn’t sound like much until you stack it on top of TLS, checkout scripts, payment requests, and third-party tags. On a WooCommerce store, small delays compound in exactly the places you don’t want them.
Then there’s control. A records are blunt but reliable. If you need multiple destinations for resilience or traffic distribution, direct records support that cleanly. If you’re working with hostname patterns across subdomains, a setup like a wildcard DNS record strategy can simplify administration, but it still doesn’t change the core rule that the apex has different constraints.
Use this mental filter when deciding:
- Choose A records when the hostname is the root domain, when mail and verification records must coexist, or when you want direct routing control.
- Choose CNAMEs when the hostname is a subdomain and the provider benefits from being able to change the underlying destination without asking you to edit DNS again.
- Avoid chains when possible, especially if the hostname sits on a critical path like storefront, checkout, or certificate validation.
The wrong record type doesn’t just make DNS untidy. It changes how the whole stack behaves under pressure.
Real-World Use Cases for WordPress and CDNs
The usual production pattern for WordPress is not “A or CNAME everywhere.” It’s a split design.
The root domain uses A records. Subdomains often use CNAMEs. That division isn’t tradition for its own sake. It reflects how the platform, DNS standards, and managed edge services behave.
CNAME records are used in 72% of CDN integrations, largely because they let providers change underlying IPs without manual user updates, according to PowerDMARC’s comparison of CNAME and A records. The same source notes that multiple A records enable anycast routing for high availability, which is part of how providers absorb extreme DDoS volume, including the 71 Tbps peak in 2024.
A practical WordPress pattern
A typical store might look like this in operational terms:
- Root domain for the storefront: The business resides at the root domain for the storefront. It needs stable resolution and usually has mail, verification, and other DNS records tied to it.
wwwas a flexible front door: As a flexible front door,wwwis a natural place for a CNAME if the site is attached to a provider-managed endpoint.- Service subdomains: Blog, media, static assets, or campaign-specific subdomains are often good alias candidates when a third party controls the destination.
- Origin kept behind the edge: The public hostname should lead through the protective layer, not advertise a route around it.
This is the backbone of modern edge architecture for WordPress. Direct root. Flexible subdomains. Minimal exposure of the origin.
If you’re evaluating providers and trying to understand the traffic path, it helps to understand the role of a reverse proxy in front of WordPress. That model is what lets edge caching, request filtering, and bot separation happen before PHP does any work.
Where teams get into trouble
The bad setups are usually easy to recognize once you know what to look for.
Some teams point every hostname the same way because it feels easier to document. Others leave old DNS routes in place during a migration, so real users hit the edge while bots or stale resolvers still reach the origin directly. That split routing creates confusing symptoms. Cache behavior looks inconsistent. Security events don’t line up with server load. Admins think WordPress is underperforming when DNS is really steering requests into two different paths.
WooCommerce makes this more obvious because abuse is expensive. Login attempts, cart abuse, fake orders, and scraping don’t need to take the site down to hurt it. They just need to force enough uncached requests through to make the origin work harder than it should.
When the edge is configured correctly, WordPress handles content and application logic. When DNS is sloppy, WordPress ends up processing traffic that should have been filtered long before it reached the server.
That’s why the hybrid model holds up so well. It respects DNS limits, keeps the apex usable, and gives subdomains the flexibility that managed infrastructure needs.
The Onboarding Checklist Migrating DNS Without Downtime
DNS cutovers feel risky because mistakes are public immediately. Visitors don’t care whether the problem came from a record conflict, stale cache, or an unverified endpoint. They just see a broken site.
A clean migration is less about speed and more about sequencing.
Before you touch DNS
Start with the record that many overlook until too late: TTL. If you know a cutover is coming, reduce TTL on the relevant records to 300 seconds well ahead of the switch. Short TTLs won’t solve a bad plan, but they do make corrections and rollback faster, and the verified data notes that Google indexes both A and CNAME setups equally if TTL stays under that threshold.
Then verify the destination before pointing live traffic at it. The safest onboarding workflows don’t ask you to flip production DNS and hope for the best. They stage the domain, confirm the target is ready, and only then move traffic.
A solid preflight list looks like this:
-
Inventory the live records
Document the root,www, mail-related records, verification records, and any service subdomains. If you skip this, you’ll discover dependencies after the change. -
Decide hostname roles early
Pick which hostnames need direct mapping and which should remain aliases. Don’t improvise during the cutover window. -
Confirm certificate path
Make sure the target platform is prepared to validate and serve the domain once traffic moves. -
Check origin exposure
If the edge is supposed to protect the site, make sure the origin isn’t still publicly reachable through a leftover DNS route.
Cutover and rollback discipline
The switch itself should be boring. If it feels dramatic, the preparation wasn’t finished.
During cutover:
- Change only the records involved in traffic flow. Don’t combine a platform migration with unrelated DNS cleanup.
- Watch from multiple angles. Check storefront pages, login, cart, checkout, and admin. WordPress failures often hide in logged-in or uncached paths.
- Monitor origin load. If the edge is doing its job, server pressure should look different quickly.
- Be ready to revert. Low TTL gives you room to undo a mistake without waiting around for hours.
If you want a staged process to compare against your own runbook, this guide on moving DNS to a new edge provider without downtime outlines the same operational discipline from an edge migration angle.
One more practical point. Don’t trust a homepage check alone. A WordPress site can load the front page fine while XML-RPC, login, cart fragments, checkout callbacks, or admin-ajax requests fail behind the scenes. Validate the application paths that matter to revenue and operations.
Common Pitfalls and Troubleshooting Tips
Most DNS problems in WordPress don’t arrive labeled as DNS problems. They show up as “the SSL keeps acting up,” “mail verification broke after the CDN move,” or “we’re still seeing origin traffic even though the edge is enabled.”
That’s why this topic matters. DNS errors leak into performance, security, and operations at the same time.
A frequently missed issue is certificate validation. DNSimple’s explanation of A and CNAME differences notes that Let’s Encrypt DNS-01 challenges fail 22% more often on CNAME chains deeper than two levels, which can delay certificate renewals. The same source also highlights that CNAMEs can leak canonical names, giving bots a cleaner path to identify and target the origin directly.
Symptoms that point to DNS, not hosting
Watch for patterns like these:
-
SSL renewals that become unreliable
The site works until renewal time, then validation gets messy. Long alias chains are a common culprit. -
Edge protection that looks partially bypassed
Traffic still reaches the origin in ways that don’t match your front-door hostname. That usually means DNS is exposing more than one route. -
Email or verification records breaking after a root change
This often traces back to someone trying to use a CNAME where the hostname also needs other records. -
Intermittent slowness on uncached routes
Homepage tests can look clean while login, account pages, and checkout remain fragile.
What to check first
Start simple.
- Check the apex record type: If the root domain is using an alias in a way that conflicts with other records, fix that first.
- Flatten the chain: If a subdomain resolves through multiple aliases, reduce the depth.
- Review public DNS exposure: Make sure there isn’t an old hostname leading straight to origin.
- Test workflows: Login, add to cart, checkout, password reset, admin access, webhook callbacks.
A store can look healthy from the outside while bots hammer the origin through a hostname you forgot existed.
Plugin-level fixes won’t solve this class of problem. Blocking IPs inside WordPress is too late if the bad request already forced PHP to wake up. The cleaner move is to make DNS and edge routing work together so hostile traffic gets filtered before the application spends resources on it.
If your WordPress or WooCommerce site is dealing with origin overload, bot traffic, or a risky DNS migration, FirePhage is built for exactly that edge-first cutover. It puts filtering and caching in front of WordPress, helps stage DNS safely, and reduces the amount of hostile traffic that ever reaches your server.