Editorial Calendar Template with Topic Ownership Sheet

A calendar tells a team when to publish; it does not tell the team whether the topic already has a home. The fix is a topic ownership sheet that runs next to the calendar: one row per topic, one named owner, one target query and one canonical URL, checked before any new idea is scheduled. Blog editors, SEO leads and agency content managers who coordinate more than one writer are the people this setup is built for.

The sections below cover why calendars miss overlap, how to lay out the sheet, how a new idea gets approved, how to keep three separate dates honest, and how the team runs the whole thing week to week. A shared spreadsheet is enough; no special software is needed.

Why a calendar alone lets duplicates through

What a calendar cannot see

A calendar is organised by time. Its columns say who writes what, which week the draft is due and when the post goes live. Two posts that answer the same question can sit in different weeks without any visible conflict, because the calendar never asks what each post is about in a way that can be compared. Overlap appears only when someone reads both posts side by side, and by then both are live.

The topic sheet changes the unit of planning. Instead of a date, the row is a question a reader asks. Before a date is assigned, the question must be unique or must be deliberately different in intent from the questions already on the sheet.

Example scenario: a regional outdoor gear retailer

Example scenario: A regional outdoor gear retailer runs a blog with three contributors. One wrote a guide to choosing a winter sleeping bag two years ago. A newer contributor pitches "how to pick a sleeping bag for cold nights" and the calendar happily accepts it for the third week of next month. On the sheet, the older row shows the same reader question, the same intent and a last substantial update that is two winters old. The editor's decision is to refresh the older guide and give the new contributor a different angle, such as a packing checklist for a first winter camping trip, linked to the guide. The sheet turned a duplicate into two complementary pages.

Questions to ask before approval

The last question follows a warning in Google's helpful content guidance, which lists producing lots of content on many different topics and entering a niche without real expertise among the things to avoid. The sheet cannot create expertise, but it makes a gap visible before a draft is written.

Designing the sheet: one row per URL

Three groups of columns

Rather than a flat list of fields, think of the sheet as three groups. The identity group says what the page is. The ownership group says who is responsible. The lifecycle group says where the page is in its life. Keeping the groups visually separate, for example with colour bands in the header, helps new people read the sheet quickly.

Owner means accountable, not exclusive

An owner is the person accountable for one authoritative page staying accurate. It does not mean nobody else may write about the subject. Other writers can propose related pieces; the owner decides whether a proposal extends the existing page, becomes a separate linked page or is declined because the intent is already served. If the sheet allows a team name in the owner column, accountability evaporates, so insist on an individual.

Google's helpful content page (Opens in a new tab) asks whether it is self-evident to visitors who created the content and whether bylines are present where readers might expect them. A "byline page present" column makes that check routine. The same page warns against fabricated creator profiles such as made-up names or false credentials, so the name on the sheet and on the page should belong to a real person.

The target query column

The purpose of this column is collision detection. Enter one primary phrase per row and, optionally, one or two close variants. When a phrase is primary on one row and a variant on another, the sheet is warning you that two pages may be competing for the same search. Search volume and difficulty figures, if you keep them, come from a separate tool and are estimates; label them as such. A blank cell is better than an invented number.

For checking collisions that already exist on the live site, the guide on detecting keyword cannibalization walks through the diagnostic side. The sheet prevents new collisions; the diagnostic finds old ones.

A worked row

Example scenario: take the sleeping bag guide from the retailer above. Its topic cell reads "How do I choose a sleeping bag for winter camping?" The intent cell says "decision help before purchase". The primary query cell holds one phrase and the variant cell holds one close wording. The canonical URL cell holds the guide's address. The owner is a named contributor, the reviewer is the editor, and the byline page is marked present. Status is "needs update" because the last substantial update is two winters old, volatility is "medium" because gear specifications change slowly but product examples date, and related pages lists the packing checklist that the newer contributor will write. One row, read in ten seconds, answers who, what, where and when.

The related pages column in practice

Related pages is easy to leave empty, yet it is the column that makes merges safe. When two pages are merged, every page that linked to the retired address needs its link updated. If each row lists its neighbours, that cleanup is a lookup instead of a crawl. The column also drives internal linking for new posts: when a post goes live, the author opens the rows of its neighbours and adds a contextual link to the new page. Keep the list short, and remove entries when a neighbouring page is merged or retired.

