How and Why to Do a Mobile/Desktop Parity Audit

Posted by Everett

Google still ranks webpages based on the content, code, and links they find with a desktop crawler. They’re working to update this old-school approach in favor of what their mobile crawlers find instead. Although the rollout will probably happen in phases over time, I’m calling the day this change goes live worldwide “D-day” in the post below. Mobilegeddon was already taken.

You don’t want to be in a situation on D-day where your mobile site has broken meta tags, unoptimized titles and headers, missing content, or is serving the wrong HTTP status code. This post will help you prepare so you can sleep well between now then.

What is a mobile parity audit?

When two or more versions of a website are available on the same URL, a "parity audit" will crawl each version, compare the differences, and look for errors.

When do you need one?

You should do a parity audit if content is added, removed, hidden, or changed between devices without sending the user to a new URL.

This type of analysis is also useful for mobile sites on a separate URL, but that's another post.

What will it tell you? How will it help?

Is the mobile version of the website "optimized" and crawlable? Are all of the header response codes and tags set up properly, and in the same way, on both versions? Is important textual content missing from, or hidden, on the mobile version?

Why parity audits could save your butt

The last thing you want to do is scramble to diagnose a major traffic drop on D-day when things go mobile-first. Even if you don’t change anything now, cataloging the differences between site versions will help diagnose issues if/when the time comes.

It may also help you improve rankings right now.

I know an excellent team of SEOs for a major brand who, for severals months, had missed the fact that the entire mobile site (millions of pages) had title tags that all read the same: "BrandName - Mobile Site." They found this error and contacted us to take a more complete look at the differences between the two sites. Here are some other things we found:

1. One page type on the mobile site had an error at the template level that was causing rel=canonical tags to break, but only on mobile, and in a way that gave Google conflicting instructions, depending on whether they rendered the page as mobile or desktop. The same thing could have happened with any tag on the page, including robots meta directives. It could also happen with HTTP header responses.
2. The mobile site has fewer than half the amount of navigation links in the footer. How will this affect the flow of PageRank to key pages in a mobile-first world?
3. The mobile site has far more related products on product detail pages. Again, how will this affect the flow of PageRank, or even crawl depth, when Google goes mobile-first?
4. Important content was hidden on the mobile version. Google says this is OK as long as the user can drop down or tab over to read the content. But in this case, there was no way to do that. The content was in the code but hidden to mobile viewers, and there was no way of making it visible.

How to get started with a mobile/desktop parity audit

It sounds complicated, but really it boils down to a few simple steps:

1. Crawl the site as a desktop user.
2. Crawl the site as a mobile user.
3. Combine the outputs (e.g. Mobile Title1, Desktop Title1, Mobile Canonical1, Desktop Canonical1)
4. Look for errors and differences.

Screaming Frog provides the option to crawl the site as the Googlebot Mobile user-agent with a smartphone device. You may or may not need to render JavaScript.

You can run two crawls (mobile and desktop) with DeepCrawl as well. However, reports like "Mobile Word Count Mismatch" do not currently work on dynamic sites, even after two crawls.

The hack to get at the data you want is the same as with Screaming Frog: namely, running two crawls, exporting two reports, and using Vlookups in Excel to compare the columns side-by-side with URL being the unique identifier.

Here's a simplified example using an export from DeepCrawl:

As you can see in the screenshot above, blog category pages, like /category/cro/, are bigly different between devices types, not just in how they appear, but also in what code and content gets delivered and rendered as source code. The bigliest difference is that post teasers disappear on mobile, which accounts for the word count disparity.

Word count is only one data point. You would want to look at many different things, discussed below, when performing a mobile/desktop parity audit.

For now, there does NOT appear to be an SEO tool on the market that crawls a dynamic site as both a desktop and mobile crawler, and then generates helpful reports about the differences between them.

But there's hope!

Our industry toolmakers are hot on the trail, and at this point I'd expect features to release in time for D-day.

Deep Crawl

We are working on Changed Metrics reports, which will automatically show you pages where the titles and descriptions have changed between crawls. This would serve to identify differences on dynamic sites when the user agent is changed. But for now, this can be done manually by downloading and merging the data from the two crawls and calculating the differences.

Moz Pro

Dr. Pete says they've talked about comparing desktop and mobile rankings to look for warning signs so Moz could alert customers of any potential issues. This would be a very helpful feature to augment the other analysis of on-page differences.

Sitebulb

When you select "mobile-friendly," Sitebulb is already crawling the whole site first, then choosing a sample of (up to) 100 pages, and then recrawling these with the JavaScript rendering crawler. This is what produces their "mobile-friendly" report.

They're thinking about doing the same to run these parity audit reports (mobile/desktop difference checker), which would be a big step forward for us SEOs. Because most of these disparity issues happen at the template/page type level, taking URLs from different crawl depths and sections of the site should allow this tool to alert SEOs of potential mismatches between content and page elements on those two versions of the single URL.

Screaming Frog

Aside from the oversensitive hash values, SF has no major advantage over DeepCrawl at the moment. In fact, DeepCrawl has some mobile difference finding features that, if they were to work on dynamic sites, would be leaps and bounds ahead of SF.

That said, the process shared below uses Screaming Frog because it's what I'm most familiar with.

Customizing the diff finders

One of my SEO heroes, David Sottimano, whipped out a customization of John Resig's Javascript Diff Algorithm to help automate some of the hard work involved in these desktop/mobile parity audits.

http://ift.tt/2xCAzgb