Search Console: Build a Content Action Plan

Google Search Console content optimization starts with three commitments for every row you touch: a named owner, a baseline captured before the edit, and a review date. Copy the table below into a spreadsheet and fill in one row per page or query. The steps after it explain how to complete each column and which rows to drop.

Page or query	Evidence (metric, period, filter)	Diagnosis	Action	Owner	Effort (hours)	Baseline captured (values, dates, filters)	Review date	Decision not to act (reason)
Page URL, plus the query row that triggered it	Impressions, clicks, average position, date range, search type, country and device filters	Snippet problem, content-fit problem, decay, technical suspicion, or noise	One change, specific enough to brief	A named person, not “the team”	Your estimate	Numbers copied before any edit, with the export date	Provisional date, plus a check that the change is live	Why this row waits or is dropped

One cycle, in five moves

Set one date range and one set of filters, and write them in the sheet header.
Capture the baseline for every candidate row before anyone edits a page.
Classify each row, delete the rows that fail the stop rules, and sort what is left by absolute clicks or impressions.
Add up the effort column until you reach the hours you have this cycle. Everything else gets a “not this cycle” note.
Make the changes, record the date, and set a review date you will keep.

This procedure is for people who have a verified Search Console property and published pages. If you have no content yet, it will not tell you what to write. It helps you decide which existing pages deserve your next few hours.

Before you choose topics, sort your existing pages by what they already earn in search, since that tells you where limited editing time pays off most. capacity budget before a keyword list It walks through turning Search Console data into a ranked action plan, which is the practical step a lean team needs first.

Step 1: Fix the window and capture the baseline before you change anything

Choose one date range and keep it for the whole analysis. Use the same search type, country, device and any query or page filters for every row you compare. These settings define what each number includes, so changing any of them makes your comparison inconsistent.

Keep the newest days out of the baseline. Google’s Performance report documentation says the newest data can be preliminary, meaning it is still being collected and might change in the next few hours. As a recommendation, end your baseline period a week or more before today.

Write the numbers somewhere durable, such as a dated spreadsheet tab. Search Console keeps data for the last 16 months, and that window moves forward every day. The baseline you record today is the only copy you are sure to still have, so do not assume you can re-derive it later.

Step 2: Export the data and note what you did not get

Start with a standard export from the Performance report. It takes the least effort, and you need nothing more technical to finish this plan.

Three details change how you read the file:

The table is capped. Google’s About Search Console data page says tables show a maximum of 1,000 rows, so some rows might be omitted. Chart totals can be higher than the sum of the table rows for this and other reasons.
Dashes and tildes become zeros. The same page says any value shown as ~ or - in the report will be a zero in the downloaded data. A zero can mean “not enough data to display”, so never write a row off as worthless on a zero alone.
Filtered totals differ from unfiltered ones. Anonymized queries are included in chart totals unless a query filter is applied, such as “queries containing”. A filtered and an unfiltered total cover different sets of rows.

Google’s API and bulk export can widen coverage, but neither guarantees completeness. The API reference says it does not guarantee to return all data rows, only top ones. Paging with a start offset shifts which rows you see; it does not turn a truncated sample into a full dataset. Bulk export, which Google introduced as a way to access your Search Console data, is the route Google describes as the most complete. It needs a Google Cloud project with billing and BigQuery enabled, and usage above the free quota is charged. The export begins from the day you set it up, so for earlier history Google points to the API or the reports. Treat it as an option for a later cycle.

Before deciding anything, check which pages your own performance data flags as worth reviewing first. Search Console data That workflow turns raw Search Console figures into a prioritized list, so you spend effort on the pages where a refresh or rewrite will matter most.

Beside the export, write down the row count, any filters applied, and whether the figures came from the table or a chart total. The limits then travel with the numbers.

Step 3: Read every number as an average

Google defines average position as the average position of the topmost result from your site. In the chart that covers your whole site. In the table it covers the specific URL or grouping dimension in that row.

So a query row is itself an average. It blends every appearance of that query in your period: mobile and desktop, different countries, different days, different positions. Treat “position 11” as an initial triage hypothesis about where to look, and never report it as an exact rank.

Practitioner guides often suggest filtering for queries between positions 5 and 20 to find pages close to the first page; Kitto’s low-hanging fruit guide is one example. That range is a convenient heuristic that the guide chose, and Google sets no such threshold. Use it to decide where to look, then open the rows behind each page.

Sort by absolute clicks or impressions before you sort by click-through rate (CTR). A CTR on a row with 6 impressions is one click away from a very different number.

Step 4: Classify each row against a decision rule

Give every row one primary label. Google’s common tasks guide gives two options for a page with low CTR: update the title and description to better represent the content, or adjust the content to align better with the queries that show the page. It does not say how to choose. Our recommendation is to read the query rows behind the page.

Snippet problem. The queries match what the page is about and the average position is reasonably high. The title or description is the first suspect.
Content-fit problem. The queries do not match what the page says or promises, so a new snippet will leave the mismatch in place. Look at the content, the page’s target, and whether another page serves the query better.
Decay. Clicks or impressions for a page that used to perform have fallen across several comparable periods. Check for market changes and competing pages before you rewrite.
Technical suspicion. Impressions fall sharply or the page seems to be missing. Before you send a rewrite to an owner, check whether the page is indexed and which URL Google treats as canonical. A rewrite cannot fix a page that is not indexed as you expect.
Noise. A single-week spike, a handful of impressions, or numbers that depend on a filter you cannot reproduce.

