Strange Redirect Behavior


Has anyone run into Preformatted text an issue with redirecting traffic from an alias to the primary domain? The goal is to use a new domain and redirect all the old traffic over. So far, it seems some pages on their initial load result in a 404, directly relating to how the redirect is occuring. The rules I have setup are: 301!* 301!

(since I’m limited on links I can add, the first item is followed by a non secure www redirect, as well as a secure apex and www redirect; same for the second item, both following the same redirect rules as listed here).

Right now, it seems when a page is visited, it’s adding the splat parameter again, such as: ->,%20/news

Chrome and Safari show this initially, but will redirect properly when hitting the original URL after a few seconds. Firefox will show an error page with no response, and start to redirect after a few seconds as well.

I’ve tried to deploy and clear the cache as well, but with no luck. The www subdomain for siteB is currently the primary domain, with the www subdomain redirecting and siteA (and www subdomain) setup as aliases. Originally, the www subdomain for siteA was the primary domain. Any help or ideas on what to try would be greatly appreciated.

You only actually need this one rule:* 301!

Adding multiple rules appears to be creating some cyclic ruling, hence the double-up on your splat :slight_smile:. And, you need not worry about HTTP rules as we only serve content using HTTPS and we’ll redirect that automatically.

Hi @Pie! Thank you for the help on this! I tried your suggestion but any links with in it would stop redirecting after that. I tried using rules for the apex and www, and continued to see the original issues pop up (though I’m starting to think this may be a caching issue).

Since both domains are aliases for the site, would it be safe to have a rule for the apex and www subdomain separately? Or should the system take care of this already, and I’m possibly just running into cached results somewhere along the line? One thing I forgot to mention that might matter here, is both domains have DNS setup with the registrar and point to Netlify (Netlify DNS isn’t used here).

Can you provide an example redirect that you’re trying to accomplish and the account name? I’d like to take a look at the domain config and help determine a suitable set of rules :smiley:

Yep, sorry for the vague details before, had to get approval first. The account name is frosty-lamport-70e699 and the primary domain is Right now, it redirects from for the rewrite rule, but links without the www subdomain don’t redirect.

An example would be the article (with the www subdomain applied, the redirect will work correctly).

Thank you for taking the time to help assist with this issue!

No problem! I understand that this may be the case for some customers :slight_smile:

The rule in question is:* 301!

/* 301!
accomplish what you’re trying to achieve? :smiley:

Just tried that and no luck. It looks like that’s giving me a infinite loop on the redirects with that rule alone (coming from the old domain or the current domain).

Darn, of course it would.

In which case,* 301! has to be what you need!

Previously, when you said:

I tried your suggestion but any links with in it would stop redirecting after that

Did you ensure that it was a 301! and not a 301 rule?

Thanks, but that still only handles instances where the www subdomain is used, and has a path. With that redirect going to our any URL with will still fail to redirect. Is there any way with redirects to easily handle this, or something with the domain settings that will take care of this instead?

Damn, I really thought we’d be able to find a way which didn’t create cyclic rules. So, I should firstly apologise for wasting time!* 301!* 301!

Perhaps above is the cleanest way of tackling it after all (based on this). The http/https will be handled automagically, I believe.


1 Like

Thank you @Pie!!! Just updated and it appears to be working correctly now. I’m going to assume that the issues before were due to caching, and just letting it reset after some time allowed these to work as expected. So far this appears to work correctly for URLs with a path and without, for both the base domain and the www subdomain.

For anyone that might come across this, it looks like letting the site sit for a few days might be necessary. Triggering a deploy with cache clear did not seem to have any impact here.

Thank you again for all the help on this!