DEV Community

Elowen
Elowen

Posted on

Detect SERP Features in Search Results for Better SEO Context

#python #data #api

Organic ranking is useful, but it does not explain the whole search page.

A keyword can keep the same position while the SERP around it changes: a People Also Ask block appears, ads take more space, a local pack shows up, or video results start competing for attention.

If your monitoring script only stores organic positions, those changes disappear from the review.

This post shows a small pattern for detecting SERP features from structured search result data. A SERP API such as Talor Data SERP API can provide the search result data layer; your application can decide which features matter for your workflow.

What counts as a SERP feature?

The exact feature list depends on the search engine, query, location, and API response.

For a practical first version, you can track broad categories:

  • organic results
  • ads
  • People Also Ask
  • local pack
  • video results
  • image results
  • shopping results
  • top stories
  • related searches
  • AI or answer-style modules if your data source exposes them

Avoid overfitting the first version. The goal is to preserve context, not to model every possible page element on day one.

Normalize feature detection

Do not scatter feature checks throughout your reporting code.

Create one function that turns a raw or normalized SERP response into a stable internal shape:

{
  "keyword": "serp api for seo monitoring",
  "checked_at": "2026-07-07T09:00:00Z",
  "features": {
    "organic_results": true,
    "ads": false,
    "people_also_ask": true,
    "local_pack": false,
    "video_results": false
  }
}
Enter fullscreen mode Exit fullscreen mode

This makes later reporting easier. You can compare feature presence day by day without rereading the full response every time.

A minimal Python detector

This example is generic. Replace the field names with the actual schema from your SERP API provider.

from typing import Any


FEATURE_PATHS = {
    "organic_results": ["organic_results"],
    "ads": ["ads", "paid_results"],
    "people_also_ask": ["people_also_ask", "related_questions"],
    "local_pack": ["local_pack", "local_results"],
    "video_results": ["videos", "video_results"],
    "image_results": ["images", "image_results"],
    "shopping_results": ["shopping_results"],
    "top_stories": ["top_stories", "news_results"],
    "related_searches": ["related_searches"],
}


def has_any_field(raw: dict[str, Any], possible_fields: list[str]) -> bool:
    for field in possible_fields:
        value = raw.get(field)
        if isinstance(value, list) and len(value) > 0:
            return True
        if isinstance(value, dict) and len(value) > 0:
            return True
        if value is True:
            return True
    return False


def detect_serp_features(raw: dict[str, Any]) -> dict[str, bool]:
    return {
        feature_name: has_any_field(raw, fields)
        for feature_name, fields in FEATURE_PATHS.items()
    }
Enter fullscreen mode Exit fullscreen mode

This gives you a compact feature map that can be stored with each keyword snapshot.

Compare features over time

Once you store features per snapshot, you can compare two days:

def diff_features(before: dict[str, bool], after: dict[str, bool]) -> dict[str, list[str]]:
    added = []
    removed = []

    for feature, after_value in after.items():
        before_value = before.get(feature, False)

        if after_value and not before_value:
            added.append(feature)
        elif before_value and not after_value:
            removed.append(feature)

    return {
        "added": added,
        "removed": removed,
    }
Enter fullscreen mode Exit fullscreen mode

A report row can then say:

keyword: serp api for seo monitoring
added: people_also_ask
removed: none
Enter fullscreen mode Exit fullscreen mode

That is more useful than only saying the page stayed at position 4.

Store features next to ranking data

A practical snapshot can store both:

{
  "keyword": "serp api for seo monitoring",
  "checked_at": "2026-07-07T09:00:00Z",
  "top_organic_position": 4,
  "features": {
    "organic_results": true,
    "people_also_ask": true,
    "ads": false,
    "local_pack": false
  }
}
Enter fullscreen mode Exit fullscreen mode

This lets you ask better questions later:

  • Did clicks drop because position changed, or because the SERP added more competing elements?
  • Did a keyword become more local, visual, or question-driven?
  • Are some content formats appearing more often than before?
  • Should a change be an alert, a weekly report item, or just a log entry?

Where the SERP API fits

The SERP API gives you structured search result data. The feature detector turns that data into a stable monitoring signal.

For teams building this kind of workflow, Talor Data can be used as the data collection layer, while your code owns feature naming, storage, and reporting rules.

Final note

If you monitor SERPs, which features do you track first: ads, People Also Ask, local results, videos, shopping, or something else?

Top comments (0)