The WWW vs non-WWW version of a website should not normally behave as two separate, independently accessible versions of the same site. Search engines can encounter both example.com and www.example.com, so the important question is whether your website consistently establishes one preferred hostname and redirects the other to it.
The PKCapra WWW/non-WWW Checker compares the two HTTPS hostname variations and follows their server-side responses so you can see whether they are being consolidated correctly.
WWW/non-WWW Checker
Compare the naked and www HTTPS versions of your domain, identify the canonical hostname, and detect split-domain or redirect configuration problems.
WWW / non-WWW hostname analysis
—
Master hostname
Hostname relationship
WWW and non-WWW response matrix
| Variation | URL | Direct Status | Location | Final Status | Final Destination | Validation |
|---|
WWW/non-WWW consolidation checkpoints
The checker independently requests both HTTPS hostname variations with native cURL. It records each initial response status, follows redirects, strips path and query data with URL parsing, compares only final destination hostnames, and marks a single redirect-to-master relationship as Perfect Consolidation.
What the WWW vs Non-WWW Checker Does
The checker analyzes these two versions of your website:
https://example.comhttps://www.example.com
For each variation, it examines the response returned by the server and records information such as:
- Initial HTTP status code
- Redirect destination
- Redirect count
- Final HTTP status code
- Final destination
- Hostname reached after redirects
- Whether both variations ultimately consolidate to the same hostname
The purpose is not simply to determine whether one URL returns a 301. The important part is understanding the complete redirect behavior and whether both hostname variations ultimately resolve to the same preferred version.
Why WWW and Non-WWW Consistency Matters
A website can technically operate with either a WWW or non-WWW hostname. The important issue is consistency.
For example, a site may choose:
as its preferred hostname and redirect:
to it.
Alternatively, it may choose:
and redirect:
to the WWW version.
The problem occurs when both versions remain independently accessible without a clear consolidation.
That can create two reachable hostname variations for substantially the same website and make the site’s canonicalization configuration harder to understand and maintain.
Google describes canonicalization as the process of selecting a representative URL from duplicate or very similar URLs. Redirects, rel="canonical", sitemaps, and internal linking can all provide signals about which URL should be treated as the preferred version.
Google Search Central: Canonicalization
How the Checker Evaluates the Two Variations
The checker does not treat the initial HTTP response as the complete result.
There are two important stages:
- Initial response
- Final response after redirects
For example:
https://example.com → 301 → https://www.example.com/ → 200 OK
The initial response is 301, while the final response is 200 OK.
Those are two different pieces of information and both are important.
A 301 indicates that the original URL redirected somewhere else. The final 200 OK indicates that the destination successfully returned a page.
Understanding the Main Results
Initial Status
The initial status is the HTTP status returned when the checker first requests the hostname.
Common results include:
200 OK— the requested hostname served a successful response directly.301 Moved Permanently— the hostname permanently redirects elsewhere.302 Found— the hostname temporarily redirects elsewhere.307 Temporary Redirect— a temporary redirect that preserves the request method.308 Permanent Redirect— a permanent redirect that preserves the request method.- Other
3xxresponses — additional redirect behavior may be present. 4xxresponses — the requested resource was not successfully served.5xxresponses — the server reported an error.
Final Status
The final status shows what happened after redirects were followed.
For example:
Initial Status: 301
Final Status: 200
This means the original hostname redirected successfully and the final destination returned a successful response.
Redirect Count
The redirect count indicates how many redirects were encountered before reaching the final destination.
A simple consolidation normally looks like:
Non-WWW → WWW → 200 OK
or:
WWW → Non-WWW → 200 OK
Longer chains should be investigated because unnecessary redirect hops add complexity and can make troubleshooting more difficult.
Google recommends avoiding redirect chains where possible and keeping redirects direct when moving URLs.
Google Search Central: Site Moves and Redirects
Final Destination
The final destination shows where the request ultimately ended.
For example:
https://example.com → https://www.example.com/
This allows you to verify whether the two hostname variations ultimately converge on the same preferred hostname.
The Two Main Consolidation Cases
The checker evaluates both directions rather than assuming that WWW is always preferred.
Case A — WWW Is Preferred
Example:
https://example.com → 301 → https://www.example.com/ → 200 OK
while:
In this configuration, the non-WWW version redirects to the WWW version while the WWW version serves the final page.
The checker can therefore establish:
- WWW is the preferred hostname
- Non-WWW redirects to WWW
- Both variations consolidate to the same destination
- The redirect is functioning as expected
Case B — Non-WWW Is Preferred
The opposite configuration can also be valid.
For example:
https://www.example.com/ → 301 → https://example.com/ → 200 OK
while:
Here, the non-WWW hostname is the preferred version.
The checker therefore does not automatically treat WWW as better than non-WWW. It evaluates which hostname the server actually establishes as the final destination.
When the Checker Flags a Split or Duplicate Risk
The most important problematic condition is when both hostname variations independently return a successful response without redirecting to the same preferred hostname.
For example:
If both versions independently serve the same site, the hostname configuration has not clearly consolidated the two variations through redirects.
The checker identifies this situation as a potential:
Split / Duplicate Content Risk
This does not mean that Google will automatically penalize the website.
Google states that duplicate content itself is generally not a spam violation. Instead, search engines have to determine which URL should represent substantially duplicate content.
Google Search Central: Canonicalization
The purpose of the checker is therefore to identify the technical configuration so you can investigate and correct inconsistent hostname handling.
Why the Final Destination Matters
A redirect alone is not enough to understand the configuration.
Consider:
example.com → 301 → www.example.com → 301 → example.com
The presence of redirects does not necessarily mean the configuration is healthy. This creates a redirect loop.
Another example is:
example.com → 301 → www.example.com → 302 → another-host.example`
The final destination does not establish a straightforward WWW/non-WWW consolidation.
The checker therefore considers the complete redirect result instead of looking only at the first status code.
How URL Normalization Is Used
The checker compares the hostname reached after redirects rather than requiring two complete URL strings to be identical character-for-character.
For example, these URLs can represent the same hostname destination for the purpose of WWW/non-WWW comparison:
https://example.comhttps://example.com/https://example.com/some-pagehttps://example.com/some-page?utm_source=test
The analysis focuses on the hostname relationship while ignoring differences such as a trailing slash, path, or query string when determining the WWW/non-WWW destination.
This prevents harmless URL formatting differences from being treated as different hostname destinations.
Common Redirect Status Codes
301 — Permanent Redirect
A 301 indicates a permanent redirect and is commonly used when consolidating one hostname with another.
308 — Permanent Redirect
A 308 is also a permanent redirect, with request-method preservation behavior defined by HTTP specifications.
302 — Temporary Redirect
A 302 indicates temporary redirection and can represent a different implementation intention from a permanent hostname migration.
307 — Temporary Redirect
A 307 is a temporary redirect that preserves the request method.
Google documents permanent redirects such as 301 and 308 as stronger signals for canonicalization than temporary redirects such as 302 and 307.
Google Search Central: Redirects
WWW vs Non-WWW Is Only One Part of Canonicalization
Hostname consolidation should be consistent with the rest of the site’s URL architecture.
After establishing a preferred hostname, review:
rel="canonical"values- XML sitemaps
- Internal links
- HTTPS configuration
- HTTP-to-HTTPS redirects
- WWW/non-WWW redirects
- Redirect chains
- Alternate URL variations
For example, if the site has chosen:
as its preferred hostname, internal links should not randomly alternate between:
and:
Google recommends linking internally to the canonical version and using consistent canonicalization signals.
Google Search Central: Consolidate Duplicate URLs
A Practical Configuration Example
Suppose your preferred hostname is:
A consistent setup could look like:
http://example.com → HTTPS + hostname redirect
http://www.example.com → HTTPS
https://example.com → 301 → https://www.example.com
This creates a clear final destination.
The exact implementation can vary depending on the web server, CDN, hosting platform, SSL setup, and WordPress configuration.
Common WWW/Non-WWW Problems
Both Versions Return 200
Example:
example.com → 200
www.example.com → 200
Both versions are independently accessible.
Review the preferred hostname and implement appropriate server-side consolidation if both URLs represent the same site.
One Version Redirects to the Wrong Host
Example:
example.com → 301 → unrelated.example.net
Check the server, CDN, reverse proxy, domain configuration, and redirect rules.
Redirect Chains
Example:
example.com → 301 → www.example.com → 301 → another URL → 200
Investigate whether the redirects can be simplified.
Redirect Loops
Example:
example.com → www.example.com → example.com → www.example.com
This requires immediate configuration review because the request cannot reach a stable final destination.
WWW and Canonical Disagree
A site may redirect users to one hostname while its HTML canonical points to another.
For example:
Redirect destination:
Canonical:
This creates conflicting signals and should be investigated.
Sitemap Uses Another Hostname
If the site’s preferred hostname is:
but the XML sitemap contains:
the configuration should be reviewed for consistency.
A Useful Troubleshooting Workflow
Step 1 — Check Both Hostnames
Run the checker and record:
- Initial status
- Redirect count
- Final status
- Final destination
Step 2 — Identify the Preferred Hostname
Determine whether the site’s intended canonical hostname is:
example.com
or:
www.example.com
Step 3 — Check the Redirect
The non-preferred hostname should redirect toward the preferred hostname when both represent the same site.
Step 4 — Check the Final Destination
Make sure the redirect actually reaches the intended hostname rather than another unexpected URL.
Step 5 — Check Canonical Tags
Inspect the HTML <link rel="canonical"> value on important pages.
Step 6 — Check the Sitemap
Review the URLs submitted through the XML sitemap and confirm that they consistently use the intended hostname.
You can use the PKCapra XML Sitemap Analyzer for sitemap-level investigation.
Step 7 — Check Internal Links
Important internal links should consistently reference the preferred URL version.
For deeper internal-link analysis, use the PKCapra Internal Link Analyzer.
Step 8 — Check HTTPS Redirects
If HTTP and HTTPS behavior is also inconsistent, investigate it separately with the PKCapra HTTP/HTTPS Redirect Checker.
WWW/Non-WWW vs Canonical URL
These concepts are related but not identical.
WWW/non-WWW consolidation concerns the hostname:
example.com
www.example.com
Canonicalization concerns which URL should represent duplicate or substantially similar content.
A canonical URL can therefore involve differences beyond the hostname, including:
- HTTP vs HTTPS
- WWW vs non-WWW
- Trailing slash
- URL parameters
- Duplicate paths
Use the PKCapra Canonical URL Checker when you need to investigate canonical declarations and related URL signals.
What a Healthy Result Looks Like
A straightforward consolidated configuration generally has:
- One clearly established preferred hostname
- The alternate hostname redirects to it
- The redirect reaches the intended destination
- No redirect loop
- No unnecessary redirect chain
- Consistent canonical URLs
- Consistent sitemap URLs
- Consistent internal links
- Consistent HTTPS configuration
The exact server implementation can differ, but the important principle is consistency.
Important Limitations
The WWW/non-WWW Checker evaluates the HTTP behavior it can observe from the checking environment. A result represents the response received during the test and does not replace a complete server, CDN, DNS, or Google Search Console investigation.
Possible environmental factors include:
- Firewall rules
- CDN behavior
- Bot protection
- Rate limiting
- Hosting restrictions
- DNS propagation
- SSL configuration
- Server-side conditional redirects
- Geographic or network-specific behavior
A successful test from one environment does not guarantee identical behavior from every network or crawler.
The checker also does not determine Google’s selected canonical for a URL. Google’s selected canonical can be investigated through Google Search Console and URL Inspection.
Google Search Central: Canonicalization Troubleshooting
Frequently Asked Questions
Should I use WWW or non-WWW?
Both can be used. The important technical issue is that the site consistently establishes one preferred hostname and appropriately handles the alternate version.
Is WWW better for SEO?
There is no general SEO requirement that a site must use WWW. The important consideration is consistent URL architecture and canonicalization.
Should both WWW and non-WWW return 200?
If both versions represent the same website, independently serving both versions without a clear consolidation can create an ambiguous hostname configuration. The preferred approach depends on the site’s intended URL structure.
Is a 301 redirect better than a 302 for WWW consolidation?
A permanent redirect communicates a different intention from a temporary redirect. Google documents permanent redirects such as 301 and 308 as stronger canonicalization signals than temporary redirects such as 302 and 307.
Does a WWW/non-WWW issue automatically cause a Google penalty?
No. Duplicate content by itself is generally not treated as a spam violation. However, inconsistent URL signals can make canonicalization and site management more complicated.
Can I use a canonical tag instead of a redirect?
A canonical tag and a redirect serve different purposes. A redirect sends users and crawlers to another URL, while rel="canonical" communicates the preferred URL for a page that remains accessible.
What if both versions return 200 but have different content?
That requires closer investigation. If the two hostnames intentionally represent different websites or applications, the configuration may be legitimate. If they are supposed to represent the same content, the URL architecture should be reviewed.
Does DNS CNAME automatically redirect WWW to non-WWW?
No. DNS resolution and HTTP redirection are different mechanisms. A DNS record can determine where a hostname resolves, but it does not itself provide an HTTP 301 or 302 redirect.
Should my sitemap use WWW or non-WWW?
The sitemap should consistently use the URL version that represents the site’s preferred URL architecture.
Should internal links use the preferred hostname?
For a consistent canonical setup, important internal links should generally reference the preferred URL version rather than unnecessarily switching between WWW and non-WWW.
Why does my server redirect correctly in a browser but the checker shows a different result?
Redirect behavior can depend on server rules, CDN configuration, headers, cookies, bot protection, geographic routing, or other request characteristics. Compare the checker result with the actual server configuration and test from another environment when necessary.
Can a redirect chain cause problems?
Unnecessary redirect chains add extra requests and complexity. If several redirects are being used when one direct redirect would accomplish the same consolidation, review the configuration and simplify it where practical.
Final Check
The goal is simple:
One preferred hostname → alternate hostname redirects → preferred hostname → final page responds successfully.
After correcting WWW/non-WWW behavior, verify the related canonical, sitemap, internal-link, and HTTPS signals as well. A consistent hostname is one part of a larger technical SEO URL architecture.