Canonical host redirects on Next.js, Webflow, Squarespace, Lovable, Replit, Framer and Wix

If example.com and www.example.com both return your site, every page exists twice. The fix is one rule: pick a host, then send the other one to it with a redirect. On a hosted builder that rule is a setting, usually called the primary or default domain. On Next.js it is a few lines in next.config.js. AIScan check E4 (HTTPS and canonical host) tests the result, and the seven sections below say where the setting lives on Next.js, Webflow, Squarespace, Lovable, Replit, Framer and Wix, and what each platform's own documentation promises.

TL;DR

• Pick one host and write it down. Apex or www, either is fine. A second host that serves its own copy is what costs points on E4.
• Look for the "primary" or "default" domain setting first. Webflow calls it the default domain, Squarespace, Lovable and Wix call it the primary domain. A platform setting beats a rule you write yourself.
• Check the status code your platform sends. Lovable documents a 302 for its domain redirect and says it does not support a 301 between connected domains. aiscan.site runs on Lovable and still passes E4 with that 302 (measured today, below).
• Verify with one command: curl -sI https://www.yoursite.com/ | head -n 3. You want a redirect status and a location: line that names your chosen host.
• Fastest check of all: npx aiscan-cli yoursite.com, then read E4, HTTPS and canonical host under Discoverability.

Contents

What every platform has in common

E4 reads four facts from one scan: the final origin after redirects, whether plain http:// upgrades to HTTPS, what the opposite host (www. if you scanned the apex, the bare domain if you scanned www.) does, and whether HSTS is set. The score drops when the opposite host answers with its own full copy. Google's duplicate URL guidance says to pick one variant as canonical and redirect the others to it, and RFC 9110 defines the redirection status codes the platforms below use. Four steps apply everywhere, so each section only says what is different:

1. Choose the host. Check which one your sitemap, canonical tags and links already use. Match those.
2. Make both hosts reach the platform. A redirect from www only runs if www resolves to the platform in DNS and is connected there. Several platforms treat the two as separate entries.
3. Mark one as primary or default. The platform then redirects the rest.
4. Publish, wait, test from outside. Most of these changes need a publish, and some take up to 48 hours to propagate.

The corpus study of 696 hosts found 266 hosts (38.2%) serving a full copy from both hosts. The generic fix for nginx, Apache, Cloudflare and WordPress is a separate guide. This one covers the hosted platforms and frameworks where you do not edit a server config.

What I measured

Duplicate hosts by platform, from the AIScan database on 7 October 2026 (696 hosts, latest scan per host, rubric 2026.08.2, aiscan.site excluded). Rows with fewer than 20 hosts are indicative only.

Webflow, Squarespace, Replit, Framer and Wix did not have enough scanned hosts in that sample to publish a rate, so I do not give one. For those five the sections below rest on each vendor's documentation, read on 9 November 2026.

One live probe on 9 November 2026, from one datacentre IP, of a site I run on Lovable:

The path survives the redirect, and the www hop is a 302. AIScan's own E4 result for the site the same day: pass, 4 of 4, with the evidence line "www.aiscan.site redirects to the canonical host · HSTS set". So E4 accepts a temporary redirect to the canonical host. A 301 or 308 is still the stronger signal for search engines, which is why the Lovable section says what to do about it.

Next.js

Next.js does not know which hostname you want. Whatever hosts your deployment maps to the app will answer, which is why 41.3% of the Next.js hosts in the table above serve a duplicate. The framework's own answer is a redirect with a host match. The Next.js docs (page last updated 30 June 2026, retrieved 9 November 2026) show has accepting type: 'host', and say redirects "are checked before the filesystem which includes pages and /public files".

// next.config.js: send www to the apex, keep the path and query
module.exports = {
  async redirects() {
    return [
      {
        source: '/:path*',
        has: [{ type: 'host', value: 'www.example.com' }],
        destination: 'https://example.com/:path*',
        permanent: true,
      },
    ]
  },
}

To go the other way, swap the two hosts. Three details matter:

• permanent: true sends a 308, not a 301. The docs explain that Next.js uses 307 for temporary and 308 for permanent so the request method is preserved. A 308 is a permanent redirect and counts as one for canonicalisation.
• Query values pass through. The docs say any query values on the request are passed to the destination, so ?utm_source=... survives.
• Check the layer in front. If the app sits behind a host or CDN that already redirects, a second rule in next.config.js can create a loop. Test the public domain, not localhost, and read the location header at every hop.

Then add both domains to the project at your host, so www reaches the app and the rule has something to match. See also the Next.js platform page and AIScan's fix for the empty-render problem on Next.js.

Webflow