For low-CTR pages, also consider AI surfaces. Google’s generative AI performance report is an impressions view. It shows how many times links to your site were shown in generative AI features on Google Search, and it has a Pages dimension. The usual 1,000-row limit applies, and the report may not appear if your site has not received enough impressions in those features. Google also says clicks do come from results pages with AI Overviews, so these surfaces give you no reason to ignore a page’s clicks. Check whether the page appears in the Pages view and treat AI surfaces as one possible explanation, alongside intent mismatch and snippet quality. Do not subtract AI impressions from the main report to isolate a clean CTR; the reports do not let you measure the effect on any one page.

Before you pull pairs of competing URLs, confirm what the export actually covers, since row limits and date windows can hide pages. Search Console query and page data limits It explains how the Pages view and API row caps affect which cannibalizing URLs you see in the data.

Step 5: Delete most of the list

Remove a row from this cycle when it is one of these:

A query for your own brand, which other pages and channels already serve.
A query for a competitor’s brand, where the intent belongs to them.
A question the results page answers itself, where a click was never likely to be the goal.
A single-week spike that does not repeat in the comparison periods.
A row built on sparse data, where too few impressions exist for the metrics to mean much.
A decline caused by a technical fault. Route it to whoever manages the site’s technical health instead of assigning a content rewrite.

Record the reason for each deletion. When someone asks next quarter why a page was left alone, the note answers it.

Step 6: Size the plan to the hours you have

If your Search Console data already points to pages worth fixing, the next step is turning those findings into a realistic schedule. prioritize SEO tasks with a fixed weekly time budget It shows how to translate that list into a plan sized to the hours your team actually has.

Set your hours budget before you choose actions. If you have only a few hours a month for content updates, the plan has to fit inside them.

Estimate effort in three tiers: under one hour, one to three hours, and more than three. Keep one action per page. If a page has three problems, pick the first to fix and put the other two in the “not this cycle” column.

Once review flags a page that needs work, turn those findings into a prioritized list instead of fixing everything at once. Google Search Console content optimization: how to turn your data into a content action plan It shows how to size each fix by effort and keep one action per page for the current cycle.

The owner column is where the plan becomes real. Name one person per action, and name who approves it. If nobody on your team can do the work, your routes are in-house, freelancer, agency or a managed service, and they differ in who holds the work and who holds property access. The Blog Writer is a managed SEO and content service, powered by its own SEO operations platform, so it is one option for the owner column. Settle property access before you choose any route.

Worked example (illustrative sample data, not a real site or result)

These numbers are invented to show the arithmetic. They come from no real website and are not typical.

Suppose your budget this cycle is 6 hours. Four rows survive triage:

Row	Diagnosis	Action	Effort (hours)	Cumulative hours
/blog/invoice-template-guide, query “invoice template word”	Snippet problem: queries match, position is in the mid-teens	Rewrite title and description to name the Word template	1	1
/blog/payroll-basics, queries asking for payroll software for very small teams	Content-fit problem: the page explains payroll concepts, the queries ask for a product comparison	Add a section answering the queries, or move that query target to a new page	3	4
/blog/cookie-consent-notes, impressions fell sharply in the latest period	Technical suspicion	Check indexing and canonical URL before any rewrite	0.5	4.5
/blog/black-friday-checklist, one week of clicks spiked	Noise	Not actioned: a single-week spike that does not repeat in the comparison periods	0	4.5

The three actions use 4.5 of 6 hours, leaving 1.5. The next candidate, a rewrite of a comparison page, needs 2 hours, so it does not fit. It goes in the “not this cycle” column and becomes the first candidate next time.

The row with no action is a real output of the plan. It stops a team rewriting a page because one week looked exciting on a chart.

Step 7: Record the change and the date you will judge it

Write a change note for every edit: what changed, on which URL, on what date, and by whom. Keep it beside the baseline.

Set a provisional review date, then check two things before you judge the result. First, confirm the change is live and, where you can, that Google has had the chance to pick it up. Timing varies, so a fixed number of weeks guarantees nothing. Second, compare like with like. If the baseline used desktop and one country, the review must use the same settings and the same length of period.

Each row in the plan should name an owner, a baseline and a review date before any change goes live. publication record Recording those details alongside the change makes the later review comparable to the original baseline.

Clicks in Search Console are different from sessions in Google Analytics. Google says the two are calculated differently, so you will likely see different numbers. If you want to know whether a page’s search visits led to enquiries, join landing-page data to your enquiry records and treat the result as a hypothesis. A page-level join cannot show which query prompted a particular enquiry.

What this plan still cannot tell you

Demand. Search Console shows what your pages were shown for and clicked on. It reports nothing about how many people searched a phrase you do not rank for, so a plan built only on it ranks what already happens. Treat demand for a new topic as unknown until you check a separate source.
A clean AI and non-AI CTR split. The AI report and the main report aggregate differently, so one cannot be subtracted from the other.
Brand and non-brand splits in every setup. Google documents that the branded filter is unavailable for sub-properties and for sites with a low number of impressions. If your blog is a separate sub-property, the split may not be offered, and a query-text filter only approximates it.
Long-tail coverage. With capped tables and an API that does not guarantee all rows, your export may miss queries a page earned. Absence from the export says little about what happened.
A forecast. The plan tells you what to do and how to check it. Rankings, traffic and enquiries after the change remain unknown.

Your next step: set the date range, capture the baseline, and fill in the first five rows of the table.