Tracking whether Google AI results reference your content is not the same as tracking a conventional organic ranking. AI search features can expose a page, domain, brand, or source URL in ways that are difficult to summarize with a single position number. A useful workflow therefore needs to capture the result context, not just a yes or no visibility flag.
Make.com can orchestrate that process. It can receive a keyword set, submit requests to a SERP data provider such as DataForSEO, normalize the returned response, store a time-stamped observation, and alert the right person when a meaningful change occurs. The important work happens before the modules are connected: define what counts as a reference, which searches matter, and what decision the resulting report should support.
The recommended approach is to treat AI Mode monitoring as an evidence-collection workflow. Collect the search context, preserve the raw response, create a normalized record for reporting, and distinguish directly observed references from assumptions based on rankings or snippets.
What Google AI Mode tracking should measure
Traditional rank tracking usually asks, “What position does this URL occupy for this keyword?” AI search monitoring asks a broader set of questions:
- Did an AI-generated result appear for the query?
- Was a page, domain, brand, or source URL referenced?
- What type of AI result contained the reference?
- Which location, language, device, and search context produced it?
- Did the observation change compared with an earlier check?
These are different business states. A page can rank organically without being cited in an AI result, while a domain may be referenced in an AI response without occupying a conventional top position. Your data model should preserve that distinction instead of combining every form of visibility into one score.
An AI search observation is evidence from a specific query context, not a permanent property of a page.
Google’s result formats and third-party API fields can change. Make the workflow tolerant of missing fields and verify the current DataForSEO documentation before relying on a particular parameter or response path. The automation should fail safely when an expected AI element is absent rather than silently reporting “not referenced.”
Define the measurement before building the scenario
Start with an operational definition of a reference. For example, your team may count a reference only when the returned AI result contains a source URL on the tracked domain. A brand mention in generated text may be useful, but it should be stored separately because it does not prove that a specific page was cited.
A practical record can include:
- Query text and query group.
- Check timestamp and workflow run ID.
- Country, language, device, and search location.
- Tracked domain and target URL, where applicable.
- Whether an AI result was present.
- Whether a tracked domain or URL was referenced.
- Reference URL, result type, and available source position.
- Raw response location or retained response payload.
- Parser status and error message, if applicable.
Use explicit states such as referenced, not referenced, AI result not detected, and check failed. These states prevent a failed API request from being interpreted as a loss of visibility.
Reporting is only as trustworthy as the distinction between “the result was checked and no reference was found” and “the workflow did not collect usable data.”
Use a simple operating sequence in Make.com
A maintainable Make.com scenario can follow this sequence:
This sequence keeps collection, interpretation, and action separate. That separation makes it easier to change a parser or reporting destination without redesigning the entire workflow.
Configure the trigger and input data
Use a scheduled trigger when the workflow monitors a stable keyword set. A webhook is more suitable when another system needs to request a one-off check, such as a content review process or an internal reporting job. In both cases, pass a clear input object rather than relying on values hidden inside individual modules.
Useful input fields include the query, query group, target domain, target URL, country, language, device, and requested run type. If the workflow processes many queries, read them from a maintained table or data store. Include an active flag and a monitoring priority so high-value query groups can run on a different cadence from exploratory terms.
Do not use the trigger as the place where business logic is decided. The trigger starts a run. The source record and later filters determine what should be checked and what should happen with the result.
Send requests through the Make.com HTTP module
Add an HTTP request module after the trigger and query source. Configure authentication using the method required by your DataForSEO account, and build the request body from mapped fields. Keep the request parameters visible in the scenario so another operator can understand the location and search settings without inspecting hidden code.
Before scaling the scenario, test a small set of queries and inspect the complete response. Confirm which fields represent AI-related elements in the current provider response. Do not assume that a field named “AI,” “overview,” or “citation” has the same meaning across endpoints or API versions.
Use defensive handling for:
- Authentication failures and quota errors.
- Empty or delayed task responses.
- Unexpected response shapes.
- Missing AI-related fields.
- Duplicate results from retries.
- Temporary provider or network errors.
Where the provider uses asynchronous tasks, separate task creation from result retrieval. Store the task identifier, wait according to the provider’s process, and then retrieve the result. A scenario that assumes every request returns a complete result immediately can produce incomplete records or unnecessary retries.
Parse AI references without overstating the evidence
Use an iterator when the response contains multiple result elements. Then normalize each relevant item into a consistent internal structure. A parser should answer specific questions, such as whether the element is an AI result, whether a source URL exists, and whether that URL belongs to the tracked domain.
Domain matching needs care. Normalize protocol, casing, trailing slashes, and common URL variations before comparison. Decide in advance whether subdomains count as part of the tracked domain. Preserve the original URL as well as the normalized comparison value so a reviewer can inspect what was actually returned.
Keep these concepts separate:
- AI result presence: an AI-related result element was detected.
- Domain reference: a returned source or link matched the tracked domain.
- Page reference: a returned source matched the tracked URL.
- Brand mention: text contained a brand or entity name without proving a source citation.
- Organic ranking: a conventional result position, which is a different measurement.
What the response proves
The captured response includes a qualifying AI element or source URL under the rules you defined.
What requires caution
A ranking, brand mention, or content similarity may suggest relevance, but it does not by itself prove that a page was referenced.
Retain the raw response or a durable reference to it when practical. Normalized fields are useful for dashboards, but raw evidence is important when a parser changes or a stakeholder questions a result.
Store data for comparison, not just collection
Google Sheets may be adequate for a small test, while Airtable, a database, or a reporting platform may be better for a larger monitoring set. The destination matters less than the structure. Use one row or record per query-context-observation rather than overwriting the latest value.
A historical record lets you compare changes by query group, landing page, location, or date. It also supports useful questions such as:
- Which query groups generate AI results most consistently?
- Which pages are repeatedly referenced?
- Where has a reference disappeared after a content change?
- Are changes isolated to one location or common across locations?
- How often does the workflow fail to collect usable data?
Store a run identifier and parser version where possible. If the extraction rules change, you can distinguish a real visibility change from a change in how the response was interpreted.
Design alerts around decisions
An alert is useful only when someone knows what to do next. Avoid notifications for every individual observation. Instead, define conditions such as a reference disappearing across two completed checks, a new reference appearing for a priority query group, or a sudden increase in failed requests.
Use aggregation before notification. For example, a router can compare the latest observation with a previous record, while a second step can suppress alerts until the change meets a duration or frequency rule. Send the result to the owner of the relevant decision, not to a general channel by default.
- Define what counts as a reference.
- Separate failed checks from negative observations.
- Set a comparison period and threshold.
- Assign an owner for investigation.
- Record the next action expected from the alert.
For example, if a priority query loses a page reference, the next action might be to inspect the captured response, compare the organic result, review recent content changes, and decide whether further analysis is justified. The alert should start that process, not pretend to explain the cause.
Example: a controlled visibility review
Consider a hypothetical team monitoring product education queries across two countries. It stores 50 priority queries with a target domain, preferred landing page, and location for each record. A scheduled Make.com scenario checks the set, records the raw provider response, and writes a normalized observation to a database.
The team does not alert when a single query changes once. It creates an investigation task only when a page reference is absent on two completed checks and the requests were successful. The task includes the query, location, previous observation, latest observation, and response reference. This gives the content owner enough context to investigate without treating the automation as an SEO decision-maker.
This example illustrates the broader rule: automation should reduce repetitive checking while leaving interpretation and ownership visible.
A visibility workflow should automate evidence collection and routing, not manufacture certainty from incomplete search data.
Maintain the workflow as search formats change
AI search monitoring is not a one-time integration. Review the workflow when the provider changes its response structure, when Google introduces a different result format, or when the business changes its target markets and query groups.
Monitor the workflow itself with basic operational fields: request status, response timestamp, parser status, record count, and last successful run. Add a test query or a small validation set so changes to the parser can be checked before the full monitoring set runs.
Keep the scenario understandable. If the process grows beyond a few modules, separate query management, data collection, parsing, storage, and alerting into distinct scenarios or sub-processes. ConsultEvo’s systems and automation services take the same process-first view: clarify the operating model before adding more tools.
If the data will feed a wider reporting or operations system, review the ownership and reporting design alongside the Make.com scenario. Examples of connected operational systems are shown in the ConsultEvo client work portfolio, but the right implementation depends on the decisions your team needs the data to support.
Frequently asked questions
Can Make.com directly determine whether Google AI Mode referenced my page?
Make.com orchestrates the workflow, but it does not create the underlying search evidence. A SERP data provider must return usable AI-related result or source data, and your parser must define how a page or domain reference is identified.
Should Google AI Mode references be measured like organic rankings?
No. Organic position, AI result presence, domain reference, page citation, and brand mention are related but distinct measurements. Store them separately so reports do not imply evidence that was not collected.
What should be stored from each AI search check?
Store the query context, timestamp, location, device, target domain or URL, result classification, reference URL when available, request status, and a raw response or durable response reference.
How should alerts be triggered for lost AI references?
Use successful checks and a defined comparison rule. For example, alert only after a qualifying reference is absent across two completed checks, while routing API failures to a separate workflow health notification.
Is a Google Search Console connection required?
Not necessarily. Search Console can provide useful performance context, but AI reference collection depends on the search data source and the fields it returns. Treat Search Console metrics and AI result observations as separate datasets.
Design a reliable search visibility workflow
If your AI search tracking is producing inconsistent data, unclear alerts, or reports no one can act on, ConsultEvo can help clarify the process, ownership, and automation design before you scale it.