Webflow calls the canonical host the default domain. Its help centre article "Set a default domain" (updated 1 September 2026) says: if you connected more than one domain, "you'll need to set a default domain to redirect all traffic from the other domains to the default", and that this "helps avoid SEO penalties due to duplicate content".

1. Connect both the apex and the www host to the site, with the DNS records Webflow shows.
2. Go to Site settings > Publishing > Production.
3. Click Make default to the right of the host you chose.
4. Publish the site to that domain. The change does not apply until you do.

Things the article says that catch people:

• Quick connect picks www for you. When you connect with the Quick connect option, "your default domain is automatically set to the www subdomain", though you can make the root domain the default.
• A domain added later is not in the publish menu. If you add a domain after setting the default, go back to Production, click Make default next to the default again, publish to the new domain, then set the default once more.
• Match the global canonical tag. If the global canonical tag URL differs from the default domain, "a different domain may surface in some contexts", for example in Android's share sheet. Set both to the same host. Webflow's "Set canonical tags to improve SEO" article (updated 8 September 2026) covers the field.

If the browser shows ERR_TOO_MANY_REDIRECTS after publishing, the "Fix the too many redirects error" article (last updated 18 August 2025) says the cause is a loop between www and the root domain, usually from Webflow's older DNS records. Its fix: open Site settings > Publishing > Production, copy the current records, remove the old A and CNAME records at your DNS host, add an A record for @ and a CNAME for www with the values shown there, then publish. The values in that article were 198.202.211.1 and cdn.webflow.com. Copy yours from Production, not from this page, because records can change.

Squarespace

Squarespace calls it the primary domain. The article "Setting a primary domain" (updated 1 October 2026) says "All custom domains redirect to the primary", so whichever host visitors type, the primary one stays in the address bar. The first custom domain you add becomes primary automatically, and "if you add more custom domains, that first domain remains as your primary".

To choose the apex or www:

1. Open the Domains panel.
2. If the host you want is a separate domain entry, click ... next to it and pick Set as primary domain. For a third-party domain, click the domain and choose Set as primary domain under Actions.
3. To drop the www, switch the Use "www" prefix toggle off. The article "Removing the 'www' from your domain" (updated 1 October 2026) says that by default the naked domain and the www domain are linked, and visitors who type yourdomain.com are sent to www.yourdomain.com.
4. Allow time. That article puts the change at 24 to 48 hours.

Two limits from the same articles. The www toggle only works on domains pointing at a Squarespace site. And a visitor on the built-in your-site-name.squarespace.com address "won't redirect to your custom primary domain", so keep that address out of your links and sitemap.

For HTTP, the article "Understanding SSL certificates" (updated 4 November 2026) says the Secure setting means "visitors are always redirected to HTTPS after the certificate is issued, even if they entered HTTP". It is the default and the recommended setting, under the SSL panel's Security preference. E4 also looks for HSTS; the same article recommends ticking Secure and HSTS secure together for most sites.

Lovable

In Lovable the choice sits in Project > Settings > Domains. When you connect a root domain, the dialog's Redirect www.yourdomain.com → yourdomain.com option is on by default. Lovable then connects www as well, groups the two in one row, and redirects www visitors to your primary domain. Turn the option off and only the root domain connects.

The primary domain is the address everything else points to. Lovable's custom domain docs (retrieved 9 November 2026) say:

• The first custom domain you connect becomes the primary one, for domains added after 29 October 2025, unless the project already has a primary address.
• To change it, open the three-dot menu next to a domain and choose Set as primary. Only one domain can be primary at a time.
• A domain you buy through Lovable and connect becomes primary, replacing one Lovable chose automatically. One you picked yourself stays primary.
• Other connected domains redirect with a 302. The docs add that Lovable hosting "does not support 301 permanent redirects between connected project domains", because primary domains can change and a temporary redirect keeps that reversible.

That 302 is what my probe above found on aiscan.site, and E4 passes with it. If you want a permanent status on the www hop, the docs give no Lovable-side switch for it, and I have not tested a redirect rule in front of Lovable, so I cannot vouch for one. The decision is yours: E4 passes either way, and a 302 means search engines may keep both URLs in play longer than they would with a 301. Lovable's docs say the connected domain is what its SEO checks (indexing, canonical URLs, sitemap status) read for the correct host, so connect the domain you want indexed before you ask for indexing. See Lovable on the platform page and the soft 404 fix for Lovable.

Replit

Replit does the least for you, and says so. Its custom domain docs (retrieved 9 November 2026) put it plainly: "www is a subdomain. Linking hat-tip.cc does not automatically serve www.hat-tip.cc." So on a fresh Replit deployment the second host may not reach the app at all, which is a different problem from a duplicate, and E4 treats an unreachable opposite host as fine.

