1385315 - Use 302 Found not 301 Moved Permanently for locale-based page redirects

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Localization, enhancement)

Description

[John Whitlock [:jwhitlock]]

What feature should be changed? Please provide the URL of the feature if possible.
==================================================================================
MDN pages are locale-specific, but often respond on a "generic" URL. For example, if a user requests https://developer.mozilla.org/docs/Web/CSS/display, they are redirected to a locale-specific URL like https://developer.mozilla.org/en-US/docs/Web/CSS/display.  The redirect is based on the Accept-Language header.

This redirect has a 301 MOVED PERMANENTLY status code, which tells the browser that it can change the URL in the future without asking the web server again, and includes a Vary: Accept-Language and Accept-Encoding header, to suggest to search engines and caches that the behavior will change on those headers, and to cache accordingly.

We want to change behavior on a cookie as well (bug 1331729), and will need to change this to a 302 Found redirect, so that the server will be in the request loop for all these requests.


What problems would this solve?
===============================
Browsers will remember a 301 redirect and not ask the server again. This means that any cookie-stored strategy will not be evaluated by Kuma.

Who would use this?
===================
Users who prefer to browse the web in a non-English language but view MDN in en-US.

What would users see?
=====================
For URLs without a locale, the middleware will check for a language-preference cookie before falling back to the Accept-Language header.

For URLs with a locale, the URL wins. Users will need to select English to see the English version.

Requests to URLs without a locale will be slightly slower for all users.

What would users do? What would happen as a result?
===================================================
Most users will have the same experience, but maybe less than a second slower for non-locale links.  This mostly affects users clicking links in translated documents.


Is there anything else we should know?
======================================
The 301 should continue to be used for the homepage, to keep https://developer.mozilla.org/en-US/ as the canonical homepage and ensure the highest level of caching.

RFC for response codes: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Google does not appear to have advice on 301 vs 302 for locale-specific pages:
https://support.google.com/webmasters/answer/182192?hl=en&ref_topic=2370587

Comment 1

[[github robot]]

Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/1cd606234106b94d69be9bfe596fdd26719128ba
[Bug 1385315] Use 302 not 301 for locale based redirect

Comment 2

[Safwan Rahman (:safwan)]

It was deployed long ago!

Comment 3

[Eric Shepherd [:sheppy]]

rroue: Can you provide a link to some information explaining why this is an issue? And how do we handle it for the different locales? Should every locale use 301? I assume so, but we need to confirm. There's a cookie that overrides the Accept-Language setting, too, and that has to be considered. We have to be sure we know all the details before we can plan this work.

Comment 4

[Raphael Raue [:raue] [:rraue]]

This is very tricky, as there are several ways and a lot of issues to handle crawlers the same good as users. Basically, Google advises in the document linked above not to redirect based on location or accept headers: 

"Avoid automatic redirection based on the user’s perceived language. These redirections could prevent users (and search engines) from viewing all the versions of your site."

We do redirect. But our issue is not that users or crawlers cant view all the evrsions of our site. We do have the language selector for users and the hreflang for crawlers. But our issue is something else: all the backlings to http://developer.mozilla.org and https://developer.mozilla.org could possibly be not counting, as the 302 tells that its moved but not permanent. These two pages will have most of mdns backlinks. 301 inherits all pagerank. 302s do sometimes. 


"We know sometimes Google will treat 302s as 301 redirects but we also have heard Matt Cutts say that 301s don't pass full PageRank - although that may have changed over the years.

So using a 302 is fine, although I'd still recommend a 301 where you know the move will stay in place forever. It is just that many folks use 302s without thinking and Google needs to handle it." says Googel: https://www.seroundtable.com/google-302-redirects-pass-pagerank-21575.html

So do we know if it does here? No. Do we know it doesnt? No. Can we test this? Not even the data when we changed it will tell us which influence it had. Because we changed a lot affecting Seo in the meantime. But we know, that google doesnt like a redirect based on language and the safer way would be a 301 for the domain root, as there are 80% of the backlinks handled. 

But its hard to make a recommendation, as I have to admit, I do not fully understand the issue with the cookie and its dpendecys. In general I would recommend to not redirect but use a good UI/UX to give users a strong hint to change the language themselfes if needed. But that would change the whole setup and therefor a maybe this will give our domain more link authority is at this moment not enough. Within time I could deliver more data if its necessary or not.

But for now: what would be the cons if we would change just for the root the 302 to a 301 like www does?

Comment 5

[John Whitlock [:jwhitlock]]

Re-posted to bug 1441672, the open bug. I'm convinced by the argument for using a 301 on the homepage, but I'd like to keep the 302 for other redirects, especially since page moves and slug changes are frequent.