How We Parse 26 SERP Feature Types Into Stable JSON

Ten blue links died years ago. A modern Google results page is a dense stack of feature blocks — a featured snippet up top, an AI Overview above that, People Also Ask in the middle, a local pack, shopping units, image carousels, and a knowledge panel down the side. If your SERP API only returns organic links, it is throwing away most of what the page actually shows a searcher. This is a field note on how we parse 26 SERP feature types into stable, versioned JSON — and the schema decisions that keep that JSON from breaking your pipeline every time Google reshuffles the page.

Why SERP features are the hard part

Parsing organic results is comparatively easy: find the result container, pull the title, URL, and snippet, assign a rank. The difficulty is everything else. Google’s own documentation on how Search works catalogs a growing gallery of visual elements, and each one is a different shape with different fields:

• A featured snippet has a source URL, a snippet type (paragraph, list, table), and extracted content.
• People Also Ask is a list of expandable questions, each with its own answer and source.
• A local pack is a set of businesses with ratings, review counts, addresses, and map coordinates.
• An AI Overview is generated prose with cited sources — a structure that barely existed two years ago.

Each feature needs its own parser, its own typed shape, and its own tests. And Google changes all of them without notice.

Decision 1: one typed shape per feature, not a bag of strings

The tempting shortcut is to dump everything into loosely-typed objects and let consumers sort it out. We don’t, because that pushes the parsing burden onto every downstream user and makes breakage invisible.

Instead, every feature type gets an explicit, typed schema. An organic result is not the same type as a featured snippet, which is not the same type as an AI Overview. Each item declares what it is and carries only the fields that make sense for it. Consumers can switch on the item type and trust the fields.

{
  "type": "featured_snippet",
  "rank_group": 1,
  "rank_absolute": 1,
  "title": "How to parse a SERP",
  "url": "https://example.com/guide",
  "snippet_type": "paragraph",
  "text": "A SERP feature is any result block beyond a plain organic link..."
}

The type field is load-bearing. It is the discriminator that lets a strongly-typed client narrow the shape safely, and it is what makes a mixed list of 26 feature types tractable instead of a guessing game.

Decision 2: separate ranking from position

A subtle but important distinction: where a result sits on the page is not the same as its organic rank. An AI Overview and three ads can push the first organic result far down the visual page while it is still organic position 1. We track both:

• rank_absolute — the item’s position among all elements on the page.
• rank_group — its rank within its own feature type (organic result 1, 2, 3…).

Rank trackers that conflate these report phantom drops every time Google adds a feature above the fold. Keeping them separate is the difference between “your ranking fell” and “Google added an AI Overview above you” — two very different stories for an SEO team, and only one of them is real. We dig into that distinction more in our rank tracking notes.

Decision 3: version the parser output

This is the decision that saves us the most pain. Every parsed result carries a parser version. When Google changes a layout and we update a feature parser, the version bumps.

Why it matters:

• Re-parsing is safe. We store the raw HTML artifact for each crawl. If we improve a parser, we can re-run it over historical HTML and know exactly which version produced which output.
• Consumers get a warning signal. A version change is a visible event, not a silent shape shift.
• Backfills are possible. When we add support for a new feature type, we can backfill it across stored pages rather than losing the historical data forever.

Versioning turns “Google changed the SERP and quietly corrupted three weeks of our data” into a tracked, recoverable event. If you take one idea from this post, take that one.

Decision 4: fail loudly, degrade gracefully

Parsers encounter HTML they have never seen — a new local-pack variant, an experimental layout in one country. The wrong response is to crash the whole crawl or, worse, silently emit malformed data. Our rule:

1. Parse what you recognize into typed items.
2. When a block is unrecognized, record that it existed rather than pretending it didn’t.
3. Never let one weird feature take down the whole result.

A page with 25 clean features and one unknown block is far more useful than a hard failure. Partial, honest data beats a clean-looking lie.

How we keep it accurate: capture, replay, golden tests

The engine behind all of this is a test harness, not heroics. The workflow:

• Capture real SERP HTML into fixtures — a library of actual pages across query types and locations.
• Replay the parser over those fixtures deterministically, with no network.
• Golden tests assert the parsed JSON matches a reviewed, checked-in expected output.

When Google ships a new layout, the pattern is always the same: add a fixture from the wild, watch the golden test fail, fix the parser, review the new golden output, bump the version. Those fixtures accumulate into a regression suite that catches breakage in CI before it ever reaches a customer’s pipeline. It is unglamorous and it is the whole reason the output stays stable.

What this means if you consume SERP data

Whether you build your own parser or buy a SERP API, the same principles protect you:

• Demand typed, discriminated shapes, not untyped blobs — so a layout change surfaces as a schema event, not silent corruption.
• Insist on separate absolute and organic ranking, or your rank tracking will lie to you the moment a feature appears above the fold.
• Ask whether output is versioned. If it isn’t, you have no way to tell a parser improvement from a data regression.
• Test against your own queries. SERP layouts vary by intent, language, and location; a provider that parses commercial US queries perfectly may stumble on informational queries elsewhere.

These are exactly the axes we’d compare providers on — and they’re the ones we hold ourselves to. If you want the practical version of this, our guides to SerpApi alternatives and DataForSEO alternatives walk through how to run a golden-set diff between providers before you commit.

The bottom line

Parsing a modern SERP is 90% dealing with features and change, and 10% pulling organic links. Typed per-feature schemas, separate absolute-versus-organic ranking, versioned output, graceful degradation, and a capture-replay-golden test loop are what turn a chaotic, shifting HTML page into JSON your pipeline can actually depend on.

If you’d rather consume that stable JSON than maintain the parser yourself, that is precisely what the Serplify SERP API does — 26+ feature types, versioned output, on a free starting balance so you can diff it against your own queries.