Site Mobile-First indexed, but certain pages have "Errors"

[geekay]

Site is in Mobile First Index, but according to GSC certain pages have "Errors" as having "content wider than screen". Those few pages are important but actually impossible to make mobile friendly. So I have experimented with alternate pages stripped of some important information in order to force them to become narrow enough. Those stripped pages are tagged rel=alternate and the original ones rel=canonical.

– Maybe the original broad pages are not offered in mobile searches, but will they also be excluded from desktop searches? So far they are not, but I have understood Google maintains only one kind of index for each site.

– Because the broad pages are not mobile friendly Google may eventually stop crawling them, I presume. What will then happen to all the mobile friendly pages and images linked to solely from broad pages? Will those linked pages become orphaned, and will new mobile friendly pages linked to only from broad pages thus not be discovered and crawled by Google?

If Google can be expected to continue crawling the broad pages and include them in desktop SERPs there is no real damage - those pages are not mobile friendly. In the contrary case I have to come up with some makeshift solution, like a mobile friendly page containing all the corresponding oversized page's outbound links. Or what to do?

[Wilburforce]

What prevents the pages from being narrow enough?

[geekay]

Huge multicolumn tables containing numeral data.

[Wilburforce]

Difficult. I have a couple of tables that are too wide for narrow screens, and get round it by hiding columns, but that obviously won't work if all columns contain important data.

One way to go mught be to hide the table altogether for smaller screens, and instead display a parargraph - including a link to the full table (possibly as an image or PDF) - summarising the table contents.

That way you at least get to keep the page in the mobile index. I'm not sure how Google treats table contents, but my guess would be that a description might work as well or better for indexing too.

[Wilburforce]

...in any event (sorry, I was only looking at the technical question), the pages won't be deindexed or excluded from results if they remain too wide, but may well lose position in mobile searches. The "Mobile-First" index just means that where there are two versions of a page, the mobile version will be indexed rather than the desktop version. Where - as in this case - there is only one version of the page (the content, that is, not how it displays), that will be indexed.

[lucy24]

@media screen and (max-width: 640px) {
  table.bigcomplicatedmess tr {display: block; margin-top: 1em;}
  table.bigcomplicatedmess td:first-child {display: block; margin-left: 1em;}
  table.bigcomplicatedmess td:second-child {display: block; margin-left: 2em;}
 }

et cetera. Of course it isn't really "second-child"; I use the nth-child construction so rarely that I don't have the syntax internalized. In the rare case where I've actually had to do this, I linked the successive indent to the respective columns' language attribute, but this probably won't help your site any.

At least, that's what you'd do if you have tabular information that you really do need humans to be able to read on small devices.

[NickMNS]

I've been faced with this issue as well. The solution I used was to place the content inside a carousel. The exact implementation will depend on the data and how you can split it up. In one implementation I have placed a fixed the left most column in place while the remaining columns are place in the carousel with a few columns exposed in the viewport, then the user can swipe to view the remaining columns. With left most column fixed, the user continues to see it, thus making the table even easier to read than simple table. With this pattern the table can have as many columns as needed. In my implementation, columns are added by the user, so the number of columns doesn't need to be fixed.

This is not easy to achieve as the data is now split into multiple tables or lists (depending on your implementation) and all the rows needs to line-up, across all screen sizes and orientations and for a variety of data populating the tables. It requires some work but the end result is well worth the effort.

The width of the viewport can be adjusted based on screen size, in a mobile view one may expose three columns but on desktop one could expose twelve. In every case the table is easier to read.

If table also extends vertically beyond the screen size of a typical phone, I would recommend splitting it up in to shorter sections. I guess one could make the table scroll both vertically and horizontally, that would probably look pretty cool but would be a challenge to implement.

This is an example of what I call content that is optimized for mobile, as opposed to other options such as hiding columns, which may make the content "mobile friendly" but not "mobile optimized"

[RedBar]

Huge multicolumn tables containing numeral data.

I assume this data is fixed and not constantly changing?

Whenever I need to do this I use two routes and have never had a complaint:

1. A quality image file that auto-resizes for screen widths enabling the visitor to zoom in and out when they need to do so.

2. Use a .pdf for the same purpose however, personally, I find .pdfs a pita on mobile.

As an observation surely anyone wanting to seriously view "stuff" like this uses a bigger screen?

[Pjman]

When I go in to Console and actually look at the affected pages, then put them into Google's "Test Page" tool they all come back as "Mobile Friendly".

Looks like they are rolling back their tool?

[geekay]

As an observation surely anyone wanting to seriously view "stuff" like this uses a bigger screen?

Yes, but my problem is that about ten huge tables act as "master pages" for more than a thousand neat and small separate pages with supplemental information to the data in the tables.

In the tables there are links to the all the small pages and to images. They are useful and quite popular as such in SERPs, independently of the tables. The tables obviously do not rank high, but are indexed, so far.

Those small pages do get a lot of external backlinks as well, but many have only site internal links. So, if the table pages would get deindexed by Google, because they have "Errors" in the Mobile First Index, a large number of those small pages would become orphans in Google's eyes.

I was concerned that (i) such orphan pages sooner or later would fall out Google, or at least not get recrawled regularly, and that (ii) links in the tables to new small pages would no longer be picked up by Googlebot. And... data in the tables is not fixed at all, but do change constantly, daily. Also, new small pages need to be created avery few days.

Thank you, Wilburforce, for explaining that wide pages would not be deindexed or excempt from crawling just for being too wide. Thus the orphan problem does not seem real. No need for me to experiment with alternate pages for mobiles. I have also gotten valuable information on how the original width problem can be solved.

[HereWeGo123]

Hey everyone, we’re experiencing the same issue here- the new GSC is giving us mobile coverages errors on hundreds of affected pages, for the errors “Clickable elements too close together“ and “Content wider than screen”. Yet when we run the “affected” urls for the live version for the mobile friendly tool, it’s not giving us any errors at all. We attempted to validate the fix and some urls still came back with errors, and the same cycle over and over.

Any thoughts?

[lucy24]

Any thoughts?

Yes, but mostly along the lines of “Life’s too short to stress over every GSC message”.

[Pjman]

@lucy24 Amen!