1. Open your published app, then Tools > Domains under Replit Cloud.
2. Add the host you want as canonical, such as example.com, and create the A record and the replit-verify= TXT record it shows at your registrar.
3. If you also want www.example.com to work, add it as its own entry in the Domains tool and publish the records it generates on hostname www.
4. Make one send visitors to the other. The docs say "most builders who want a www address also configure a redirect from the apex to www (or vice versa) at their registrar". That redirect is your registrar's URL forwarding or redirect feature, not a Replit setting, and it is the part to check by hand.

Two traps from the docs: the TXT record for each host must stay in DNS permanently, and each subdomain has its own TXT record, separate from the apex. Replit also checks for your records for about six hours after you add a domain, so add both promptly. After the change, update anything that stored the old address, such as payment redirect URLs. The Replit platform page lists the other AIScan guides for the stack.

Framer

Framer's custom domain article (retrieved 9 November 2026) gives the records for an apex domain: two A records, 31.43.160.6 and 31.43.161.6, on @, and a CNAME from www to sites.framer.app. It adds that you must make sure "there are no other A or AAAA records configured for the domain, as they may interfere". The same page describes the www CNAME as the one "for redirecting to the 'www' version of your domain". The values also appear in Site Settings > Hosting > Domains, which is where to copy them from, not from here.

What I could not find in Framer's documentation is a named setting for choosing the apex or the www as the canonical host, or a statement of the redirect status code between them. Rather than guess, treat Framer as a "measure it" platform:

1. Connect the domain as the article describes, with both the apex records and the www CNAME.
2. Publish, then run the verify commands below against both hosts.
3. If the opposite host answers with a full page instead of a redirect, report it to Framer support with the two curl outputs.

Two Framer features that are not the same thing. Redirects (Site Settings > Hosting > Redirects) map old URLs to new ones: rules run in the order you drag them, they support * wildcards and :1 capture groups, and you publish to apply them. And the Canonical URL field (Settings > Domains, at the bottom) is for sites served through a reverse proxy, where Framer cannot see the public domain. Asked whether a directly connected domain needs it, Framer's FAQ answers "In most cases, no." Neither is a substitute for connecting the host properly.

Wix

Wix uses the primary domain too. In its help centre (retrieved 9 November 2026) the article "Connecting Multiple Domains to One Wix Site" says your primary domain "connects directly to your site and is your site's main address", and "any additional domains you connect redirect to your primary domain". You can connect an unlimited number of domains to one site, and you must upgrade the site with a plan first.

1. Go to Domains in your Wix account.
2. Assign the extra domain to the site, and when asked choose Redirect it to the primary domain. The other option, Replace the current primary domain, disconnects the existing one.
3. To switch which host is primary, click Set as Primary next to it and confirm with Set as Primary Domain.
4. Wait 24 hours. The article "Switching Your Primary and Redirected Domains" says that for the first 24 hours the site is available under both names, and after that the address bar changes to the primary domain.

The 24 hours matter for testing: a scan on day one can show a duplicate that clears by itself. Wix's article on redirecting a single page ("Setting Up a 301 Redirect for a Page on Your Site") covers page-level 301s and says they only work on a custom domain, not a free wixsite.com address. The domain-level articles I read do not state the status code of the redirect to the primary domain, or whether a new site starts on the apex or on www, so check both with the commands below. See AI readiness setup on Wix for the other checks.

Verify the fix on any platform

With AIScan (default): run npx aiscan-cli yoursite.com, open Discoverability and find E4, HTTPS and canonical host. It should read pass, and the evidence line should say the opposite host "redirects to the canonical host" and that http:// "upgrades to https". The Discoverability checks page explains the grading.

By hand with curl, one request per variant, without following redirects:

curl -sI http://example.com/      | grep -iE '^(HTTP|location)'
curl -sI http://www.example.com/  | grep -iE '^(HTTP|location)'
curl -sI https://example.com/     | grep -iE '^(HTTP|location)'
curl -sI https://www.example.com/ | grep -iE '^(HTTP|location)'

Expected: exactly one of the two HTTPS variants answers 200 with no location. The other three answer a redirect that lands on it, ideally in a single hop. Add a path (/blog/x) to one request to confirm the path survives, and follow the chain with curl -sIL to count hops. Republish first if the output looks old, and allow for the propagation times above.

Next step

Run the scan on your own domain and confirm E4, then read the rest of the series in AIScan's guides. The adoption numbers are in the 696-host study, the server-level rules for nginx, Apache and Cloudflare are in redirect www and http to one canonical host, and the cross-platform comparison is in the platform league table.

Published on 9 November 2026 from vendor documentation read that day (page dates are given where the vendor shows one) and one live probe. This guide replaces seven planned single-platform posts.