DEV Community

Elowen
Elowen

Posted on

Use Dify to Summarize Google Results from a SERP API

A Dify workflow can turn a keyword into an answer, but the answer is only as fresh as the data you give it.

If the user asks for current Google results, People Also Ask questions, or a quick summary of what is visible on a SERP, the workflow needs an external search step before the LLM step.

This tutorial shows a simple Dify workflow pattern: user input goes into an HTTP Request node, the node calls TalorData SERP API, and the LLM summarizes the returned organic and people_also_ask fields.

What we are building

The workflow has four parts:

  1. Start node: accepts a keyword or question from the user.
  2. HTTP Request node: calls TalorData SERP API.
  3. LLM node: summarizes the returned search results.
  4. Answer node: returns a concise response with search context.

The goal is not to build a full SEO platform inside Dify. The goal is to give the workflow a fresh search input that can be inspected and summarized.

Step 1: Define the user input

Create a Dify Workflow or Chatflow and add an input variable such as:

query
Enter fullscreen mode Exit fullscreen mode

Example user input:

google search api
Enter fullscreen mode Exit fullscreen mode

Keep the first version simple. One query is easier to debug than a list of queries.

Step 2: Add an HTTP Request node

Add an HTTP Request node after the start node.

Use this endpoint:

https://serpapi.talordata.net/serp/v1/request
Enter fullscreen mode Exit fullscreen mode

Set the method to:

POST
Enter fullscreen mode Exit fullscreen mode

Set the headers:

Authorization: Bearer <TALORDATA_TOKEN>
Content-Type: application/x-www-form-urlencoded
Enter fullscreen mode Exit fullscreen mode

Store your token in Dify's secret or environment configuration if your workspace supports it. Do not paste real credentials into prompts, public templates, or screenshots.

Step 3: Send form parameters

The request body should use form URL encoded parameters.

Start with:

engine=google
q={{query}}
json=2
Enter fullscreen mode Exit fullscreen mode

You can add market parameters when needed:

gl=us
hl=en
device=desktop
Enter fullscreen mode Exit fullscreen mode

If your workflow needs AI Overview analysis, keep that as a separate version or optional branch:

ai_overview=true
Enter fullscreen mode Exit fullscreen mode

For a first search-summary workflow, ordinary organic results and People Also Ask questions are usually easier to review.

Step 4: Inspect the response fields

The confirmed fields you can safely design around include:

organic
people_also_ask
search_information
search_metadata
request_params
Enter fullscreen mode Exit fullscreen mode

For the LLM summary, you usually do not need the full response. Pass only the fields that help the model answer:

{
  "organic": "top result titles, links, descriptions, and positions",
  "people_also_ask": "related questions when present",
  "search_metadata": "request status and timing context"
}
Enter fullscreen mode Exit fullscreen mode

The smaller the prompt input, the easier it is to debug the output.

Step 5: Create the LLM prompt

In the LLM node, pass the HTTP node output into a prompt like this:

You are summarizing live Google search results for a user.

User query:
{{query}}

Organic results:
{{organic}}

People Also Ask:
{{people_also_ask}}

Write a short summary that includes:
- the main topics visible in the results
- recurring page types or source patterns
- 3 useful questions from People Also Ask, if available
- a note that this is based on the returned search snapshot

Do not claim that the SERP proves facts beyond the returned results.
Enter fullscreen mode Exit fullscreen mode

This prompt keeps the model focused on summarizing search evidence instead of inventing background context.

Step 6: Return a practical answer

A good output format is:

Search snapshot summary

Main result themes:
...

Common page types:
...

People Also Ask questions:
...

Notes for follow-up:
...
Enter fullscreen mode Exit fullscreen mode

This format works well for content briefs, keyword research, search intent review, and quick market checks.

Step 7: Add failure handling

Do not let the workflow return a confident answer if the HTTP Request node fails.

Add a branch or check for request status when possible:

  • if the request succeeds, continue to the LLM summary
  • if the request fails, return a short message that live search data was unavailable
  • if the result is empty, ask the user to try a clearer query or different market settings

The workflow should be honest about whether it used fresh search data.

What to log during testing

When testing the workflow, record:

  • query
  • request parameters
  • response status
  • result count
  • whether people_also_ask was present
  • LLM output quality
  • cases where the summary overclaimed

These logs are often more useful than the first working prototype.

Final thought

Dify makes it easier to connect nodes, but the workflow still needs a reliable data boundary.

A SERP API step gives the LLM current search evidence before it writes the summary. The important part is keeping the request inspectable, the prompt focused, and the answer honest about what came from the returned SERP snapshot.

If you want to test this pattern with live Google results, the TalorData SERP API page is a practical starting point; new accounts include 500 responses for experimenting with workflows.

Top comments (0)