Permanently forward Netlify subdomain to custom TLD


I’d like to permanently redirect all traffic going to the default netlify subdomain to my set custom domain.

I noticed the netlify subdomain site was still live. Wouldn’t this cause duplicate content issues? I’ve tried adding redirect rules in the Gatsby redirects and netlify.toml files but nothing worked.


@emTr0 Welcome to the Netlify community.

Have you tried creating a _redirects file with an instruction along these lines?

# redirect from Netlify to custom domain* 301!

Yes. I don’t think it works because the domain is set to so it’s not catching anyone going to the other. The netlify site doesn’t seem to be updating but it’s still there with some content that was posted before I set the custom domain.

@emTr0 This seems to be a completely different issue than you raised in your original post.

I’m not sure how you arrived at that conclusion. I want to forward to I don’t want the subdomain to remain live but since I can’t just shut it, I’d have to permanently forward it to

None of the redirect or toml rules seem to work since netlify only sees the site being served at even though the other is still live (although with old content).

hi @emTr0, question:

You can associate a custom domain you own with your netlify site either by using Netlify DNS OR by using the DNS that currently manages the site to point to the subdomain. I think that’s what you are looking for?

There isn’t a way to remove the Netlify site name in general.

You could set up a redirect as greg suggested, so IF someone should find the netlify site name and try and access that URL, they would be redirected.


I already have those redirect rules but they don’t seem to be working. I have both http/https but it still shows the old site at the subdomain link (without content and an old page).

For reference:*                  301!*                   301!

The wildcard doesn’t seem to be working correctly.

Ok so I just tried going to a link by adding the slug to the subdomain version and it works so as long as someone is clicking a full link to a post or page, the wildcard will work. I tried adding redirect rules for the homepage but it still won’t work.

Hi, @emTr0. I think the redirects are almost currently working but two of the redirects work “too literally”.

Here is an example of the “empty path” URL (“empty path” meaning "nothing after the domain name except “/”):

Here is an example with curl:

$ curl -svo /dev/null  2>&1 | egrep "< (HTTP|location:)"
< HTTP/2 301
< location:

It is redirecting to! Clearly that isn’t what is intended.

This is happening because of the first two rules below (the second two rules are correct):                   301!                    301!*                  301!*                   301!

To resolve this, change the first two rule to remove “:splat”:                         301!                          301!*                  301!*                   301!

To summarize, the “:splat” on the target is only required if there is wildcard ("*") on source. Leave the splat on the second two rules and remove it from the first two above. Then trigger a new deploy to have the redirect changes take effect.

If that change doesn’t resolve this (or if there are other questions), please let us know.

@luke I removed the splat but still isn’t forwarding. I tried with/without a trailing slash just to be sure. I also cleared browser cache and all that. Tried waiting for a little bit of time also but same result.

Here are the rules I currently have setup:                         301!                          301!                           301!                            301!*                  301!*                   301!

I also have rules to specific posts, which work fine.

Hi, @emTr0,

Those redirects work when I test them:

$ curl -svo /dev/null  2>&1 | egrep -i "< (HTTP|location)"
< HTTP/1.1 301 Moved Permanently
< Location:
$ curl -svo /dev/null  2>&1 | egrep "< (HTTP|location)"
< HTTP/2 301
< location:

Did you resolve this or are you still seeing the issue? If you do not see these redirects working now, would you please send us an x-nf-request-id header (or the info it replaces) for a failed redirect?


The subdomain is still loading without forwarding.

Here is what you asked for:

1. x-nf-request-id:


Hi, @emTr0, we only responded with that x-nf-request-id once (they are unique). The timestamp was 1590373478.468 seconds after the Unix epoch which is Sun May 24 19:24:38 PDT 2020.

At that time, the following deploy was active (having completed less than two minutes before):

In that deploy, there were only two redirects active and neither was for the subdomain You can download the _redirects file used by clicking on the download deploy button on that page shown in the screenshot below:


Note the date and time of the request: Sun May 24 19:24:38 PDT 2020

Did you just get that x-nf-request-id? If so, I think it is because you have a service working locally which has that version of the page cached. I see the referrer header in original request was:

This usually indicates a service worker (but not always). There is more information about unregistering a service worker at the topic below:

If there are other questions about this, please let us know.

I appreciate your detailed response.

Whatever was causing it to not forward must have cleared itself because it’s now forwarding for me the way it should. I consider this solved unless you would like more info for future reference.


1 Like