Performance Tracking

info

SCS v0.2 stores query-level GSC history in data/<workspace>/<workspace>-performance.csv with pid, period, query, url, pulled, clicks, impressions, CTR, and position. See Field Reference.

Google Search Console

GSC shows what happens after publishing — the data that closes the loop:

• Queries — which keywords drove impressions
• Clicks — organic click volume
• Impressions — how often pages appeared in search results
• CTR — click-through rate
• Average Position — an aggregate diagnostic; interpret with query, page, and date context
• Indexing — which pages are indexed
• Errors — technical issues affecting search visibility

Data collection and capability

Google provides a Search Console API, subject to its quotas and access requirements. The endpoints below are available APIs; their presence does not mean SCS currently collects this data automatically. In the documented SCS workflow, performance rows are imported or entered into the workspace CSV.

Data	Endpoint
Search analytics	searchanalytics.query
URL inspection	urlInspection.index.inspect
Sitemap list	sitemaps.list

Sitemap discovery is handled by the site's SEO plugin, not by SCS: SEOPress generates and serves the XML sitemap automatically when content is published. The sitemaps.list endpoint only reports which sitemaps Google already knows about. See XML Sitemaps.

The workspace performance CSV is query-level:

data/<workspace>/<workspace>-performance.csv
pid,site_id,title,keyword,created,updated,period,query,url,pulled,gsc_clicks,gsc_impressions,gsc_ctr,gsc_position,notes

info

GSC data is delayed and has a limited retention window (commonly about 16 months). Pull on a regular schedule and retain dated snapshots. Verify current Google limits and API behavior for your property. Store rows with the correct page URL and period; do not treat average position as a standalone outcome.

Monthly performance review

For each important page, record a baseline and compare like-for-like periods. Review:

1. Whether the page is indexed and the intended canonical URL is appearing.
2. Which queries and landing pages receive impressions and clicks.
3. Whether query intent matches the page and its conversion goal.
4. CTR, impressions, and clicks in context—accounting for seasonality and changes in demand where possible.
5. Whether another page on the site serves the same queries or competes for the same task.
6. What changed on the page, when it changed, and the next action.

Record an evidence-based action: maintain, investigate, improve, consolidate, or prune. A change in average position alone is not enough to diagnose success or failure. Avoid refreshing content on a fixed schedule when the evidence does not indicate a need.

Content Refresh Cycle

Phase	Timing	Action
Initial check	After publication, when data is available	Verify the intended URL and indexing; investigate technical issues
Performance review	At a consistent interval suited to traffic and decision needs	Compare relevant queries and pages with a baseline; record findings
Refresh decision	When evidence suggests decay, changed intent, outdated claims, or overlap	Update, consolidate, investigate, or leave unchanged with rationale

Suggested Reporting Cadence

• Weekly: Pipeline status review, new keyword opportunities
• Monthly: Review priority pages and record findings/actions; cadence may vary by traffic and business need.
• Quarterly: Review coverage, overlap, and content decisions; prioritize changes based on evidence rather than age alone.

GSC CSV architecture

Performance is stored per workspace, separate from the keyword stage CSVs:

data/<workspace>/<workspace>-keywords.csv      → production state
data/<workspace>/<workspace>-publishing.csv    → WordPress state
data/<workspace>/<workspace>-performance.csv   → query-level GSC history

Join them on pid (and url) for end-to-end reporting.