Handling >1,000 redirects with Next.js...seemingly impossible.
Unanswered
Barn Swallow posted this in #help-forum
Barn SwallowOP
Before we rebuilt our site on Next.js, our site was based in WordPress, and there weren't a lot of ideal decisions made prior to my coming on board related to URL site structure, much of which was based in SEO understandings at the time (i.e. have as much as possible at the top level, like site.com/my-blog-post, site.com/my-page, etc). Exacerbated by WordPress plugins that allowed endless redirects, we now lug around a pretty hefty amount of redirects, close to 1,000, as we've restructured content over the years to better accomodate.
It's a pretty big issue. Thousands upon thousands of historical inbound links would immediately break if we dumped most of these, and the way Google is handling SEO and 404s and authority at the moment, it would be really bad. So I'm not interested in the "just don't have that many redirects", because we're already working on that piece. I'm trying to figure out how to performantly handle this many redirects of varying kinds in the meantime.
Has anyone effectively managed to handle an astronomical amount of redirects? Edge Config seems fully out of the question, with the 64kb limit, and next.config redirects has a limit of 1024. Just looking for more options to figure these sorts of things out.
It's a pretty big issue. Thousands upon thousands of historical inbound links would immediately break if we dumped most of these, and the way Google is handling SEO and 404s and authority at the moment, it would be really bad. So I'm not interested in the "just don't have that many redirects", because we're already working on that piece. I'm trying to figure out how to performantly handle this many redirects of varying kinds in the meantime.
Has anyone effectively managed to handle an astronomical amount of redirects? Edge Config seems fully out of the question, with the 64kb limit, and next.config redirects has a limit of 1024. Just looking for more options to figure these sorts of things out.
8 Replies
American Crow
Not the same but had a similar use case:
I have about 10 thousand rewrites for localized pathnames (slugs) in 13 languages. That's done via middleware. No performance issues
I have about 10 thousand rewrites for localized pathnames (slugs) in 13 languages. That's done via middleware. No performance issues
Barn SwallowOP
@American Crow 👀
What method? Just straight bulk json?
@Barn Swallow <@240974567730970625> 👀
American Crow
Pretty much yeah. Using next-intl middleware wrapper since it does the rewrites for me but it's just looking up the paths in a gigantic json file. Didn't really get into it how it's handled internally just saying it's performant
Barn SwallowOP
Yeah wondering if that's a better method than the next.config.
so you do something like, import the json, check the path against it, force a middleware rewrite and move on?
American Crow
Yes pretty much. I can't help you much just point you to the docs of next-intl. As i said i never put too much thought into it i just tried it with a huge set of data to see if it can handle it and yea it can. Did some Lighthouse tests and i am satisfied.
https://next-intl-docs.vercel.app/docs/routing/middleware#localizing-pathnames
i basically have the setup as you can see in this^ link. Just have the pathrewrites in a separate file and above 10k of them.
https://next-intl-docs.vercel.app/docs/routing/middleware#localizing-pathnames
i basically have the setup as you can see in this^ link. Just have the pathrewrites in a separate file and above 10k of them.
Barn SwallowOP
Maybe I'll give that a go then, what's the worst that could happen 🙃