Page Deep Dive

Explain everything the connected tools know about one URL and condense it into a page scorecard (search, indexing, on-page, speed, engagement), the queries it wins and loses, and recommendations. The user's request may contain a property, the page URL or path, a date range, and a focus hint such as a country or "mobile only"; honor all of them.

Workflow

1. Resolve the property, the URL and the window. If the user's request or the conversation names a property, use it. Site URLs use GSC formats: sc-domain:example.com or https://www.example.com/. Otherwise call list_sites and pick the obvious match. If several plausible properties exist, ask the user which one before continuing.

   • The page must be a full URL. When the user gives only a path, build the URL from the property's host, and for a sc-domain: property confirm host and protocol against the rows of query_top_pages rather than guessing between www and the bare host.
   • Use the last 28 days compared with the previous period unless the user specifies dates. The daily tools take no comparison parameter, so compare the first and second half of the window yourself and say the delta is derived.
   • GSC data lags about 2 to 3 days: never treat the most recent 2 days as complete, and if a dip appears at the very edge of the range, say it is likely reporting lag, not a real drop.

2. Daily series. Call get_page_performance with siteUrl, pageUrl and the optional startDate/endDate. daily holds one row per day, oldest first, with clicks, impressions, ctr and position.

   • ctr values are already percentages on a 0-100 scale. Never multiply them by 100. position: lower is better, and a change toward a lower number is an improvement; never color it as a decline.
   • Describe the shape of the trend: flat, a step change on a named date, a gradual slide, a spike, or a weekly rhythm. Impressions rising while clicks stay flat point at the snippet or the position; impressions falling with position steady point at demand or indexing.
   • The pageUrl filter is an exact match on the full URL. When daily is empty the response carries emptyBecause and a nextStep that calls query_search_analytics with a page contains filter to list the URL variants Search Console records (trailing slash, protocol, host); rerun with the variant that carries the traffic and tell the user which one it was.

3. Queries the page wins and loses. Call query_search_analytics with dimensions: ["query"], filters: [{ "dimension": "page", "operator": "equals", "expression": "<page URL>" }] and rowLimit: 100; follow pagination.nextOffset as startRow only when the user wants the long tail. Rows carry keys (the query), clicks, impressions, ctr on the 0-100 scale and position.

   • Sort the rows into winners (page 1 with clicks), near misses (position 11 to 20 with real impressions) and snippet losers (page 1 with far fewer clicks than the impressions suggest).
   • Query rows cover only the queries Google lists: quote the page total from coverage.filteredTotals, mention coverage.hiddenClicksShare (0-1) when it is large, and never sum the rows into a total.