Closed Bug 481550 Opened 11 years ago Closed 6 years ago

[SEO] Implement canonical and alternate URLs (www.mozilla.org)

Categories

(www.mozilla.org :: General, enhancement)

enhancement
Not set

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kohei, Assigned: kohei)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

Google caches https://www-trunk.stage.mozilla.com/ because the stating site has not been password-protected for some time. www.mozilla.com is also accessible via SSL (https). Are you aware of the situation?
Summary: Implement canonical URL → Implement canonical URL (www.mozilla.com)
Yes, aware as this has happened recently. What are the solutions here besides password protecting? Would be nice for this not to happen, but also want to make staging/trunk easy to preview?
Target Milestone: --- → 2.2
Target Milestone: 2.2 → 2.3
Target Milestone: 2.3 → Future
https://encrypted.google.com/search?q=site:mozilla.com/en-US/firefox/

We can still find some variations...

https://www.mozilla.com/
sjc.mozilla.com
nova.stage.mozilla.com
www.sv-se.www.mozilla.com
en-us.www-trunk.stage.mozilla.com
hagege.stage.mozilla.com
Severity: normal → major
Summary: Implement canonical URL (www.mozilla.com) → [SEO] Implement canonical URL (www.mozilla.com)
Duplicate of this bug: 681753
Hey Anthony - Can you help out here?
Assignee: nobody → anthony
Target Milestone: Future → 3.9
Blocks: 667557
Hey Anthony - what's the status of this bug? Can you help out here? Let me know as this is set for next week's release (next Tue).
http://www.google.com/search?hl=en&q=Firefox now shows
http://sjc.mozilla.com/en-US/firefox/new/ as our homepage. Too bad :(
Severity: major → blocker
You can also find www.en-us.www.mozilla.com/en-US/firefox/beta/ as the second position.
Attached patch revised patch (obsolete) — Splinter Review
Attachment #365579 - Attachment is obsolete: true
Rather than using rel=canonical, I think we should use 301 redirects. It gives the right information to robots but also redirect users.

I think the problem is worse on Google because of the recent merge.

CCing Jake to help us with this.
We should kill sjc.m.c, nova.stage.m.c and hagege.stage.m.c (and redirect everything to mozilla.org/firefox).

For the locales inside the domain, I need to talk with Pascal and see how/when it is needed.
FWIW, when I google for 'Firefox' the first result is www.mozilla.org/firefox. This is even when using the links in comments 8 and 9. The second result is www.mozilla.org/firefox/fx, and the third is www.getfirefox.net. The locale and location URLs do not appear on the first page at all.

I have no idea what nova.stage.mozilla.com and hagege.stage.mozilla.com are, but I found them (on mrapp-stage02, for the record). I can remove their content and turn them into redirects easily enough. Being that they're apparently stage sites, should they redirect to the current mozilla.org stage site (bug 682398) instead of prod?

sjc.mozilla.com will be a bit more complicated. That's used as the origin host for the CDN... we'll need to change that first. I need to investigate why this was created in the first place before changing it.
Thanks Jake.

For google results, they are really "bouncy" these days. One day I get mozilla.org/firefox, another day I get sjc.mozilla.com (with Sitelinks).

For nova and hagege, I'd rather redirect to the prod mozilla.org/firefox. We're not using them anymore so if that can "boost" a bit our pagerank, it's cool. Once it's done, I'll delete the SVN branches.

For sjc.mozilla.com, if the investigation is not successful, we should put a robots.txt preventing Google to index it. But it's better to figure out if we can change that.
nova.stage.m.c and hagege.stage.m.c redirects are both in place. There were some 301 redirects in place already (at least for nova.stage), so if you want to test I recommend clearing your browser cache.

Unfortunately we can't just robots.txt on sjc.mozilla.com. It's just a ServerAlias to www.mozilla.org, and thus uses the same DocumentRoot. Still inquiring on this.
Duplicate of this bug: 684755
Target Milestone: 3.9 → 3.10
Target Milestone: 3.10 → 3.12
Is this still happening? It kinda fell off my radar in the last couple weeks.

The only thing I know of that for sure uses sjc.mozilla.com is the CDN, which I should be able to change easily enough. On the other hand if the problem has gone away due to improved Google indexing or something, it might not be worth messing with. :)
Anthony - Any updates here?
I'm not seeing sjc.m.c on the first page results. But we still have results coming from sjc.mozilla.com listed : http://www.google.com/search?q=site:sjc.mozilla.com.

