Client Report

Turn one property's performance into a deliverable a client can open: a self-contained HTML report, a client-portal table, or both. The output is the report summary for the user, the exact share URL with who has access to it, and the next steps. The user's request may contain a property, a date range or days, the client's email and name, a title, a focus (queries, pages, movers), and whether the user wants the HTML file, the portal link or both. For the content of a weekly digest, run the weekly-report skill and bring its mover tables here.

Workflow

1. Resolve the property 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. Use the last 28 days compared with the previous period unless the user specifies dates; generate_seo_report sizes both windows from days. GSC data lags about 2 to 3 days and the tools count back from the latest settled date, so state the dates the response reports (range, comparison) rather than implying the report runs through today, and if a dip appears at the very edge of the range, say it is likely reporting lag, not a real drop.

2. Confirm the deliverable. Ask, or infer from the user's request, what the client gets and who receives it (email, optional name):

   • the HTML report: one self-contained file the user forwards or uploads;
   • a portal table: one URL behind a client login, which the user sends once access is granted;
   • both, with the portal table carrying the one table the client will look at most. Every write step below lists what it will create and waits for the user's yes, and all of them need write access. If a write is refused because the connection is read-only, say so and complete the read-only parts.

3. Generate the report. Call generate_seo_report with siteUrl, days (7 to 180, default 28), format and includeSitemap (default true; false skips the sitemap fetch). Choose format by use:

   • html (the default): a finished, self-contained report in html, with bytes as its size. Save that string as a .html file and hand the file to the user; do not paste it into the conversation.
   • compact: a few numbers per section in sections (summary, trend, topQueries, topPages, countries, devices, ctrCurve, opportunities, rankingByQuery, rankingByPage, decay, cannibalization, sitemaps and more), each with a drill naming the tool and the exact arguments that reproduce it. Use it to narrate the report in chat and to fetch full rows for the portal table over the same window.
   • json: every sub-result in full, which is large; only when the user asks for the raw data. Every format carries highlights (kpis, topQueries, topPages, movers), range, comparison, settledThrough and dataSource. One call fans out to about twenty reads, so call it once per format you need, not once per question. ctr values are already percentages on a 0-100 scale; never multiply them by 100. position: lower is better, so a change toward a lower number is an improvement; never color it as a decline. Weight the story by the clicks and impressions at stake, not by percentages alone.