Both www and non-www open: keep both as extra entry points or redirect to one?

Conclusion first: if the www and non-www versions point to the same set of content, the official website usually keeps only one primary domain and applies a 301 permanent redirect from the other, rather than making both versions publicly accessible at the same time. If both versions open, it is effectively declaring two sites with identical content to search engines and analytics tools at the same time: ranking signals are recorded separately, analytics are recorded separately, and every content change requires clearing two caches. Based on common delivery experience in 2026, this consolidation can usually be configured within 1 business day (experience range), at low cost; if you wait until indexing and monthly reports have taken shape before changing it, the cost mainly falls on the observation period and rework of measurement definitions.

When both domains open, is the extra one an entry point or a separate set of accounts?

Technically, making both the www and non-www versions point to the same server only requires adding one DNS record, and it can be configured in minutes; this is also how “both can open” arises in many projects. But for search engines and analytics tools, HTTP vs. HTTPS and prefixed vs. non-prefixed are different addresses; as long as both return 200 with the same content, the same content has two addresses, and crawling will process them as two separate addresses.

In delivery, the more common problem is not indexing but reconciliation. Operations looks at the admin backend, sales looks at inquiry sources, and the client looks at the monthly report; if these three sets of data belong to two different domains, disputes such as “the backend shows dozens of inquiries but analytics records only half” easily arise, and after a full round of troubleshooting it turns out that the two versions each recorded part of the data.

• Split indexing: The same piece of content has two addresses, backlinks and ranking signals are spread across them, and during a redesign it is harder to tell which address is being referenced.
• Analytics split into two sets: The same visitor entering through two entry points may be counted as two groups of people, and monthly reporting definitions remain inconsistent over time.
• Incomplete certificate coverage: Only the primary domain has a certificate, while the other domain can still be served over HTTP, leading to “some browsers show a security warning and others do not.”
• Clearing caches twice: After CDN is enabled, each domain stores its own cache; if only one is purged after a change, “the backend was updated but the frontend did not change” easily occurs.
• Inconsistent sharing and materials: In-site links, share images, QR codes, and addresses printed on business cards are written inconsistently, so the versions visitors copy and share are not unified.

First decide whether to consolidate or keep both—don’t start with redirects

Not every case of “both domains open” should be merged. The key is not whether the domain names look similar, but whether the content on both sides is the same set and whether they serve the same audience. With one set of content and one group of clients, consolidating to one primary domain is simpler; if there are already two sets of content and two audiences, forcing a 301 will block the other side’s entry point as well and may actually lose traffic sources.

You can use the following dimensions for a quick self-check first; cost and timeline are estimated as experience ranges and vary with site size in practice:

• Option A: Consolidate to a single primary domain. Configuration cost is usually within 1 business day (experience range), depending on internal links, sitemap, and template changes; configuration takes effect the same day, while indexing and analytics definitions usually need 2 to 8 weeks to stabilize (experience range); suitable for an official website with a single brand, one set of content, and visitors who do not distinguish entry points.
• Option B: Keep both domains. This avoids redirect configuration, but every redesign, certificate deployment, and cache purge must be done twice, and measurement disputes will persist; suitable for scenarios where domestic and overseas sites are operated separately, different brands under a group, or a legacy domain still has independent backlinks and offline materials.
• Judgment basis: If, after opening both domains, you cannot find any difference other than the address bar, it basically belongs to the category that should be consolidated.

Decide, redirect, reference, verify: break consolidation into four steps

These four steps are separated because they fail in different places: a DNS error means the site cannot open, a redirect error means it does not land in the right place, a reference error means “surface consolidation while the interior is still scattered,” and without platform-side verification you cannot see crawling after consolidation. Only after all four steps are checked is the consolidation complete.

1. Decide: First decide which is the primary domain; either www or non-www is fine, depending on brand habits and existing backlink distribution. Once decided, write it into the delivery document, and use it consistently for business cards, materials, and backend configuration.
2. Redirect: Uniformly 301 redirect the non-primary domain to the corresponding path on the primary domain, landing in one hop; avoid chains such as HTTP to HTTPS and then to the primary domain, and avoid redirecting all inner pages to the homepage.
3. Reference: Rewrite all domain references in internal links, canonical tags, sitemap, share image addresses, analytics code, and customer service code to the primary domain. This step is easy to miss; go through each template location one by one.
4. Verify: Follow the platform’s official documentation to perform site verification and crawl checks, then spot-check several inner pages to confirm they return 301 rather than 302 and that paths correspond one-to-one.

