How Do You Build a Monthly Content Calendar From Search Console Data?

How do you decide what to write next month without guessing?

Start from what Google already shows you for, not from what a keyword tool says you could rank for. Your Search Console data contains a list of queries where you are visible but under-performing, and that list is a better content calendar than anything you will brainstorm in a meeting.

I run this exercise once a month, and it consistently produces a better queue than a blank document does. The reason is simple. A query where you already earn impressions is a query where Google has decided your site is topically relevant. You are arguing about placement rather than about admission.

What follows is the whole process, using only Search Console and a spreadsheet.

Why should Search Console drive your calendar rather than a keyword tool?

Because it is the only dataset that describes your site specifically. A keyword tool tells you what the market searches for. Search Console tells you which of those searches Google has already connected to your pages, along with how often, in what position, and how many people clicked.

Google's documentation lists four metrics in the Performance report, which are clicks, impressions, click-through rate and average position. Those four together answer a question no external tool can answer, which is where you are currently losing. A page with impressions and no clicks is a different problem from a page with no impressions at all, and the fix is different in each case.

Keyword tools still have a place, and I use them for demand sizing on topics I have no presence in at all. But they should inform maybe a quarter of your calendar. The rest is sitting in a report you already have access to and probably open twice a year.

Which report and which settings do you start from?

Open the Performance report and set it up before you read anything. Google says you choose a dimension by selecting the appropriate tab above the table, offering queries, pages, countries, devices, search appearance and dates, and that you can change the date range or search type using the filters at the top.

The default view matters here. Google's documentation says the default view shows click and impression data for the past three months. Three months is a reasonable working window for a monthly calendar, long enough to smooth out a quiet week and short enough that you are looking at current behaviour rather than last year's.

Set search type to web unless you have a genuine reason not to, since image and video traffic behave differently and will distort your reading. Then switch to the Queries tab, sort by impressions, and export. That export is your raw material for everything below.

How do you find queries you rank for but do not deserve to yet?

Look for high impressions with a poor average position and a low click-through rate. That combination means Google keeps showing you for a search that people are performing, and people keep choosing somebody else. Each of those rows is a piece of content that exists in demand but not in quality.

I sort the export by impressions descending and then read down the average position column. Anything with meaningful impressions sitting outside the first few positions goes on a shortlist. The exact threshold depends on your site's scale, and I would rather you look at your own distribution than take a number from me that fits somebody else's traffic.

Then read the queries themselves, because this is the part no formula does for you. Some rows will be the same intent phrased five ways, which is one article. Some will be a question your existing page mentions in passing and never answers, which is a section. And some will be a topic you have no real business writing about, which is a row you delete.

How do you tell a new article from a refresh?

Switch the same filtered view to the Pages tab and see whether one of your pages already earns the impressions. If a page is already showing for the query, you have a refresh. If the impressions are spread thinly across several pages with none owning it, you usually have a new article and possibly a structural problem.

The thin spread case is worth stopping on. When three pages each pick up a fraction of the same query, you are competing with yourself, and publishing a fourth page makes it worse. That is a consolidation job rather than a writing job, and it belongs in a different queue. I have written separately about how to fix keyword cannibalisation on a Webflow site, and this report is where you find it.

For genuine refreshes, note what the query asks that the page does not answer. A refresh with no defined gap becomes a cosmetic edit, and cosmetic edits do not move anything. The content refresh workflow only works when each item arrives with a specific reason attached.

What do you do when the report will not show you enough rows?

Move to the API. Google's Search Analytics query documentation says the row limit has a valid range of 1 to 25,000 with a default of 1,000, which is a great deal more than most people ever pull. For a large blog, that difference is the difference between seeing your head terms and seeing your actual long tail.

You can group by country, device, page, query, search appearance, date and hour, which means you can ask questions the interface makes awkward. My most common request is queries grouped by page for a single country over one quarter, which gives me a per-page brief instead of a site-wide word cloud.

The filters are the other reason to go there. The documentation lists operators for contains, equals, notContains, notEquals, includingRegex and excludingRegex. A regex filter that excludes your own brand name removes the single biggest distortion in most Search Console exports in one step, and brand queries are not a content calendar.

How do you turn the list into an actual calendar?

Give every surviving row a page type, an owner and a month. Page type decides the shape of the work, owner stops it stalling, and a month forces prioritisation. A list without those three columns is a wish list, and wish lists do not get published.

I order by expected effort against current visibility rather than by search volume. A refresh on a page already earning impressions usually ships faster and moves sooner than a new article on a topic where you have nothing. Front-load the calendar with those, because early wins keep the process alive inside a company that is not yet convinced.

Keep the whole thing in whatever your team actually opens. A Google Sheet is fine. Airtable is better if you want status and automation on top. What matters is that the reason a row exists travels with the row, so the person writing in three weeks can see which query produced the brief.

What should you deliberately ignore in this data?

Ignore average position as a target, ignore anything with a single-digit impression count, and ignore brand queries entirely. Average position is a summary of many different results pages and moves for reasons that have nothing to do with your content. Chasing it directly produces work that feels productive and changes nothing.

Low-impression rows are the bigger time sink. There are always thousands of them, they are individually plausible, and collectively they will consume a quarter for almost no return. Set a floor, hold it, and revisit the floor next quarter rather than debating individual rows.

Also resist the pull towards reporting. The output of this exercise is a calendar, not a dashboard. If you want a standing view of performance, build it separately, and a monthly reporting view in Looker Studio is the right home for that. Keeping the two apart stops your planning session turning into a status meeting.

How often should you rerun this?

Monthly for the calendar, quarterly for the thresholds. A month is long enough for published work to start registering impressions and short enough that you are reacting to the current state of your site. Rerunning weekly mostly produces noise and a team that stops trusting the process.

What should change quarterly is your floor and your definition of a poor position. As a site grows, yesterday's interesting row becomes background, and a threshold that made sense at a hundred articles is wrong at a thousand. Write the current thresholds down so that the review is a decision rather than a vague feeling.

The discipline that matters most is closing the loop. When a piece ships, note the query it was built for, and look at that query next month. Without that step you are generating work rather than learning anything, and the point of starting from your own data was to learn.

What should you do next?

Open the Performance report today, set search type to web, leave the date range on the default three months, switch to the Queries tab and export it. That single export takes a few minutes and it is the entire input to this process. Everything after it is reading and deciding.

Then take your top twenty rows by impressions, classify each as refresh, new or consolidate, and stop. Twenty is enough to fill a month and small enough that you will actually finish the exercise. The most common failure here is trying to process the whole export in one sitting and abandoning it halfway.

Do it once and you will have a calendar built from evidence about your own site instead of a brainstorm. If you run a large blog and want a second pair of eyes on the export before you commit a quarter to it, reach out and I am happy to look.