The pitch gate: how a new idea gets approved

Five steps before an idea reaches the calendar

1. Search the sheet for the topic wording and the target query. Writers phrase the same idea differently, so look in both columns.
2. Search the live site as well. Old posts, migrated pages and material written by another team may not be on the sheet yet.
3. Compare the first paragraph of each close match with the pitch. If the answers read almost the same, the pitch overlaps.
4. Choose a path: extend the existing page, shift the pitch to a different intent, or drop it.
5. Record the decision and the reason in the notes cell so the same pitch does not return next quarter.

The whole check should take minutes, not hours. If it takes longer, the sheet is missing information, and that is itself a finding worth fixing.

When two pages already compete

Google's documentation on consolidating duplicate URLs describes three ways to signal a preferred page: redirects, the rel="canonical" link annotation and a sitemap. According to that page, a redirect is a strong signal that the target should become canonical, rel="canonical" is also a strong signal, and a sitemap is a weak one. The page adds that the methods can be combined for more effect, that none of them is required, and that robots.txt should not be used for canonicalization. It also says Google decides which pages are duplicates based on similarity of content, so the choice is ultimately Google's. The full explanation is in Google's page on consolidating duplicate URLs (Opens in a new tab).

Practical suggestion: when two of your own pages serve one intent, pick the stronger one as the canonical page, move whatever is valuable from the weaker one, and redirect the weaker address. Weigh the strength using publication history, the last substantial update and the links the page already receives. Afterwards mark the old row "merged" and note the new canonical URL; keep the row so the history is not lost.

Decision rule

Dates that do not lie

Three dates, three meanings

One date column cannot carry three meanings. The first published date is the day the page first went live and never changes. The last substantial update is the day the content last changed in a way that matters to a reader. The next review is the day someone will look at it again. Keeping them apart answers two different questions: how old is this page, and when should we look at it.

What counts as substantial

Google's helpful content guidance asks whether you are changing the date of pages to make them seem fresh when the content has not substantially changed. That question is the reason to label the column "last substantial update". Fixing a typo or a broken link does not qualify. Adding a section, rewriting an outdated step or replacing a table with current data does. Write this rule at the top of the sheet so anyone filling it in applies the same test.

The same guidance flags removing a lot of older content primarily because you believe it will help search rankings, and notes that it will not. For that reason a review should not end in a reflexive delete. Update, merge or redirect first. The guide to refreshing old blog posts covers the update mechanics.

Review rhythm by volatility

Not every page deserves the same review rhythm. A page that describes pricing, regulation or a software interface changes often; a page that defines a concept changes rarely. A volatility column with high, medium and low values lets each row carry its own review date. No fixed interval is given here because the right one depends on your sector; start with an assumption, run it for a quarter and adjust.

Data can move a page up the queue

A scheduled review is not the only trigger. If traffic or impressions for a page decline, the page should jump the queue. The article on finding articles that lose traffic shows how to spot those pages. A "performance note" column gives that signal a place to land, so the owner sees that the page entered the queue because of data, not because the calendar said so.

Running the sheet as a team

A short weekly pulse and a longer monthly review

Two rhythms keep the sheet alive. The weekly pulse is a ten-minute pass over new pitches: each one goes through the five-step gate and leaves with a decision. The monthly review is longer and works through the sheet itself. A workable agenda: reassign rows with no owner, read the overlap notes from the past month, decide on every page whose review date has arrived, finish the redirects and canonical changes agreed earlier, and only then fill next month's calendar from the approved ideas.

The agenda deliberately puts the calendar last. The calendar is an output of the gate, not an input to it. A team that fills the calendar first notices overlap only after drafts exist.

Example scenario: an agency with rotating freelancers

Example scenario: A content agency manages blogs for several clients and uses freelancers who change from month to month. Every client has its own sheet. When a freelancer is briefed, the editor sends the row for the assigned topic together with the related pages cell and a handover note. The note names the reader question, the sections that age fastest, the sources the page relies on and the pages it must not duplicate. When the freelancer leaves, nothing about the topic leaves with them, because the knowledge sits in the sheet.

Handover note fields

Settling disputes

When two writers want the same topic, three criteria decide: closest expertise, who owns the existing page and previous published work on the subject. If they tie, the editor assigns the topic to the writer with the lighter load and makes the other writer the reviewer. Write the reasoning in the notes cell. A recorded reason ends a debate that would otherwise return every few months.