Acceptance can use a “four-combination spot check”: HTTP vs. HTTPS and www vs. non-www, paired in all combinations; enter any inner-page address and it should ultimately land in one hop at the same primary domain address, without redirect chains. Testing only the homepage and not inner pages usually misses detail-page links generated by the backend.

Delivery scene: a consolidation stuck on renewal and cache

One project was fairly typical: the client’s old domain had been purchased together with an email service years earlier, the budget was constrained by renewal, and they were unwilling to buy another certificate for the old domain alone, so only the primary domain was placed on HTTPS while the old domain still returned 200 over HTTP. At the same time, CDN had already been enabled on the site, and after launch operations purged only the cache on the primary domain side. On acceptance day, the client saw the old page on a phone and the new page on a computer; it took two rounds of changes to locate the coexistence of two delivery paths, and from launch to stable measurement definitions it took about three extra weeks (experience range).

The approach later agreed was: before consolidation, produce a domain and redirect checklist listing the primary domain, certificate coverage, cache refresh arrangements, and hard-coded domains in the backend and APIs item by item, and only change the configuration after the client confirms each item. This step usually takes an extra half day to one day (experience range), but it reduces the probability of “discovering after the change that something still points to the old domain.”

Several omissions worth checking item by item before delivery

• 301 written as 302: A temporary redirect is not treated as an address change, so consolidation is weakened.
• Only the homepage redirects: Old links and inner pages still point to the old domain, and two sets of addresses appear mixed in indexing.
• Residual internal links: Breadcrumbs, pagination, and share buttons in templates still generate old-domain links.
• Certificate purchased for only one domain: When the old domain redirects, a security warning may be triggered first, and visitors are redirected only after seeing the warning, which noticeably worsens the experience.
• Hard-coded domains in backend and APIs: Login, payment callbacks, and API addresses are hard-coded to one version, causing functional errors after switching domains.

When is consolidation appropriate, and when should domains not be forced together?

The cases suitable for consolidation are fairly clear: the official website has only one set of content and serves the same group of clients; the site launched recently and indexing has not yet taken shape; or the domain was inherited from an old site and backlinks are split across the two versions. In such cases, the benefits of consolidation mainly fall on measurement definitions, indexing judgment, and daily maintenance cost; one configuration saves effort over the long term.

The cases where it is unnecessary or inadvisable should also be stated clearly: when the two domains genuinely carry different content and different audiences, such as a domestic site and a site for overseas clients, consolidation will damage the other side’s entry point; when the old domain has accumulated many independent backlinks and its content does not correspond one-to-one with the main site, the safer approach is to keep the old domain and redirect corresponding pages item by item, rather than making a blanket redirect to the homepage. The boundary can be summarized in one sentence: if the content is one set, consolidate; if the content is not one set, do not force them together.

Frequently asked questions

Do HTTP and HTTPS each need a separate redirect?

Generally no, they do not need two separate redirects. A rule can be written as “any protocol and any prefix on the non-primary domain redirects to the corresponding path on the HTTPS primary domain”; landing in one hop is simpler and easier to troubleshoot than a two-hop chain.

Which one should be used, 301 or 302?

Use 301 for permanent address changes; use 302 for temporary maintenance or staged rollout. Consolidation is a long-term action; if 302 is used, search engines will not treat it as an address change, and the effect will be weakened.

If both domains are kept, can canonical alone solve the problem?

Canonical is a hint, not a directive; the two addresses will still be crawled and measured separately. To make visitors and reports recognize only one version, you still need 301 redirects plus unified internal links.

After consolidating the old domain, does it still need renewal?

As long as old links, business cards, or event materials still point to it, continuing renewal is usually safer. Once the domain is stopped, the redirects stop working with it, and that traffic source will be cut off directly.

How long after redirects are configured can changes be seen?

The configuration itself takes effect the same day. Indexing and measurement definitions usually need 2 to 8 weeks to stabilize (experience range), depending on site size and crawl frequency; it is not advisable to watch it day by day.

If you are currently stuck on this issue, start with two steps: confirm whether the content opened by the two domains is exactly the same, then use the “four-combination spot check” to see whether redirects land in one hop. Most corporate official websites belong to the category with one set of content that can be consolidated; but if the two domains were originally two sets of content for two groups of clients, do not change redirects yet—clarify the correspondence first and then decide. The timelines and work hours in this article are all experience ranges; actual results depend on site size and platform rules, and specifics can be checked against each search platform’s official documentation and the delivery acceptance checklist.