Google Analytics MCP lets an AI assistant retrieve your GA4 reports and help you investigate organic traffic, landing pages and business outcomes. The useful part is not asking it to "do SEO." It is asking a specific question with a property, a date range, a traffic definition and a result you can check.
These 13 questions turn that approach into a practical workflow. Each includes a prompt to adapt, the output to request and the conclusions the data can support. They target Google's official Analytics MCP implementation, not a particular hosted connector. The prompts are documentation-based templates, not results from a private analytics account.
GA4 describes measured activity on your site. Search queries, impressions and Google positions need Search Console or another appropriate source; connecting GA4 through MCP does not add those datasets.
Before you ask Google Analytics MCP
Start with a working connection and access to the intended GA4 property. Google's official Analytics MCP repository explains the current installation, credentials and API setup. Its tools include property discovery, standard reports, custom-definition discovery and funnel reports. Check the tools your installed version actually exposes before requesting a particular operation.
The official server is read-only: it can retrieve reports, but it cannot install tracking, register events or change Analytics settings. An assistant with other connected tools may have additional permissions; the Analytics connection's limits do not describe every tool in that assistant.
If MCP itself is unfamiliar, the SEO MCP overview explains the connection model. You do not need a new prompt architecture for every question below. Establish this common reporting contract once:
Use Google's official Analytics MCP tools for property [PROPERTY_ID].
First confirm its name, reporting time zone and currency.
For session-based organic analysis, filter
sessionDefaultChannelGroup exactly to Organic Search.
Use only the production hostname(s): [PRODUCTION_HOSTS].
Compare the latest 28 calendar days ending 3 days ago with the
immediately preceding 28 days, in the property's time zone.
Print the resolved inclusive start/end dates before interpreting results.
Show the dimensions, metrics, filters and tool used for each result.
Retrieve all rows needed for the comparison, not just the first page.
Report available quality/coverage metadata and any missing capability.
Separate returned facts, calculations and hypotheses.
Do not invent unavailable values or change the requested traffic segment.
Replace the placeholders with your own property and exact hostnames. Filtering only www.example.com, for instance, would exclude example.com if both legitimately serve production visitors. Decide the allowed set first.
Use session acquisition consistently. sessionDefaultChannelGroup describes how the session was acquired; first-user acquisition answers a different question. Google's channel definitions provide the underlying classification.
The three-day buffer is a practical starting convention, not a completeness guarantee. Google's data freshness guidance explains that processing and attribution can change reported data. Adjust the window when the property's situation requires it, and do not compare an incomplete day against a complete one.
For metric definitions and the equivalent GA4 interface workflow, use the existing GA4 reporting guide. This article concentrates on asking and checking the questions through MCP.
1. Is organic search traffic growing?
Begin with a trend, not a verdict about your entire SEO strategy. A period total can hide a recent decline, a one-day spike or an uneven comparison.
Using the reporting contract, compare Organic Search sessions and
engagedSessions across the two periods. Return period totals,
absolute differences and percentage changes.
Then return daily sessions for both windows, aligned by day number.
Flag unusual days and explain whether the change is sustained or
concentrated. If the earlier value is zero, label percentage change
not applicable rather than inventing an infinite growth rate.
Request two outputs: a summary table and a daily series. The summary tells you the size of the change; the series tells you when to investigate. Keep the current and previous windows visibly labeled.
If sessions increased while engaged sessions stayed flat, that is a reason to examine the traffic mix. It does not establish that the new traffic is poor or that your content disappointed readers. An event-configuration change could also alter engagement reporting.
For a seasonal business, add a separately labeled year-over-year comparison if the historical data is available. It provides context; it should not silently replace the consecutive-period comparison.
2. Which landing pages lost the most organic sessions?
A page losing half its traffic is not automatically your largest problem. You need the original volume, absolute loss and business context.
Compare sessions by landingPagePlusQueryString for both periods,
using the reporting contract. Retrieve the complete required URL
set from each period and join the two sets before ranking losses.
Return URL, previous sessions, current sessions, absolute change
and percentage change. Sort the decline table by sessions lost.
Separate newly appearing and disappearing URLs. Identify missing
rows or coverage limits before treating an absent URL as zero.
Consider this illustrative calculation, not an observed GA4 result:
| Landing page | Previous sessions | Current sessions | Change | Percentage |
|---|---|---|---|---|
/guides/example-a/ |
40 | 20 | -20 | -50% |
/products/example-b/ |
4,000 | 3,200 | -800 | -20% |
The second page lost more sessions despite the smaller percentage decline. If it is commercially important, it may deserve attention first.
Do not request only this month's top pages: a formerly important page could have disappeared from that sample. Pagination and a union of both periods protect against that particular blind spot.
GA4 can locate the measured loss. To investigate Google impressions, clicks, CTR or position, continue with Search Console MCP. A GA4 decline alone cannot distinguish a ranking change from lower demand, attribution changes or broken measurement.
3. Which search engines explain the change?
"Organic Search" is a channel, not a synonym for Google. A change in its total can come from a different mix of search sources.
Under the same Organic Search and production-host filters, compare
sessions by sessionSourceMedium for the two periods.
Return each source/medium, both session counts and absolute change.
Show which sources contributed most to the net change, then list
all other sources separately rather than hiding them in the summary.
Do not infer the search query or an AI citation from a source label.
Use sessionSourceMedium when you want the combined label, or sessionSource when the source alone is sufficient. The Data API schema defines these as session-acquisition dimensions.
If the decline is concentrated in one search source, that narrows your next investigation. If all sources fall on the same date, measurement or website availability becomes another hypothesis to check.
Neither pattern proves its cause. In particular, an Analytics source label cannot reveal whether a visit came from a conventional Google result or a specific AI-generated answer. Keep that uncertainty in the report.
4. Are mobile visitors getting worse outcomes?
Separate changes in traffic volume from changes in outcomes per session. More mobile visits can change an overall rate even when neither device group has deteriorated.
Compare Organic Search by deviceCategory for both periods.
Return sessions, engagedSessions and engagementRate. Where a
verified relevant key event is configured, also return its
session key-event rate with the event explicitly named.
Show count changes and rate changes in percentage points.
For the largest device-specific decline, break out landing pages.
Flag small samples and distinguish a changing device mix from
worse performance within the same device group.
Use the device summary to choose the next page-level check. If one important mobile landing page has a large session count and weaker outcomes, examine its form, content and purchase journey rather than declaring the whole mobile website broken.
A rate moving from 4% to 3% fell by one percentage point, or 25% relative to its earlier rate. Those are different descriptions; the assistant should label the calculation it uses.
Do not average page-level percentages to produce a device total. Use the appropriate aggregate rate or matching numerator and denominator. Analytics can identify a segment to inspect; it does not measure that page's loading speed or diagnose a browser defect.
5. Which countries need separate SEO attention?
A site's overall growth can hide a loss in the market it actually serves. Geography helps you distinguish a larger audience from a more useful one.
Compare Organic Search sessions by country for both periods.
Keep the countries in [TARGET_MARKETS] identifiable and show
other countries separately. Return sessions, engagedSessions
and the agreed business-outcome metric where available.
Identify the largest absolute changes within target markets.
For a material change, drill into landing pages and session source.
Flag small or privacy-limited groups; do not invent their values.
Define the target markets yourself rather than asking the assistant to decide where your business should operate. A local service company and an international software company will interpret the same geographic distribution differently.
If one market is weakening, inspect the relevant landing pages and search evidence. The country breakdown does not diagnose incorrect language targeting or hreflang by itself. Country and language are also different dimensions: a country is not proof of the language a visitor wanted.
Avoid automatically turning every city or country row into a new SEO landing page. The analysis should identify an actual reader or customer need before it becomes a content-production decision.
6. Which content groups attract useful organic visits?
Individual URLs can be noisy. Grouping landing pages can reveal whether your guides, product pages or location pages are doing the job you expect.
Use these mutually exclusive landing-page rules:
Guides: paths beginning /guides/
Products: paths beginning /products/
Locations: paths beginning /locations/
Other: every remaining path, with unclassified values flagged.
Replace these example rules with my confirmed site structure.
Compare Organic Search sessions and agreed outcomes by group.
Show the mapping rules and unmatched URLs. Calculate rates from
matching counts rather than averaging URL-level percentages.
Identify important exceptions within each group.
These are example path rules, not a claim about your website. If an existing registered content-group dimension already matches your reporting need, confirm it before using it. Otherwise, retrieve the required URL-level data and apply the explicit grouping to the returned table. Label that grouping as a calculation outside the GA4 property configuration.
Keep query strings from accidentally turning one page into many apparent content types. Decide how tracking parameters should be normalized for this analysis, preserve meaningful variants and disclose the rule.
The result can guide effort: perhaps a small collection of service pages generates the useful outcomes while a large blog attracts most sessions. That is a prioritization finding, not permission to delete the blog or assume those sessions have no other value.
7. Which pages attract visits without engagement?
Use engagement to choose pages for review, then inspect what those pages are meant to do. A quick contact lookup and a long tutorial should not automatically be judged by the same behavior.
For Organic Search landing pages, return sessions, engagedSessions
and engagementRate for both periods. Apply my minimum review volume
of [MIN_SESSIONS] to avoid ranking tiny samples as major problems.
Find pages with meaningful traffic and weakening engagement.
For each, show counts, rate change and the page's intended task.
Do not infer reading completion, satisfaction or ranking impact
from engagementRate alone.
Pick the minimum volume according to your site and decision, not a supposed universal SEO threshold. Keep excluded low-volume pages available in a separate table if they are commercially important.
Google's user-engagement explanation describes measured foreground activity. That is not the same thing as proving that someone understood an article or found a useful answer. A custom completion event requires an actual implementation; MCP cannot invent it from pageviews.
An unexpected pattern can justify reviewing the opening answer, navigation, content relevance or tracking. Do not mechanically lengthen a page to increase time spent. The useful outcome may be helping the visitor finish the task faster.
8. Which organic landing pages generate leads?
Define a lead before asking the question. A button click, a successful enquiry and a qualified sales opportunity are different outcomes.
Our agreed lead event is [LEAD_KEY_EVENT]. Confirm that its
property-specific session key-event rate metric is available.
For Organic Search landing pages, return sessions and the rate
of sessions containing that specific key event, for both periods.
Keep all eligible organic sessions as the rate denominator.
Do not substitute the all-key-events rate or filter eventName
in a way that changes the intended session population.
If the selected metric is unavailable, report that limitation.
For event volume, run a separate eventName-filtered eventCount
report for the selected lead event and label these as occurrences.
Show the counts alongside rates without mixing their denominators.
The schema distinguishes sessionKeyEventRate, which covers any key event, from event-specific metrics such as sessionKeyEventRate:generate_lead when that event is configured as a key event. Replace the example with the actual configured event; a plausible name does not prove it exists.
If you also request event counts, label them as event occurrences. Repeated submissions can make them different from sessions with a lead, unique leads or qualified opportunities. Do not reconstruct an exact lead count from a rounded percentage.
A page with many sessions but few recorded leads may deserve a clearer next step or a form review. Before changing it, check whether the measurement really captures successful submissions. GA4 alone cannot tell you which enquiries became sales-qualified leads unless the appropriate data has actually been supplied.
9. Which organic landing pages generate revenue?
For a store with working ecommerce measurement, connect landing-page demand to recorded purchases and revenue. Keep the units and attribution context visible.
For Organic Search, compare landingPagePlusQueryString with
sessions, ecommercePurchases and purchaseRevenue in both periods.
Display the report currency. Show absolute changes and calculate
purchase revenue per session from matching aggregate values.
Flag missing ecommerce implementation, restricted revenue access
or incompatible fields. Do not return a missing revenue field as
zero, and do not describe recorded revenue as profit or proven
incremental revenue caused by SEO.
ecommercePurchases counts purchase events under its documented definition. purchaseRevenue has its own event and refund rules; they are not interchangeable measures. Confirm the implementation and business model before interpreting a surprising ratio, especially when a property combines web and app activity.
Read currency and any active metric restrictions from the response metadata when available. A permission restriction is different from a genuine period with no purchases.
Use the output to protect important commercial pages and investigate changes. Do not call it return on SEO investment without the relevant cost data and an appropriate attribution method. The report supplies recorded Analytics evidence, not a controlled estimate of what would have happened without SEO.
10. Do new and returning organic visitors behave differently?
An increase in organic sessions may reflect more first-time visits, more returning visits or both. The useful question is whether the mix changed and how each group behaved.
Within the agreed Organic Search session scope, request a
compatible report using newVsReturning and the selected session
and outcome metrics. Compare both periods and label the groups
as GA4 reports them.
Show volume and rates separately. Keep unclassified values visible.
If the combination is incompatible, report the exact limitation
rather than switching to firstUserSource or a different population.
Do not sum distinct user counts across groups as a unique total.
The newVsReturning dimension distinguishes users with no previous sessions from users with previous sessions under Analytics' measurement. Its interpretation depends on the identity and collection information available to the property.
A person can arrive as new earlier in a reporting window and return later. Device changes, consent conditions and other measurement limits also make this different from a complete history of real people.
Use this split to investigate whether content mainly introduces visitors to the site or accompanies repeat visits. Do not label the result a retention study or lifetime-value calculation. Those require a separately defined cohort, follow-up window and supporting data.
11. What changed after a content update?
Use a before-and-after comparison to decide what to investigate next, not to claim that an edit caused every subsequent change.
This page changed on [UPDATE_DATE]: [LANDING_PAGE].
The intended change was [CHANGE_DESCRIPTION].
Compare 28 complete days before the update with 28 complete days
after it, excluding the implementation day. Use matching Organic
Search, hostname and landing-page rules. If 28 processed days are
not yet available, report that the requested comparison is not ready.
Return sessions, engagement and the agreed outcome metrics.
Compare relevant device/source shifts. Keep observations separate
from explanations; list external evidence needed to test causes.
For a renamed URL, supply the old and new paths and the actual redirect date. Otherwise, an assistant may report a loss on the old address while ignoring the replacement. Document which pages belong in each period before combining them.
Choose a reasonable comparison page or group only if you can explain why it is comparable. It may help contextualize a sitewide change, but it does not turn an observational comparison into a randomized test.
A better answer might say, "Recorded organic sessions improved after the update, while the device mix also changed." It should not jump to "The new introduction increased rankings." Use the appropriate Search Console evidence and change history to investigate that separate claim.
12. Where do organic visitors leave the conversion journey?
Counts of product views, cart additions and purchases are useful, but dividing one event total by another does not establish that the same visitors completed those steps in order.
Check whether the installed official MCP exposes run_funnel_report
and can express the requested organic population and step rules.
For our actual tracked events [STEP_1], [STEP_2] and [STEP_3],
request an ordered funnel with the Organic Search segment stated
explicitly. Describe entry conditions, ordering, reporting unit
and whether the conditions are user- or session-scoped.
Show step counts and drop-offs, with a device breakdown if supported.
If the available tool cannot enforce the requested population or
journey definition, say this funnel is unavailable. Do not replace
it with an all-traffic funnel or ratios of independent event totals.
The current official implementation includes run_funnel_report, using the Data API's alpha funnel reporting. Treat its installed signature and the current funnel guide as the authority for supported conditions.
For a shop, the intended journey might be view_item, add_to_cart, begin_checkout and purchase. For a service website, it might use a real enquiry-start and successful-submission event. Those are possible definitions, not a guarantee that your property records them.
Confirm the question's scope before interpreting the output. A user-level sequence can answer something different from "what happened within one organic session." A large drop-off can identify a step worth investigating; it cannot establish why the visitor stopped or whether an interface change will fix it.
13. Could a tracking problem explain the SEO report?
Sometimes the first repair belongs in measurement. A broken event or an unexpected hostname can make a normal business week look like an SEO failure.
First use the agreed Organic Search scope to inspect daily sessions,
landing-page values and the previously selected outcome metrics.
Flag abrupt discontinuities, unexpected (not set) values and
outcome changes that do not track the session trend.
As a separate, clearly labeled diagnostic report, inspect the
property's hostName and channel distributions to look for staging,
local development or a possible attribution shift. Do not replace
the original production-organic result with this broader report.
Return an issue table with the observed signal, possible explanation,
evidence still needed, owner and next verification step.
The broader diagnostic query is deliberately requested here. It is necessary to see traffic excluded by the original host/channel filters; it is not a substitute answer to the original SEO question.
Look for a sharp change around a release, a new production hostname missing from your allowlist, or a lead event that stops while traffic remains stable. These patterns justify checking the measurement configuration. They do not prove a tag failed.
The Analytics MCP can inspect recorded reports and supported configuration reads. It cannot inspect your deployed tracking code, validate every browser event or repair a consent implementation merely by reading GA4. Assign the next check to the appropriate person or authorized tool, and keep unresolved measurement problems visible before making a content decision.
One precise run_report example
Natural-language prompts are easier to reuse when you can inspect one concrete request. The following is an illustrative argument object for the official MCP tool, not a completed query and not a REST request. Replace the property ID and hostname before using it.
The current run_report implementation expects snake_case argument and nested protobuf field names. Dimension and metric identifiers remain their documented API strings, such as landingPagePlusQueryString. A hosted connector's runRawReport may expect a different shape.
{
"property_id": "123456789",
"date_ranges": [
{
"start_date": "30daysAgo",
"end_date": "3daysAgo",
"name": "current"
},
{
"start_date": "58daysAgo",
"end_date": "31daysAgo",
"name": "previous"
}
],
"dimensions": ["landingPagePlusQueryString"],
"metrics": ["sessions", "engagedSessions", "engagementRate"],
"dimension_filter": {
"and_group": {
"expressions": [
{
"filter": {
"field_name": "sessionDefaultChannelGroup",
"string_filter": {
"match_type": "EXACT",
"value": "Organic Search"
}
}
},
{
"filter": {
"field_name": "hostName",
"string_filter": {
"match_type": "EXACT",
"value": "www.example.com"
}
}
}
]
}
},
"order_bys": [
{"metric": {"metric_name": "sessions"}, "desc": true}
],
"limit": 100,
"offset": 0,
"return_property_quota": true
}
Both ranges contain 28 days because the endpoints are inclusive. Google's date-range reference explains relative dates and the property's reporting time zone.
The hostname condition intentionally allows one example hostname. For several legitimate production hosts, change that condition to the appropriate explicit allowed set; do not remove host filtering without deciding the scope.
A limit of 100 is a page size, not evidence that the report contains only 100 rows. Use the returned row count and Data API pagination rules to retrieve the required rows with the same query definition. Do not confuse a short response, privacy suppression and statistical sampling: they are different limitations.
This object was checked against the documented schema and official source signature. It was not executed against a private GA4 property; actual field compatibility, permissions and available data still need verification in yours.
Check the answer before acting
Ask for a small evidence table before accepting the assistant's recommendations. It should contain the property, resolved dates, filters, dimensions, metrics, returned coverage and the calculation behind each important claim.
Use this worksheet when the answer looks suspicious:
| What you see | What to verify next |
|---|---|
| GA4 and MCP show different totals | Match property, dates, time zone, hostname, acquisition scope, filters and metric definitions before diagnosing a discrepancy. |
| A formerly important URL is missing | Check both periods, pagination, URL variants and report coverage before treating it as zero. |
| A report is empty | Inspect the available empty reason, permissions, field compatibility and whether the requested data was actually collected. |
| A thresholding or sampling warning appears | Preserve the warning and its actual meaning. Being subject to thresholding does not by itself prove rows were removed. |
Rows were grouped into (other) |
Record the loss of detail. Fetching more pages does not reconstruct the underlying combinations. |
| Revenue is missing | Check implementation, metric compatibility, currency and access restrictions; missing is not zero. |
| A rate looks surprising | Verify the event definition, denominator, aggregation and whether the reported change is relative or in percentage points. |
Keep the first query small: answer one question with a few necessary dimensions before expanding it. More dimensions can produce a larger report without producing a better decision. Available quota information can help diagnose query limitations; it does not make a restricted or uncollected value recoverable.
For every proposed action, request four things: the observed signal, the possible explanation, the evidence still needed and the next responsible person or check. A suitable output is "review the mobile enquiry flow on this landing page," supported by the relevant counts. "Rewrite everything because Google dislikes the site" is not a finding available from GA4.
Once the definitions and queries are stable, reuse the useful outputs in a weekly SEO dashboard. Retain enough request context to reproduce the next report. The value of Google Analytics MCP is a shorter route from a precise question to checkable evidence and a sensible next action.