How we parse Google SERP features into stable JSON

A Google results page is a stack of different blocks. To use it in code, you turn each block into a JSON object with a type, a position and its own fields. This post explains how Serplify’s parser does that, and the rules that keep the output stable when Google changes its HTML.

It is written for developers who use SERP data or build their own parser. The field names match our response format docs.

What a results page looks like to a parser

A modern results page has a few classic links and many other blocks. Think of an AI Overview at the top, then ads, People Also Ask, a map with three businesses, videos and a knowledge panel. Google’s own visual elements gallery shows dozens of them.

Each block has a different shape:

• A featured snippet has a source page, a title and sometimes a table.
• People Also Ask is a list of questions. Each one opens to show an answer and its source.
• A local pack is a set of businesses with ratings, phone numbers and a Google Maps ID.
• An AI Overview is generated text with links to the pages it cites.

The classic links are the easy part. Most of the work is in the other blocks, and Google changes them without notice. For a plain guide to each block, read SERP features explained.

Rule 1: every block gets a type

We return the page as one list called items. Each item says what it is in a type field. Your code reads the type first, then the fields that type promises.

Here is an organic result as it comes back:

{
  "type": "organic",
  "rank_group": 1,
  "rank_absolute": 3,
  "page": 1,
  "domain": "nike.com",
  "title": "Nike Running Shoes",
  "description": "Shop the latest running shoes …",
  "url": "https://www.nike.com/running",
  "breadcrumb": "nike.com › running"
}

Not every type gets the same depth. Nine types have fully typed fields, which means each field is named, documented and checked. They are organic, paid, featured_snippet, ai_overview, people_also_ask, related_searches, refinement_chips, knowledge_graph and local_pack.

Forty more types are detected and returned in a simpler shared shape. That shape holds a title, a description, a URL, sub-items, images, and a rating or price when the block has one. Examples are video, top_stories, shopping, jobs and discussions_and_forums. That makes 49 types in all, and the feature types docs list every one.

The type names follow DataForSEO’s, so code written for DataForSEO’s advanced results can read ours.

A test checks this list against real pages. We sample the item types seen on real production results. If the sample holds a type our list lacks, the test fails.

Rule 2: keep two ranks, not one

Where a block sits on the page is not the same as its organic rank. Ads, an AI Overview and a map can push the first organic link far down the screen. So every item has two numbers:

• rank_absolute is its place among all blocks on the page. 1 is the top block.
• rank_group is its place among blocks of the same type, such as organic result 1, 2 or 3.

A third field, page, says which Google page the item came from.

Tools that keep only one number report false drops. Google adds an AI Overview above you, and your rank seems to fall by one, though no rival passed you. With both numbers you can tell those cases apart. Our guide to tracking rankings in bulk shows how to report both.

Rule 3: one broken block must not break the page

Sometimes Google ships a layout we have never seen, perhaps in one country or on one device. So the parser runs one small parser per feature. If the People Also Ask parser fails on a page, it logs a warning, and the rest of the page still parses.

There is one exception. If we cannot work out the real URL of an organic result, the whole parse fails. A ranking with the wrong URL is worse than no ranking, because it looks correct.

We also log a warning when a page yields no organic results at all. Real results pages almost always have some, so an empty list is a sign to look at the HTML.

Rule 4: version the parser and keep the HTML

The parser has its own version, a date stamp such as 2026.09.12-1. We bump it each time a change in Google’s HTML forces a fix. That September 12 build, for example, follows Google’s redirect links to the real ranking URL. It no longer guesses the URL from the domain shown on the page.

We also keep the raw HTML of recent pages next to the parsed JSON. That gives us two things:

• Re-parsing. When a parser improves, we can run it again over stored pages.
• Clear logs. Parse warnings are logged with the parser version, so we know which build read which page.

You can get the raw page yourself. Send "format": "html" and the API returns the HTML instead of parsed items.

How we test it: saved pages and golden files

The parser is tested against real Google pages saved as fixtures. Each fixture is three files: the page HTML, the search settings, and the JSON we expect. That last file is called a golden file.

Today the suite holds 21 saved pages from desktop and mobile. They include local packs from Dutch, Hebrew, Korean and Russian results, because Google labels those blocks in the local language.

When Google ships a new layout, the steps are always the same:

1. Save a real page with the new layout as a fixture.
2. Run the tests and watch the golden test fail.
3. Fix the parser for that block.
4. Review the new expected JSON by hand and save it.
5. Bump the parser version.

Every later change runs against all saved pages, so an old fix cannot quietly break.

What to ask of any SERP data source

These checks work for any parser or SERP API, ours included:

• Is every item typed? You want a type field you can switch on, not loose text.
• Are there two ranks? One number cannot tell a new block apart from a lost position.
• Is the parser versioned? Without a version, you cannot tell a fix from a bug.
• Does it fail loudly where it counts? A wrong URL should be an error, not a quiet guess.
• Can you get the raw HTML? Then you can check any result yourself.

If you would rather read this JSON than maintain a parser, the Serplify SERP API returns it for every Google search. Our first request, step by step shows the call and the response. If you are weighing a scraper of your own, read how to scrape Google search results first.