Page MenuHomePhabricator

Add navbox links to mobile page HTML
Closed, InvalidPublic

Description

Outcome from 2018 SEO project with Go Fish Digital:

The navboxes at the bottom of articles are good for search engine rankings, as they improve the link equity of the other pages. This is true even if the links are collapsed by default (which they are on desktop), and also true even if the links themselves are in the HTML but not visible to the user.

Navboxes were removed from the mobile view because the nature of the tables meant they weren't very useful to users, and removing them also reduced page weight. Search engines like Google are increasingly switching to mobile-first crawling, and not having these links present is bad for link equity.

There's a tradeoff here: page weight and good performance are taken in to account by crawlers, but so is the presence of these links. If adding the links back in (but not necessarily displayed to the user) doesn't have a large performance impact, then they should probably be put back.

Event Timeline

Deskana moved this task from Tag to 2018 SEO project outcomes on the SEO board.

This task is about including navbox links in the HTML without necessarily showing them to users, as opposed to T124168 which is about showing them, so this isn't strictly a duplicate.

If T124168 were resolved then this one would be too, but the inverse is not necessarily true.

I'm pretty sure I was advised a while back that hidden links are penalised in SEO. That's why I figured adding these links in the HTML would also require displaying them. It would be worth getting some advice on whether that's the case.

Even so, as you say, there are technical reasons not to show navbox, to be more specific they can bump page HTML size up by 17%. Related: https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Removal_of_secondary_content_in_production

I'm pretty sure I was advised a while back that hidden links are penalised in SEO. That's why I figured adding these links in the HTML would also require displaying them. It would be worth getting some advice on whether that's the case.

Go Fish said that hidden links are penalised if they're invisible, but they're still more beneficial than if there's no links there at all. So, adding them back but keeping them invisible would be beneficial.

Even so, as you say, there are technical reasons not to show navbox, to be more specific they can bump page HTML size up by 17%. Related: https://www.mediawiki.org/wiki/Reading/Web/Projects/Performance/Removal_of_secondary_content_in_production

Yep. This task has so many competing interests: UX, SEO, performance, etc. I'm not sure where to draw the line.

AFAIK google isn't indexing the mobile version of the page, they are indexing Parsoid content. So this should have no effect on SEO for google either way.

AFAIK google isn't indexing the mobile version of the page, they are indexing Parsoid content. So this should have no effect on SEO for google either way.

Per T198963#4596451, this is invalid.

I keep seeing that repeated. Is there any actual documentation on MediaWiki wiki (or WMF wiki or....) that Google uses the Parsoid content? Who would be the contact (for WMF) to verify that? I would expect some sort of memo or similar in a public place if it is driving design decisions.

And that's just Google anyway. There are other search engines which may not use Parsoid content.

Jdlrobson moved this task from Team: web to Tracking on the MobileFrontend board.
Jdlrobson edited projects, added MobileFrontend (Tracking); removed MobileFrontend.
Krinkle changed the task status from Duplicate to Invalid.Dec 17 2021, 12:34 AM

Changing to invalid per prior conversation, and in context of its parent task. The duplicate remains open and has other (valid) reasons behind it.