Ability to send 301 status code in App router when permanentRedirect

[WavyWalk]

Goals

1. be able to specify 301 as a status code for permanent redirect.

Background

During migration from page to app router, we faced an issue that we can not send 301 redirect as permanentRedirect sends a 308 status code by default.

Sending 301 instead of 308 is a hard requirement from our SEO team.

We do now patching the package to not block the migration but that's mess.

Would be just great to be able to do it. Implementation according to source code shall also be not complicated.

Proposal

User shall be able to specify the status code he prefers.

By default 308 is used, 301 will be used only if it is directly specified.

Change does not break signature of permanentRedirect function.

New argument is provided as object to allow future extensions.

We could contribute.

permanentRedirect(
   '/foo', 
   undefined | RedirectType, // if undefined defaults to what it defaulted to before  
   { // optional new arg, suggest object, to allow future additions if they will be required.
     useStatusCode: 301 | 308
   }
)

example usage:

permanentRedirect('foo') // default 308
permanentRedirect('foo', undefined, { useStatusCode: 301 }) // will use 301 as status code, type is default
permanentRedirect('foo', 'push', {useStatusCode: 301})

[Netail]

Interesting, however 301 & 302 mean the HTTP method can change, while 307 & 308 do not.
Webpages are always a GET, thus making 307 & 308 more appropriate. HTTP 301 & 302 can be used for backend/api endpoints.

More on the HTTP redirect specs; https://stackoverflow.com/questions/42136829/whats-the-difference-between-http-301-and-308-status-codes

In terms of SEO, this should not matter. (article)

[WavyWalk]

Thanks for providing details, for devs it's clear.

We used same arguments with our SEO people, their position is:

• 301 works for SEO already, they can't risk trying out 308s
• there's not much proven successfull usage of 308s in SEO community

For such simple thing we have to make an experiment on set of pages to prove that 308 would behave same (which will take month or more), as well as patch next to use 301s for now.

[lightningspirit]

I'm also on the same position right now. The SEO specialists have 301 and 302 as hard requirements. Technically speaking, it looks like that for Google it shouldn't matter, however that's not their perspective nor the data they've collected. Hence, it would be important, for us devs, to be able to override the status code as a third parameter (maybe?).

EDIT:
Referring to the article that @Netail quoted, it states:

While Google treats 308 redirects on par with 301 redirects, it is crucial to note that 308 redirects do not inherently provide superior SEO benefits. They can offer technical advantages in specific scenarios, particularly when there is uncertainty about the request type.

As per their discoveries, there are no superior SEO benefits of 308, only the advantage (I believe when they say "technical advantages") that browsers respect verbs that were previously used.

Additionally, the StackOverflow article that @Netail mentioned includes a chart showing cases where 301 or 302 redirects are preferable.

Since I'm not aware of any deprecation warnings for 301 and 302 redirects, I believe it's important to implement this. I'm willing to open a PR for the change, provided core developers agree to move forward with that.