It should do that already :o

Ah, yes, see: T91183: Make MobileFrontend add a mobile rel=alternative to the desktop version instead of noindexing mobile pages

Change 212022 had a related patch set uploaded (by Florianschmidtwelzow):
Enable alternate and canonical links for mobile/desktop pages

https://gerrit.wikimedia.org/r/212022

Change 212021 had a related patch set uploaded (by Florianschmidtwelzow):
Hygiene: Correctly add alternate and canocial links

https://gerrit.wikimedia.org/r/212021

I'm not sure, if enabling it has any unexpected side effects :/ Mobile pages aren't blocked by robots.txt (i remember i read something like that), but i think @MaxSem had some reason to set $wgMFNoindexPages to false in https://gerrit.wikimedia.org/r/#/c/46542/ :)

Change 212021 merged by jenkins-bot:
Correctly add alternate and canocial links

https://gerrit.wikimedia.org/r/212021

• https://gerrit.wikimedia.org/r/212021 (branch master): WMF-deploy-2015-06-16_(1.26wmf10)

I'm not really happy, that this is already marked as resolved, see my last comment :)

In T99587#1296865, @Florian wrote:

I'm not sure, if enabling it has any unexpected side effects :/ Mobile pages aren't blocked by robots.txt (i remember i read something like that), but i think @MaxSem had some reason to set $wgMFNoindexPages to false in https://gerrit.wikimedia.org/r/#/c/46542/ :)

It would be great, if we can discuss to enable this on wmf wikis :) (proposed in change https://gerrit.wikimedia.org/r/#/c/212022/)

@MaxSem can you comment?
@Florian I'll add it to the sprint board so this doesn't get lost and gets signed off and any bugs that need to be opened are.

Ping @MaxSem, @kaldari: Can you provide additional context for 46542 – why $wgMFNoIndexPages was set to false for a sample of articles?

Indexing of the mobile site was initially disabled due to Google screwups (mixing mobile results with desktop on desktop searches, etc). Enabling back for a subset was an attempt to check if it was fixed, as out Google contacts claimed.

Thanks for your feedback @MaxSem :) Hmm, what project do you suggest? Maybe a little wikipedia first (maybe and all others if that works like expected?

I would suggesting trying Wikivoyage? It's search rankings can only improve.. ! :)

@Florian: Do you think the use of Title#getFullURL avoids the problems tracked by T93550. I've taken a quick look at the source and it seems so, but there's a hook in there too…

@phuedx Hmm, I can't reproduce this problem for "our" canonical/alternate tag, I tested the following cases:
(mobile) /w/index.php?title=Main_Page
-> canonical tag with (desktop-url)/wiki/Main_Page

(mobile)/wikki/Main_Page
-> canonical tag with (desktop-url)/wiki/Main_Page

(desktop)/w/index.php?title=Main_Page
-> alternate tage with (mobile-url and max-width 768px)/wiki/Main_Page

(desktop)/wiki/Main_Page
-> alternate tage with (mobile-url and max-width 768px)/wiki/Main_Page

But it's possible that I have something somewhere in my local setup, so we probably should wait with changing anything in this direction until T93550 or at least T67402 is resolved, just to be sure :)

Btw.: I see, that we would add the alternate and canonical links for all actions, not just for view, so the edit page would have these tags, too, which sounds pretty false to me. Any input? :)

@Florian: How is this affected by the work in T67402 as well? It looks like the related patches give us canonical URL generation for free. One thing worth noting is that the inclusion of the canonical link is behind a feature flag in core, i.e. $wgEnableCanonicalServerLink, whereas in core it's something else.

Btw.: I see, that we would add the alternate and canonical links for all actions, not just for view, so the edit page would have these tags, too, which sounds pretty false to me. Any input? :)

I'm struggling to think of an action that this wouldn't be useful for.

In T99587#1395793, @phuedx wrote:

@Florian: How is this affected by the work in T67402 as well? It looks like the related patches give us canonical URL generation for free. One thing worth noting is that the inclusion of the canonical link is behind a feature flag in core, i.e. $wgEnableCanonicalServerLink, whereas in core it's something else.

Hmmpf, I haven't tested yet, but we should avoid to to add multiple canonical links to one page. One way would be to check for the relevant config vars from core, before trying to add the canonical link (which should be always the desktop url), which doesn't cover cases, where no canonical link is added. Another way would be to force disable the core canonical link on all mobile pages and always add our own one (with a nearly same implementation as core), which we should avoid, too (code duplication isn't rellay good). Another, in my point of view much easier, way would be to use core to create a canonical tag on mobile pages. For this we (like I said: untested) we just need to force $wgEnableCanonicalServerLink to be true and set a canocial link with OutputPage::setCanonicalUrl(). I would upload a change for it, after i tested it but would appreciate some feedback :)

For the alternate: It doesn't affect us, MediaWiki core shouldn't add an alternate link for a mobile optimized version (it's all handled by MobileFrontend).

Btw.: I see, that we would add the alternate and canonical links for all actions, not just for view, so the edit page would have these tags, too, which sounds pretty false to me. Any input? :)

I'm struggling to think of an action that this wouldn't be useful for.

Yeah, core adds the canonical links to all actions, too, so never mind :)

@Florian Hey! what's the status of this? Patch is merged.

@Jhernandez: There is still an open change (https://gerrit.wikimedia.org/r/#/c/212022/). For now, I would wait, until the blocked by task is resolved. Then test our own implementation again and decide, if there is something we need to do, or if we can test to enable it in one of the wmf wikis :)

Change 212022 abandoned by Florianschmidtwelzow:
Enable alternate and canonical links for mobile/desktop pages

Reason:
can be done later, too, it's just a small change, and there is some work that need to be done before this change.

https://gerrit.wikimedia.org/r/212022

Still not clear what is left to do here. @Florian could you clarify in the task description? :)

@Jdlrobson See the "blocked by" task :) T93550: Fix canonical URL issues (tracking)

Moved to discovery team since this seems more inline with their remit.

In T99587#1607061, @Jdlrobson wrote:

Moved to discovery team since this seems more inline with their remit.

I'm not sure that it is. Part of the reason is that I'm unclear what problem this task is aimed at solving; the title of the task mentions a specific solution to an unclear problem.

@Florian Can you provide information on the problem that this task is intended to solve? I can't assess this task's priority at present.

@Deskana: I thought I had this explained already, but it seems, I haven't :P Let me try it now:

The goal should be to implement https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/separate-urls for Wikimedia domains (mobile and desktop ones). The current situation is:

Desktop:

• The desktop site shows a canonical link to itself, even, if it's the same URL as the current one (see T93550: Fix canonical URL issues (tracking), so this isn't in the scope of this task)

The goal:

• The desktop site _should_ add an alternative link rel="alternate" media="only screen and (max-width: 640px)" with the mobile url as a target

Mobile current:

• The mobile site adds a canonical link to the desktop site (e.g. from https://en.m.wikipedia.org/wiki/Main_Page there is a canonical link to https://en.wikipedia.org/wiki/Main_Page)

The goal:

• Make sure, that this canonical link to the mobile page is always added, even if T93550 is fixed.

I hope I haven't missed anything :)