I think we should really not expose something else than the real website. And for those that are exposed (like trunk and stage) disallow indexing in robots.txt.

For the locales, I haven't talked about it with Pascal yet.
Talked with Pascal about the locales. All the {locale}.mozilla.com and www.{locale}.mozilla.com have never been used for real and don't have the logic to read and enforce the locale. So we can just redirect them to www.mozilla.org/firefox directly.

Jake, we can do this on our side but maybe it is easier to do this at the vhost level?
Target Milestone: 3.12 → 3.10
Target Milestone: 3.10 → 3.12
What is it that's broken about how the (www.)?<locale>.mozilla.com URLs are treated now?

http://en-us.www.mozilla.com/ already redirects to http://www.mozilla.org/firefox for me. Do we have any cases where this isn't already working?
Target Milestone: 3.12 → 4.0
Target Milestone: 4.0 → 4.1
Target Milestone: 4.1 → 4.2
Target Milestone: 4.2 → 4.3
Target Milestone: 4.3 → 4.4
Target Milestone: 4.4 → Future
Anthony, friendly ping, can you provide an update on where you are with this bug? TX!
As Jake mentions, those redirects are already in place so I'm gonna close this.

Also, see bug 697243 to remove some code that deals with those locale domains but is useless now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Hey guys, this bug is NOT FIXED yet. (It should be WONTFIX at least)

You have to implement rel="canonical" anyway to prevent the SSL site and stating site from being cached:
https://www.google.com/search?q=allinurl:https://www.mozilla.org/+site:mozilla.org
https://www.google.com/search?q=site:www-dev.allizom.org

sjc.mozilla.com is still indexed:
https://www.google.com/search?q=site:sjc.mozilla.com

This should be filed as another bug under the mozilla.org component but www-stage.mozilla.org is cached:
http://www.google.co.jp/search?q=site:www-stage.mozilla.org
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: anthony → nobody
Severity: blocker → normal
Along with rel="canonical", it's nice to have rel="alternate" hreflang="x" to combine indexing signals (aka PageRank) among locales.

http://googlewebmastercentral.blogspot.com/2011/12/new-markup-for-multilingual-content.html
http://support.google.com/webmasters/bin/answer.py?hl=en&answer=189077

<link rel="canonical" href="http://www.mozilla.org/en-US/firefox/">
<link rel="alternate" hreflang="af" href="http://www.mozilla.org/af/firefox/">
<link rel="alternate" hreflang="ar" href="http://www.mozilla.org/af/firefox/">
          :
<link rel="alternate" hreflang="en" href="http://www.mozilla.org/en-US/firefox/">
          :
Blocks: 722848
No longer blocks: 667557
I don't think we can avoid google showing www-dev.allizom.org URLs. http://www-dev.allizom.org/robots.txt already disallow robots. Google is only listing URLs, no title or content. And I only see one URL.