Views and filters

One sheet can serve different roles through saved filters. The editor filters by status to see rows with no owner or marked to merge. A writer filters by their own name. The SEO lead sorts by primary query to see duplicated phrases. Everyone works from the same data, so the views never disagree. Copying the data into a second file is the first step towards a stale sheet.

Reading Search Console alongside the sheet

Search Console data is a useful companion to the sheet because it shows which queries a page actually appears for. If a page appears for queries that belong to another row, the sheet and the live behaviour disagree, and the disagreement is worth a conversation. This is a diagnostic habit, not a rule: Google's documentation does not say that an ownership sheet changes how queries are matched, so use the data to ask questions and the sheet to record the answers.

When the data suggests that two pages share queries, return to the decision rule. Often the right answer is to sharpen the intent of one page, for example by making a guide more decision-oriented and a checklist more procedural, rather than merging them. Write the sharpened intent in the intent column so the difference is explicit for the next writer.

Quarterly clean-up of the sheet itself

Once a quarter, the sheet needs maintenance of its own. Check that every canonical URL still resolves to the page it names, that merged rows point to a live address, and that no row carries a status that has not changed for several review cycles. A row stuck at "on hold" for a long time deserves a decision: either an expert has been found, or the topic is retired from the plan. Closing these loops keeps the sheet from becoming a graveyard of intentions.

Pitfalls and the first ninety days

Common failure patterns

Month one: skeleton and inventory

The first month is about getting a usable sheet, not a perfect one. Fill it from a content inventory, keeping only the identity and ownership columns at first. The content audit guide explains how to build that inventory. Every URL becomes a row. Apply the gate to new pitches immediately, and merely flag, rather than solve, the overlaps you discover in old content.

Month two: resolving flagged overlaps

The second month works through flagged overlaps with the decision rule. Each monthly session closes a few merges and updates the status column. The target query column matures, and writers begin to reject their own duplicate pitches before they reach the gate.

Month three: lifecycle columns and health checks

In the third month the volatility column and review dates go live. Three health questions can now be compared with the previous month: how many pitches skipped the gate, how many rows changed owner, how many topics remain with nobody accountable. Trim the sheet accordingly. Remove columns that nobody uses, and add one only when a recurring decision lacks the information.

What the sheet does not promise

Nothing in Google's documentation links an ownership sheet to rankings. The sheet is an internal quality control: it reduces duplicate pages, keeps the right people accountable and makes updates deliberate. Treat any change in search performance as something to be investigated in Search Console, not as proof that the sheet works.

Frequently Asked Questions

Is an editorial calendar the same as a content calendar?

In everyday use the two names describe the same planning tool: a schedule of what is published, when and by whom. The difference that matters is between a calendar, which manages time, and a topic ownership sheet, which manages the content itself. Teams that want to prevent overlap keep both.

Does a small team need a topic ownership sheet?

Even a single writer can forget an older post. A small team can shorten the sheet to topic, primary query, canonical URL, publication date and last substantial update. Add owner and status columns as the team grows.

Which of two overlapping pages will Google pick?

According to Google's page on consolidating duplicate URLs, Google decides which pages are duplicates based on similarity of content and identifies the version that is objectively best to show users. Redirects and rel canonical are strong signals and a sitemap is a weak one. The documentation does not guarantee which page will be chosen.

Should I change the publication date when I update a post?

Leave the first published date alone and track the last substantial update separately. Google's helpful content guidance questions changing the date of pages to seem fresh when the content has not substantially changed. Refresh the update date only when the content really changed.

Is deleting old overlapping posts the answer?

Weigh updating, merging and redirecting first. Google's helpful content guidance lists removing a lot of older content primarily because you believe it will help search rankings and notes that it will not. A deleted page also takes its links and readers with it.

What tool should the sheet live in?

A shared spreadsheet is enough. What matters is that it is the single source of truth and that everyone reads the columns the same way. If you switch tools, carry the column definitions across.

Conclusion

A calendar sets the publishing order; a topic ownership sheet decides whether a topic should be published at all. Give every topic a named owner, a primary query and one canonical URL. Run each new idea through the five-step gate before it earns a slot. Track first published, last substantial update and next review as three separate dates, and walk the sheet in the same order every month.

If you want expert help turning approved topics into finished articles, take a look at our content writing service.