You’ve rebuilt your website in Framer and connected your new domain. It looks great. But your old domain is still out there, in Google, in backlinks and on old business cards.
So you open Framer’s redirect settings to send it over. And you discover they can’t do that part.
Framer’s redirects work on paths inside the domain your site already uses. Moving visitors from a completely different domain needs to happen before the request ever reaches Framer.
What Framer’s redirects can and can’t do
Framer has a good built-in redirect system. In Site Settings → Redirects, you can send one path to another, use wildcards like /blog/*, and reuse parts of the old URL with capture groups.
That covers changes like:
yourstudio.com/work/old-project → yourstudio.com/projects/new-project
But Framer’s own help article is clear about the limit. You can only redirect sub-paths within your current domain. To redirect an entire domain, it tells you to set that up with the provider of the old domain.
So this won’t work inside Framer:
oldstudio.com → yourstudio.com
Why it can’t work inside Framer
When someone visits oldstudio.com, their browser asks DNS where that domain lives. If the old domain isn’t connected to your Framer project, the request never reaches Framer, so no rule there can run.
You could connect the old domain to a second Framer project just to redirect it. Some people do that with a redirect component. But it means paying for and maintaining an extra site, and it usually relies on a client-side redirect rather than a proper 301.
Something needs to answer for the old domain and reply with a real redirect. That’s a job for DNS plus a redirect service, not for your website.
The setup that works
Keep the old domain registered. Don’t let it expire, even if the old website is gone.
Connect the old domain to a redirect service. With Redirect Supply, you add the domain and get a short set of DNS records to add at your registrar.
Create your redirect rules. Send the old domain, and ideally its important pages, to the matching pages on your Framer site.
Test it. Check both
http://andhttps://, with and withoutwww.
Your Framer site doesn’t change at all. It keeps its own domain and its own internal redirects.
Don’t send everything to the homepage
It’s tempting to forward the whole old domain to your new homepage. For a parked or campaign domain, that’s fine.
But if the old domain used to host a full website, its pages still have links and rankings. Send them somewhere useful:
oldstudio.com/pricing → yourstudio.com/pricing
oldstudio.com/blog/* → yourstudio.com/blog/*
oldstudio.com → yourstudio.com as a catch-all for everything else
The wildcard rule carries the rest of the path across. So oldstudio.com/blog/framer-tips lands on yourstudio.com/blog/framer-tips, as long as your Framer slugs stayed the same.
Read more about how rule priority works in our path redirects docs.
Combine both kinds of redirects
In a real migration, you’ll often use both:
Redirect Supply for the old domain, sending it to your new domain.
Framer’s redirects for paths that changed on the new domain itself.
For example, the old domain sends /case-studies/* to yourstudio.com/case-studies/*. Then a Framer redirect sends /case-studies/* on your new site to /work/*, because you renamed the section.
That works, but it creates two hops. Where you can, point the old domain straight at the final URL. It keeps things faster and cleaner for search engines.
A real example
Say you’re a studio moving from oldstudio.com, built years ago on WordPress, to newstudio.com, built in Framer. A sensible set of rules looks like this:
oldstudio.com/ → newstudio.com/
oldstudio.com/services/* → newstudio.com/services
oldstudio.com/blog/* → newstudio.com/blog/*
oldstudio.com/contact → newstudio.com/contact
* → newstudio.com/ as the catch-all
The services section was restructured, so its old pages go to the new overview. The blog kept its slugs, so the wildcard keeps every post’s path. Everything else falls through to the homepage.
Five rules cover a site with hundreds of URLs. That’s usually how it goes: a handful of patterns does most of the work.
Keep the old domain registered
The redirect only works as long as you control the old domain. Set it to auto-renew, and keep the DNS login somewhere your team can find it.
If the old domain expires, someone else can register it, and every link pointing to it starts sending people to them.
What about HTTPS?
People will visit the old domain over https://, especially if it ever had a certificate. If whatever answers for the old domain can’t complete a secure connection, the browser shows an error before the redirect runs.
Redirect Supply issues and renews certificates for connected domains automatically, so both http:// and https:// work.
Checking the result
Once the DNS records are in place and the domain shows as Connected, run a few old URLs through our free redirect tester. You’ll see each hop, its status code, and where it lands.
If you’re comparing options, we’ve also written up Redirect Supply vs Framer redirects in more detail.
