---
title: "Canonical host redirects on Next.js, Webflow, Squarespace, Lovable, Replit, Framer and Wix"
slug: canonical-domain-redirect-every-platform
published: 2026-11-09T12:14:51.030525+00:00
updated: 2026-11-09T12:14:51.030525+00:00
author: "M Asif Rahman"
author_url: https://ar.bd
category: "AI Readiness"
tags: check:E4, platform:nextjs, platform:webflow, platform:squarespace, platform:lovable, platform:replit, platform:framer, platform:wix, canonical host, redirects, www, how-to, AI readiness
description: "Redirect www and apex to one canonical host on Next.js, Webflow, Squarespace, Lovable, Replit, Framer and Wix: where each setting lives, plus the curl for E4."
url: https://aiscan.site/blog/canonical-domain-redirect-every-platform
---

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

| Platform | Jump to | Where the choice lives |
|---|---|---|
| Next.js | [#next-js](#next-js) | A `redirects()` rule with a `host` match in `next.config.js` |
| Webflow | [#webflow](#webflow) | Site settings, Publishing, Production, **Make default** |
| Squarespace | [#squarespace](#squarespace) | Domains panel, **Set as primary domain**, **Use "www" prefix** toggle |
| Lovable | [#lovable](#lovable) | Project, Settings, Domains, **Set as primary** |
| Replit | [#replit](#replit) | Domains tool, one entry per host, redirect at your registrar |
| Framer | [#framer](#framer) | Site Settings, Domains, DNS records for apex and `www` |
| Wix | [#wix](#wix) | Domains, **Set as Primary**, other domains redirect to it |

## 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](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) says to pick one variant as canonical and redirect the others to it, and [RFC 9110 defines the redirection status codes](https://www.rfc-editor.org/rfc/rfc9110.html#name-redirection-3xx) 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](https://aiscan.site/blog/canonical-host-https-corpus) found 266 hosts (38.2%) serving a full copy from both hosts. [The generic fix for nginx, Apache, Cloudflare and WordPress](https://aiscan.site/blog/canonical-host-redirects-for-agents) 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.

| Detected platform | Hosts | Serve a duplicate origin | Share | No HTTPS upgrade | Share |
|---|---|---|---|---|---|
| None detected | 261 | 134 | 51.3% | 71 | 27.2% |
| WordPress | 185 | 29 | 15.7% | 7 | 3.8% |
| Next.js | 160 | 66 | 41.3% | 17 | 10.6% |
| Astro | 34 | 12 | 35.3% | 4 | 11.8% |
| Shopify | 17 | 2 | 11.8% | 0 | 0% |
| Lovable | 11 | 6 | 54.5% | 0 | 0% |

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:

| Request | Status | `location` |
|---|---|---|
| `http://aiscan.site/` | 301 | `https://aiscan.site/` |
| `http://www.aiscan.site/` | 302 | `https://aiscan.site/` |
| `https://www.aiscan.site/blog/x` | 302 | `https://aiscan.site/blog/x` |
| `https://aiscan.site/` | 200 | none |

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".

```js
// 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](https://aiscan.site/docs/platforms/nextjs) and [AIScan's fix for the empty-render problem on Next.js](https://aiscan.site/blog/nextjs-react-invisible-to-ai-crawlers).

## 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](https://aiscan.site/docs/platforms/lovable) and [the soft 404 fix for Lovable](https://aiscan.site/blog/fix-soft-404s-for-ai-agents#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](https://aiscan.site/docs/platforms/replit) 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](https://aiscan.site/blog/ai-readiness-setup-guide#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](https://aiscan.site/docs/checks/discoverability) explains the grading.

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

```bash
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](https://aiscan.site/guides). The adoption numbers are in the [696-host study](https://aiscan.site/blog/canonical-host-https-corpus), the server-level rules for nginx, Apache and Cloudflare are in [redirect www and http to one canonical host](https://aiscan.site/blog/canonical-host-redirects-for-agents), and the cross-platform comparison is in the [platform league table](https://aiscan.site/blog/platform-league-table-agent-readiness).

*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.*