http://www.allizom.org/robots.txt should disallow robots.
(In reply to Anthony Ricaud (:rik) from comment #28)
> I don't think we can avoid google showing www-dev.allizom.org URLs.

I think we *can* do so, and importantly can consolidate the distributed PageRanks to www.m.o by using the canonical URLs instead of blocking access to the duplicated content. If you implement the canonical URLs and remove the following directive, the allizom URLs will be gone from Google's SERP after a while.

> User-agent: *
> Disallow: /
(Yeah, I know Allizom not exactly duplicated contents.)
As I wrote in Bug 743202, implementing 302 redirects and canonical URLs would be a better option. Google's Blogger service is adopting such approach. We always want to see URLs like http://www.mozilla.org/firefox/ on SERP. With the canonical URLs, we can 

a. avoid search engines indexing mixture of URLs with and without locale code like
http://www.mozilla.org/fr/firefox/
http://www.mozilla.org/it/firefox/
(use 302 redirect from http://www.mozilla.org/firefox/)

b. avoid search engines indexing the specific landing page URLs like
http://www.mozilla.org/en-US/firefox/fx/
http://www.mozilla.org/en-US/firefox/new/
(use 302 redirect from http://www.mozilla.org/firefox/)

c. avoid search engines indexing secure "https" URLs like
https://www.mozilla.org/en-US/firefox/

d. avoid search engines indexing the allizom stating URLs like
http://www.allizom.org/en-US/firefox/fx/
http://www-dev.allizom.org/en-US/firefox/fx/

e. show the single ideal URL on SERP
http://www.mozilla.org/firefox/

f. consolidate the distributed PageRanks to the canonical URL
So what's the next step here?
(In reply to Kohei Yoshino from comment #29)
> I think we *can* do so, and importantly can consolidate the distributed
> PageRanks to www.m.o by using the canonical URLs instead of blocking access
> to the duplicated content. If you implement the canonical URLs and remove
> the following directive, the allizom URLs will be gone from Google's SERP
> after a while.

Here's our own example: http://mozilla.jp/

It's also accessible with http://www.mozilla.jp/ for some reason, and such www'd URL is linked from somewhere, somehow; e.g. http://www.mozilla.org/contribute/local/asia.html

But Google won't index www'd URLs because we have implemented canonical URLs.
https://www.google.com/search?q=site:www.mozilla.jp

(In reply to Kohei Yoshino from comment #31)
> As I wrote in Bug 743202, implementing 302 redirects and canonical URLs
> would be a better option. Google's Blogger service is adopting such
> approach. We always want to see URLs like http://www.mozilla.org/firefox/ on
> SERP. With the canonical URLs, we can 
> 
> a. avoid search engines indexing mixture of URLs with and without locale
> code like
> http://www.mozilla.org/fr/firefox/
> http://www.mozilla.org/it/firefox/
> (use 302 redirect from http://www.mozilla.org/firefox/)

I was wrong here :( The redirecting http://www.mozilla.org/firefox/ to http://www.mozilla.org/en-US/firefox/ or other locales should always be 301 Perm, or the localized indexed pages and those descriptions may not be indexed. The canonical URLs also need the corresponding locale. And hreflang may also be used.

> b. avoid search engines indexing the specific landing page URLs like
> http://www.mozilla.org/en-US/firefox/fx/
> http://www.mozilla.org/en-US/firefox/new/
> (use 302 redirect from http://www.mozilla.org/firefox/)

The redirecting http://www.mozilla.org/en-US/firefox/ to /en-US/firefox/new/ and /en-US/firefox/fx/ should be 302 Temp. Then Google will index /en-US/firefox/ instead of /en-US/firefox/new/ or /en-US/firefox/fx/. I'll update Bug 743202.

> e. show the single ideal URL on SERP
> http://www.mozilla.org/firefox/

This wasn't right either. The ideal URLs are with locale as noted above.
http://www.mozilla.org/en-US/firefox/
(In reply to John Slater from comment #32)
> So what's the next step here?

I'm not familiar with the new Bedrock backend (Git/Python) but the patch may be simple like this...

On each page:
https://github.com/mozilla/bedrock/blob/master/apps/firefox/templates/firefox/central.html

> {% block page_path %}/firefox/central/{% endblock %}

The page path will also need when you re-implement breadcrumbs (Bug 705535)

On the master template:
https://github.com/mozilla/bedrock/blob/master/templates/base.html

> <link rel="canonical" href="http://www.mozilla.org/{{ LANG }}/{% block page_title %}{% endblock %}">
Attachment #558271 - Attachment is obsolete: true
(In reply to Kohei Yoshino from comment #34)
> > <link rel="canonical" href="http://www.mozilla.org/{{ LANG }}/{% block page_title %}{% endblock %}">

I mean page_path, not page_title...
Severity: normal → enhancement
(In reply to Kohei Yoshino from comment #35)
> (In reply to Kohei Yoshino from comment #34)
> > > <link rel="canonical" href="http://www.mozilla.org/{{ LANG }}/{% block page_title %}{% endblock %}">
> 
> I mean page_path, not page_title...

Hm, close. I think every page can determine its own canonical URL (by looking at the request), though it might not make sense to define it everywhere if it'll just point to the same URL anyway.

However, making it overwritable via a block seems to make sense. (Also, please use the url() helper).
(In reply to Fred Wenzel [:wenzel] from comment #36)
> Hm, close. I think every page can determine its own canonical URL (by
> looking at the request), though it might not make sense to define it
> everywhere if it'll just point to the same URL anyway.

Oh. My original patch (attachment 558271 [details] [diff] [review], PHP) uses $_SERVER['REDIRECT_URL'] and our mozilla.jp backend uses $_SERVER['REQUEST_URI'] to determine the canonical URL.

> However, making it overwritable via a block seems to make sense. (Also,
> please use the url() helper).

Yes. For example, /en-US/firefox/new/ and /en-US/firefox/fx/ will use /en-US/firefox/ as the canonical URL. (Bug 743202)
Blocks: 745355
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Blocks: 838405
Closing for now.  We will ask our new SEO partner for assistance with creating canonical URLs that will work within our structure.
Status: NEW → RESOLVED
Closed: 8 years ago7 years ago
Resolution: --- → INCOMPLETE
This is still valid... Google is indexing many pages on the SSL and staging sites:

https://www.google.com/search?q=allinurl:https://www.mozilla.org/+site:www.mozilla.org&filter=0
https://www.google.com/search?q=site:https://www.allizom.org/&filter=0

With .htaccess you cannot prevent Google from indexing those pages. You can use <meta name="robots" content="noindex"> instead but end up losing PageRank. So canonical URL is better.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
(In reply to Kohei Yoshino from comment #39)
> This is still valid... Google is indexing many pages on the SSL and staging
> sites:
> 
> https://www.google.com/search?q=allinurl:https://www.mozilla.org/+site:www.
> mozilla.org&filter=0
> https://www.google.com/search?q=site:https://www.allizom.org/&filter=0
> 
> With .htaccess you cannot prevent Google from indexing those pages. You can
> use <meta name="robots" content="noindex"> instead but end up losing
> PageRank. So canonical URL is better.

In the Google Webmaster tools, I have mozilla.org and www.mozilla.org as two websites with www.mozilla.org has the preferred domains on both.

We also have bots/spiders blocked from non-prod sites here:

https://www.allizom.org/robots.txt

I think I would prefer having something like the following on each page that is dynamic to the URL being displayed:

<link rel="canonical" href="https://www.mozilla.org/foo" />

What are your thoughts on http vs https in the canonical reference? Should that also be dynamic or can it also use "//www.mozilla.org/foo".

Thanks!
I think "canonical" URLs should start with http://www.mozilla.org/
//www.mozilla.org may confuse Googlebot.
(In reply to Kohei Yoshino from comment #41)
> I think "canonical" URLs should start with http://www.mozilla.org/
> //www.mozilla.org may confuse Googlebot.

Nah, that's a valid notation for an href.
(In reply to Fred Wenzel [:wenzel] from comment #42)
> Nah, that's a valid notation for an href.

Sure it's valid, but a canonical URL should be unique.
Starting with http:// is safe here.
Status: REOPENED → NEW
Blocks: 834422
Once Bug 796109 is resolved, we have to use https:// of course.
Duplicate of this bug: 875293
* Merged with the alternate URL bug. (Bug 875293)
* Alternate URL will be needed to implement OGP and Twitter Cards. (Bug 834422)
* Moved the backend implementation from Bug 773371, that exposes the translation list of the current page. So the lang switcher won't block this bug and Bug 834422.

Pull request: https://github.com/mozilla/bedrock/pull/1005
Assignee: nobody → kohei.yoshino.bugs
Status: NEW → ASSIGNED
Summary: [SEO] Implement canonical URL (www.mozilla.com) → [SEO] Implement canonical and alternate URLs (www.mozilla.com)
Blocks: 773371
(In reply to Kohei Yoshino [:kohei] from comment #46)
> * Alternate URL will be needed to implement OGP and Twitter Cards.

I mean, Canonical URL will be needed...
No longer blocks: 773371
Depends on: 903886
No longer blocks: 834422
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/03ad73dad26e0ed66edbd0ca5e340e7f7c7c0d49
Bug 481550 - Implement canonical and alternate URLs

https://github.com/mozilla/bedrock/commit/f2cfc57029bfe8f5122e5a86182f4c4dfacc185e
Merge pull request #1005 from kyoshino/bug-481550-canonical

Bug 481550 - Implement canonical and alternate URLs
Summary: [SEO] Implement canonical and alternate URLs (www.mozilla.com) → [SEO] Implement canonical and alternate URLs (www.mozilla.org)
Woo hoo!

https://www-dev.allizom.org/en-US/firefox/new/
https://www-dev.allizom.org/en-US/firefox/os/

Is there is reason why only the canonical is fully qualified and the alternatives are relative?
FYI: these are now on production.
(In reply to Chris More [:cmore] from comment #49)
> Is there is reason why only the canonical is fully qualified and the
> alternatives are relative?

Hmm, it's my mistake... I checked Google's resources and all of those used fully qualified URLs. Here's a follow-up pull request to fix it:

https://github.com/mozilla/bedrock/pull/1235/files
(In reply to Kohei Yoshino [:kohei] from comment #51)
> (In reply to Chris More [:cmore] from comment #49)
> > Is there is reason why only the canonical is fully qualified and the
> > alternatives are relative?
> 
> Hmm, it's my mistake... I checked Google's resources and all of those used
> fully qualified URLs. Here's a follow-up pull request to fix it:
> 
> https://github.com/mozilla/bedrock/pull/1235/files

Ok, good. Let's see if we can push to get a review on this change as the current setup is not correct. thanks
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/b65d4524282d4b7897b7752c62fe64cd9b826ea7
Bug 481550 follow up: make alternate URLs fully qualified

https://github.com/mozilla/bedrock/commit/511ba2427b0bcb0e6a5bd1cad29a0bd582297d43
Merge pull request #1235 from kyoshino/bug-481550-canonical

Bug 481550 follow up: make alternate URLs fully qualified
Looks good on -dev now:

     <link rel="canonical" hreflang="en-US" href="http://www.mozilla.org/en-US/firefox/os/">
    <link rel="alternate" hreflang="x-default" href="http://www.mozilla.org/firefox/os/">
          <link rel="alternate" hreflang="cs" href="http://www.mozilla.org/cs/firefox/os/" title="Čeština">
      <link rel="alternate" hreflang="cy" href="http://www.mozilla.org/cy/firefox/os/" title="Cymraeg">
      <link rel="alternate" hreflang="de" href="http://www.mozilla.org/de/firefox/os/" title="Deutsch">
      <link rel="alternate" hreflang="el" href="http://www.mozilla.org/el/firefox/os/" title="Ελληνικά">
      <link rel="alternate" hreflang="en-US" href="http://www.mozilla.org/en-US/firefox/os/" title="English (US)">
      <link rel="alternate" hreflang="es-AR" href="http://www.mozilla.org/es-AR/firefox/os/" title="Español (de Argentina)">
      <link rel="alternate" hreflang="es-CL" href="http://www.mozilla.org/es-CL/firefox/os/" title="Español (de Chile)">
      <link rel="alternate" hreflang="es-ES" href="http://www.mozilla.org/es-ES/firefox/os/" title="Español (de España)">
      <link rel="alternate" hreflang="es-MX" href="http://www.mozilla.org/es-MX/firefox/os/" title="Español (de México)">
      <link rel="alternate" hreflang="fr" href="http://www.mozilla.org/fr/firefox/os/" title="Français">
      <link rel="alternate" hreflang="hu" href="http://www.mozilla.org/hu/firefox/os/" title="magyar">
      <link rel="alternate" hreflang="pl" href="http://www.mozilla.org/pl/firefox/os/" title="Polski">
      <link rel="alternate" hreflang="pt-BR" href="http://www.mozilla.org/pt-BR/firefox/os/" title="Português (do Brasil)">
      <link rel="alternate" hreflang="ro" href="http://www.mozilla.org/ro/firefox/os/" title="română">
      <link rel="alternate" hreflang="sr" href="http://www.mozilla.org/sr/firefox/os/" title="Српски">
      <link rel="alternate" hreflang="ur" href="http://www.mozilla.org/ur/firefox/os/" title="اُردو">
on stage
        <link rel="canonical" hreflang="en-US" href="http://www.mozilla.org/en-US/firefox/os/">
    <link rel="alternate" hreflang="x-default" href="/firefox/os/">
          <link rel="alternate" hreflang="cs" href="/cs/firefox/os/" title="Čeština">
      <link rel="alternate" hreflang="de" href="/de/firefox/os/" title="Deutsch">
      <link rel="alternate" hreflang="el" href="/el/firefox/os/" title="Ελληνικά">
      <link rel="alternate" hreflang="en-US" href="/en-US/firefox/os/" title="English (US)">
      <link rel="alternate" hreflang="es-AR" href="/es-AR/firefox/os/" title="Español (de Argentina)">
      <link rel="alternate" hreflang="es-CL" href="/es-CL/firefox/os/" title="Español (de Chile)">
      <link rel="alternate" hreflang="es-ES" href="/es-ES/firefox/os/" title="Español (de España)">
      <link rel="alternate" hreflang="es-MX" href="/es-MX/firefox/os/" title="Español (de México)">
      <link rel="alternate" hreflang="fr" href="/fr/firefox/os/" title="Français">
      <link rel="alternate" hreflang="hu" href="/hu/firefox/os/" title="magyar">
      <link rel="alternate" hreflang="pl" href="/pl/firefox/os/" title="Polski">
      <link rel="alternate" hreflang="pt-BR" href="/pt-BR/firefox/os/" title="Português (do Brasil)">
      <link rel="alternate" hreflang="ro" href="/ro/firefox/os/" title="română">
      <link rel="alternate" hreflang="sr" href="/sr/firefox/os/" title="Српски">
(In reply to raymond [:retornam] (needinfo? me) from comment #55)
> on stage
>         <link rel="canonical" hreflang="en-US"
> href="http://www.mozilla.org/en-US/firefox/os/">
>     <link rel="alternate" hreflang="x-default" href="/firefox/os/">
>           <link rel="alternate" hreflang="cs" href="/cs/firefox/os/"
> title="Čeština">
>       <link rel="alternate" hreflang="de" href="/de/firefox/os/"
> title="Deutsch">
>       <link rel="alternate" hreflang="el" href="/el/firefox/os/"
> title="Ελληνικά">
>       <link rel="alternate" hreflang="en-US" href="/en-US/firefox/os/"
> title="English (US)">
>       <link rel="alternate" hreflang="es-AR" href="/es-AR/firefox/os/"
> title="Español (de Argentina)">
>       <link rel="alternate" hreflang="es-CL" href="/es-CL/firefox/os/"
> title="Español (de Chile)">
>       <link rel="alternate" hreflang="es-ES" href="/es-ES/firefox/os/"
> title="Español (de España)">
>       <link rel="alternate" hreflang="es-MX" href="/es-MX/firefox/os/"
> title="Español (de México)">
>       <link rel="alternate" hreflang="fr" href="/fr/firefox/os/"
> title="Français">
>       <link rel="alternate" hreflang="hu" href="/hu/firefox/os/"
> title="magyar">
>       <link rel="alternate" hreflang="pl" href="/pl/firefox/os/"
> title="Polski">
>       <link rel="alternate" hreflang="pt-BR" href="/pt-BR/firefox/os/"
> title="Português (do Brasil)">
>       <link rel="alternate" hreflang="ro" href="/ro/firefox/os/"
> title="română">
>       <link rel="alternate" hreflang="sr" href="/sr/firefox/os/"
> title="Српски">

It hasn't been pushed to stage yet. The URLs should be absolute as they are on -dev.
Fixed on prod: https://www.mozilla.org/en-US/firefox/os/ :)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: Future → ---
fixed on prod
<link rel="alternate" hreflang="x-default" href="http://www.mozilla.org/firefox/os/">
          <link rel="alternate" hreflang="cs" href="http://www.mozilla.org/cs/firefox/os/" title="Čeština">
      <link rel="alternate" hreflang="de" href="http://www.mozilla.org/de/firefox/os/" title="Deutsch">
      <link rel="alternate" hreflang="el" href="http://www.mozilla.org/el/firefox/os/" title="Ελληνικά">
      <link rel="alternate" hreflang="en-US" href="http://www.mozilla.org/en-US/firefox/os/" title="English (US)">
      <link rel="alternate" hreflang="es-AR" href="http://www.mozilla.org/es-AR/firefox/os/" title="Español (de Argentina)">
      <link rel="alternate" hreflang="es-CL" href="http://www.mozilla.org/es-CL/firefox/os/" title="Español (de Chile)">
      <link rel="alternate" hreflang="es-ES" href="http://www.mozilla.org/es-ES/firefox/os/" title="Español (de España)">
      <link rel="alternate" hreflang="es-MX" href="http://www.mozilla.org/es-MX/firefox/os/" title="Español (de México)">
      <link rel="alternate" hreflang="fr" href="http://www.mozilla.org/fr/firefox/os/" title="Français">
      <link rel="alternate" hreflang="hu" href="http://www.mozilla.org/hu/firefox/os/" title="magyar">
      <link rel="alternate" hreflang="pl" href="http://www.mozilla.org/pl/firefox/os/" title="Polski">
      <link rel="alternate" hreflang="pt-BR" href="http://www.mozilla.org/pt-BR/firefox/os/" title="Português (do Brasil)">
      <link rel="alternate" hreflang="ro" href="http://www.mozilla.org/ro/firefox/os/" title="română">
      <link rel="alternate" hreflang="sr" href="http://www.mozilla.org/sr/firefox/os/" title="Српски">
Status: RESOLVED → VERIFIED
Duplicate of this bug: 743202
You need to log in before you can comment on or make changes to this bug.