Mobile vs Desktop vs Location SERPs

Full transcript

964 words · script draft, under review.

Intro

You did a careful SERP analysis. Desktop results, national settings, the whole thing. Then a customer searches on their phone, in their own city, and sees something else entirely. A map on top. Different shops. Your analysis didn't cover what they saw.

Most SERP analysis is done for one device and one location, usually without anyone deciding that on purpose. Often that's fine. Sometimes it's the whole story.

In this episode, I'll show you which settings change the results page, when the differences actually matter, how to measure them, and a sampling plan so you don't pay for every combination.

The settings that change a SERP

When you request a results page through an API, you choose three things, whether you think about it or not.

Device. Desktop or mobile. With DataForSEO you set this with a device parameter, and you can also set the operating system.

Location. This can be a whole country, a region, a city, or, for local searches, a specific point given as coordinates. The narrower you go, the more local results can change.

Language. The interface language of the search. Keep this consistent with the market you're analysing, or you'll get results nobody in that market actually sees.

One more thing about your own browser. When you search yourself, the results are shaped by where you are, your history, and your settings. That's why I never use my own searches as data. An API request with explicit settings is repeatable. My browser isn't.

When the differences matter

So when should you care?

Location matters most when the search has local intent. Someone looking for a shop, a service, or anything they'd visit in person. You see it in the results page: a local pack, the map with three businesses, or results that change from city to city. For those searches, a national snapshot is almost meaningless. You need to look at the cities that matter to you.

For searches without local intent, like "how to clean a burr grinder", location usually changes little within one country. Not nothing, but little.

Device matters in a different way. The ranking pages are often similar, but the layout isn't. On mobile, features like the map, videos, or an AI overview can fill the whole first screen. So the same position six might be visible on desktop and invisible on mobile without scrolling. If most of your audience is on mobile, that changes what a position is worth.

Measuring the difference

To measure the difference, I use the same kind of overlap we used for clustering in episode twenty-four. Take two results pages for the same keyword, with one setting changed. Count how many of the top ten URLs they share.

Eight or more shared URLs: for planning purposes, they're the same results page. Five to seven: similar, but check the top three. Fewer than five: treat them as two different results pages, and analyse them separately.

I also compare features. Does the local pack appear in one setting and not the other? Where does the first organic result start? Those differences can matter more than the overlap.

A sampling plan

You could pull every keyword on every device in every city. That gets expensive fast and mostly tells you the same thing over and over. So I sample.

Step one: test device. Pick about twenty keywords from your set, spread across your topics. Pull each on desktop and mobile with the same location. At around three tenths of a cent per request, that's about twelve cents.

Step two: test location, but only for keywords that look local. Pick the ones with a local pack or obvious local intent, and pull them in three to five locations that matter to you.

Step three: decide your default. If device overlap is high, pick the device your audience mostly uses and stick with it. If certain keywords are clearly local, give them their own location settings in your tracking from now on.

With made-up numbers for our example shop: the device test shows an average overlap above eight out of ten. So we choose mobile as the default. Six of the twenty keywords show a local pack. For those, the overlap between cities is around three out of ten. So for those six, we track the shop's own city separately, and we don't trust the national snapshot at all.

Wiring it into tracking

Once you've decided, write it down per keyword, not just per project.

I give each keyword a small profile: which device, which locations, and why. Most keywords end up with one line: national, mobile. The local ones get a list of cities. That profile is what your weekly snapshots from the last episode use, so every snapshot is pulled with the same settings.

It also keeps costs predictable. A keyword with three locations costs three times as much to track. With profiles, you see that in the plan before it shows up on the invoice.

And re-run the device test once or twice a year. Layouts change, features come and go, and a default that was right last year might not be right now.

Common pitfalls

Three pitfalls.

One: an ambiguous location. Some place names exist in several countries. Use a location code, or check what the API says it used, which is in the response.

Two: changing settings mid-series. If you switch device or location halfway through your snapshots, the change in results is your doing. Store the settings with every row.

Three: forgetting the layout. Matching URLs don't mean equal visibility. Always look at where organic results start on each device.

Wrap-up

So: know your three settings, measure overlap before you assume, sample instead of pulling everything, and give local keywords their own location. The sampling plan template is linked in the description. Next episode: SERP gates, the go or no-go checks I run before building any page at all. See you there.