seo-opportunities

Use for an SEO report, search traffic changes, declining pages, low CTR, striking-distance queries, indexing issues or recommendations. For the weekly digest use compact mode below.

The report must help a teammate decide what to do this week. Collect evidence first, then write a short briefing with wins, losses, specific changes and follow-up measurements. Do not return a list of metrics followed by generic advice or a backlog of queries the agent could have run itself.

Discover the exact schemas of admin-mcp__search-console-analytics, admin-mcp__search-console-inspect-url, admin-mcp__search-console-sitemaps, admin-mcp__list-feedback and admin-mcp__crux-web-vitals before calling them. These require team access. If a tool is unavailable or not configured, report its concrete error and continue with available evidence; never invent data or bypass access controls.

Scope and dates

• Default to 28 days for a standalone report; use the requested window when supplied, including the digest's N days.
• Search Console lags 2–3 days. Set inclusive endDate to today minus 3 calendar days; startDate is endDate minus (N−1) days. The previous window ends the day before startDate and spans exactly N days. Pass dates explicitly on every call; the API default remains 28 days regardless of the requested window.
• Default scope is nuxt.com and all subdomains, including ui.nuxt.com and nested subdomains. On every analytics call use filters=[{"dimension":"page","operator":"includingRegex","expression":"^https?://([a-z0-9-]+[.])*nuxt[.]com/"}]. This includes HTTP and HTTPS URLs; the anchored hostname and trailing slash exclude lookalike domains. Do not intersect it with the old apex-only filter. If the user explicitly narrows the report to one host, REPLACE the domain-wide expression with that exact host (for example ^https?://ui[.]nuxt[.]com/). Add exact-page, query and requested path filters with AND. Only use hosts covered by the configured Search Console property; if a URL-prefix property covers just the apex, disclose that subdomain data is unavailable rather than claiming full domain coverage.
• Use the same property, filters and search type (web) in both windows. Do not compare filtered totals with unfiltered property totals or older reports with different scope.
• CTR is already a percentage; its changes are percentage points. Lower average position is better: write “improved 7.3 → 5.3” or “worsened 5.3 → 7.3.” When the previous baseline is zero, show the absolute change and “no prior baseline,” not a percentage. Flag tiny baselines rather than celebrating large percentages on a handful of clicks.

Date coverage gate

• Before calculating ANY period changes, query dimensions=["date"], rowLimit=500, startRow=0 for BOTH explicit windows with the selected domain-or-host/path scope. Verify all N expected calendar dates are present in each response, including each start and end date. The daily row limit must cover the whole window, including a digest requesting up to 365 days. Do not confuse date coverage with partial page/query coverage.
• Search Console retains only 16 months. Two 365-day windows cannot both fit in that history. A nominal 3-day reporting lag also does not guarantee the latest requested dates have arrived. If dates are missing or a request falls outside retention, do not fill them with zero or call the comparison complete; no returned data can also mean no traffic, so coverage is unverified rather than a proven outage.
• When either window is incomplete, unavailable or unverified, show available totals separately as partial/unverified with the requested dates, actual returned date span and missing-date count where known. Suppress percent/absolute deltas, win/loss labels and trend claims that depend on that comparison. Say “comparison unavailable — .” Keep current-data recommendations only when independently supported. Do not silently shorten the window, extrapolate a full period or shift dates without refetching all evidence for both new windows. The rest of the weekly digest must continue.