How to Build an AI Keyword Clustering Agent in Make.com, Step by Step

The exact Make.com modules, prompt, and JSON schema that turn a raw keyword export into topic clusters ready for a content plan, plus the batch-size limit that breaks it if you ignore it.

Most "cluster your keywords with AI" advice stops at "paste them into ChatGPT." That works for 20 keywords. It falls apart at 300, because you're re-pasting, re-prompting, and manually copying results into a spreadsheet every time you add a new keyword batch. Here's the actual Make.com scenario: the exact modules, the exact prompt and JSON schema, and where the pattern breaks if you skip the batch-size limit.

What this scenario actually does

A Make scenario reads a batch of raw keywords from a Google Sheet, bundles them into a single array, sends that whole array to an LLM in one call with a strict JSON schema, parses the result, and writes one row per cluster back to a second sheet, one row per topic cluster rather than one row per keyword. It does not pull search volume or difficulty data (Make has no native keyword-research module), and it does not publish anything. The output is a clustered content plan ready for a human to prioritize, not a finished content calendar.

Inputs you need before you build this

• A Make account. The free tier (1,000 operations/month) covers this comfortably: clustering a 300-keyword batch runs a handful of modules per execution, not per keyword, since the whole list goes into a single AI call. Core starts at $10.59/month if you outgrow the free tier's monthly operation cap.
• An API key for the model you'll call, OR use Make's built-in AI Toolkit, which runs on Make's own AI provider with no external API key required on any plan, a genuinely faster way to prototype this before wiring in your own OpenAI or Anthropic key.
• A raw keyword export, from Ahrefs, Google Search Console, or anywhere else, pasted into a Google Sheet with at minimum a single keyword column.
• A second, empty Google Sheet tab to receive the clustered output: columns for cluster_name, primary_keyword, search_intent, content_type, and keywords.

Map the logic: the five modules, in order

1. Google Sheets (Search Rows): pulls every keyword row from your raw export tab. Run this on a defined batch, 200 to 300 keywords at a time, not your entire keyword universe in one shot; see "Where this breaks" below for why.
2. Array Aggregator: Make's built-in Tools module that bundles every row from the previous step into a single array in one bundle, instead of passing keywords through the scenario one at a time. This is the step that makes clustering possible at all: an LLM can't group keywords it only ever sees one at a time.
3. OpenAI (Create a Completion) or Anthropic Claude (Create a Message): the actual clustering call. One request, the full keyword array as input, the exact prompt below. Make's AI Toolkit module works as a drop-in substitute here if you're not ready to connect your own provider key yet.
4. JSON (Parse JSON): parses the model's JSON string response into a structured object Make can actually work with, and is where a malformed response (missing bracket, trailing comma) will visibly fail the run instead of silently corrupting your sheet.
5. Iterator + Google Sheets (Add a Row): the Iterator splits the parsed clusters array into one bundle per cluster, and the Add a Row module writes each one to your output tab.

Five modules. No Router, no conditional branching, because there's only one path through this scenario.

The exact prompt

This is the message content for the AI module. The schema constraints do the real work; a loose "group these into topics" prompt produces clusters that don't map to anything you can act on.

You are an SEO content strategist. Below is a JSON array of raw keywords pulled from a keyword research export.

Keywords: {{ keywordArray }}

Group these into topic clusters, where every keyword in a cluster could realistically be covered by a single page. Return ONLY valid JSON matching this exact schema, no commentary outside the JSON:

{
  "clusters": [
    {
      "cluster_name": "string, a short human-readable topic name",
      "primary_keyword": "string, the single keyword from this cluster with the clearest, most searchable phrasing",
      "search_intent": "informational" | "commercial" | "transactional" | "navigational",
      "content_type": "string, e.g. 'blog post', 'comparison page', 'landing page', 'product page'",
      "keywords": ["every input keyword that belongs in this cluster"]
    }
  ],
  "unclustered": ["any input keyword that doesn't fit cleanly into a cluster with at least one other keyword"]
}

Rules:
- Every keyword from the input array must appear exactly once, either inside one cluster's "keywords" array or in "unclustered". None dropped, none duplicated across clusters.
- Group by shared search intent and topic overlap, not shared words. "best crm for startups" and "crm software for small business" belong together even with zero word overlap. "apple pie recipe" and "apple stock price" do not belong together despite sharing "apple".
- Do not invent or estimate search volume, difficulty, or competition. That data isn't in the input; state nothing about it.
- Cap any single cluster at roughly 15 keywords. A cluster that would need more than that is really two topics wearing one name; split it.

The "every keyword exactly once" rule is what turns this from a fuzzy suggestion into something you can audit. Without it, a model will happily drop awkward keywords that don't fit anywhere rather than telling you so, and you won't notice until you're missing a keyword you specifically added.

Where this breaks

• Batch size ceiling. Feed this a keyword list in the thousands and the model starts losing track of keywords partway through, producing clusters that quietly merge unrelated terms or drop entries despite the "exactly once" rule. Run this in batches of 200 to 300 keywords, not your full backlog at once. Bigger lists mean more scenario runs, not one giant prompt.
• Cluster boundaries drift between runs. Ambiguous keywords near a topic boundary can land in a different cluster if you re-run the same batch later, because clustering by semantic judgment isn't deterministic the way a rules-based grouping would be. Treat cluster names and boundaries as a first-pass hypothesis, not a fixed taxonomy you build URLs around immediately.
• No real intent verification. The search_intent and content_type fields are the model's best guess from the keyword phrasing alone, not a check against what's actually ranking. Before greenlighting a content brief off this output, spot-check the top few clusters' actual search results, especially anything labeled "transactional," since that's the label most likely to be wrong on ambiguous B2B keywords.

The verdict

Make is the right tool for this specifically because Array Aggregator and Iterator are exactly the "many in, structured many out" pattern this task needs, without writing a custom parsing script the way n8n's Code node would require. Zapier can call the same AI APIs, but its per-Zap model and more limited native looping make the aggregate-then-iterate shape clunkier to build without reaching for a paid Premium app. If you're already exporting keyword lists from Ahrefs or Search Console by hand and pasting them into ChatGPT one batch at a time, this scenario replaces that manual step with a five-minute setup, run it whenever you add a new export, and it costs a small fraction of even Make's free monthly operation allowance per batch.