A content tracker is often mistaken for an editorial calendar with a few extra columns. That may be enough to plan titles and due dates, but it is not enough to manage a publishing handoff.
A publishing team needs to answer a different set of questions: Which source was approved? Where is the WordPress draft? Who can move it forward? Has the public page actually been checked? If the tracker cannot answer those questions from one record, people will fill the gaps with messages, assumptions, and duplicate sheets.
The term content tracker can cover many jobs. This guide focuses on the operational question that comes before a publishing item is complete: “Who must approve this CMS draft, and what must happen before this item is complete?” It does not treat a transferred draft, a WordPress status, or a planned URL as proof that a page has been approved, released, or verified.
What a content tracker must tell a publishing team
Define the tracker’s job before choosing a template, spreadsheet, or platform. Its job is not to hold every piece of editorial information. Its job is to make the next publishing decision visible.
For each item, a useful tracker should let a coordinator determine:
- the authoritative source document or exported file;
- the destination site and intended content location;
- the CMS draft that is being reviewed;
- the current approval state and the person responsible for the next move;
- any unresolved exception that prevents release; and
- whether the live URL has been checked after publication.
A title, publish date, and broad status such as “in progress” do not establish those facts. “In progress” might mean the writer is revising a source document, an editor is reviewing a WordPress draft, or a publisher is waiting for a missing image. Those are different situations, with different owners.
Keep later reporting separate unless the same system can support it without obscuring the handoff. A publishing record can include a later analytics link or reporting date, but it should not replace the fields needed to make a release decision. An approved draft may have no reporting data because it is not live, while a live page may still need a correction or verification check.
The practical unit of work is one publishing item, identified consistently from assignment through live-page verification. For a recurring article series, do not reuse an old record merely because the title is similar. Create a new item ID for each distinct release.
Approval states, owners, and exceptions
A status becomes useful when it tells the team what has passed, what is still required, and who has authority to act next. Avoid labels such as “done” until you define whether they mean source complete, draft created, approval received, page released, or live page verified.
Use a small number of states with a stated pass condition. The following sequence is a starting point for a publishing content tracker:
| State | Meaning | Next owner | Pass condition for moving forward |
|---|---|---|---|
| Drafting | The source is being written or revised. | Writer or editor | The source is ready for the required editorial review. |
| Awaiting review | The source is submitted for a decision. | Editor, client approver, or subject-matter reviewer | The required reviewer records approval or returns a specific change request. |
| Approved for CMS QA | The source is approved for destination preparation; it is not yet release-approved. | CMS QA owner | A CMS draft exists and required source-to-draft checks are complete. |
| Ready to publish | CMS QA is complete and no release-blocking exception remains. | Publisher or release owner | The assigned release owner confirms the item may be released on the intended site. |
| Live—verified | The public page has been checked after release. | Live-page verifier | The public URL, expected content, key links, images, and relevant release settings have been checked, with no open blocking exception. |
Add approval owner, next owner, and release owner as separate fields when one person may hold more than one role. The approval owner decides whether the content is acceptable. The CMS QA owner checks the destination draft. The release owner controls publication timing. A single person can do all three on a small team, but the tracker should not rely on that being assumed.
An exception field turns a vague blockage into a manageable task. Record four pieces of information:
- Exception: what differs from the expected result;
- Impact: whether it blocks publication or can be resolved later;
- Assignee: the person responsible for resolving or accepting it; and
- Next check date: when someone must confirm progress.
For example, “featured image is missing” is incomplete. A useful record is: “Featured image supplied in CMS is an outdated product screenshot; blocks publication. Assignee: Priya, asset owner. Next check: 15 May, 14:00.” The CMS QA owner can then keep the record out of Ready to publish without guessing whether the image is optional.
For workflows that begin with page-level audit findings rather than new content, see our guide to agency content audit tools.
Fields that connect a content item to its source, CMS draft, and live URL
The most important distinction in a content tracker is between three locations that are often collapsed into one generic “link” column:
- Source document: the working or approved editorial source, such as a document in the team’s storage.
- CMS draft: the private WordPress record where the content, metadata, and layout are prepared for the destination site.
- Live page: the public URL that readers can access after release.
A CMS draft link proves that a draft exists. It does not prove the copy is approved, the page is published, or the live page has passed QA. Likewise, a source-document link identifies the material under discussion but does not tell the reader where it was transferred.
Use this field map as a starting point. It is an editorial control template, not a universal product standard.
| Field | What to record | How the field is used |
|---|---|---|
| Item ID | A stable internal reference, such as ACME-047 | Lets the team refer to one item even if its title changes. |
| Working title | Current editorial title | Helps people recognize the item; it is not the primary identifier. |
| Client or site | Client name plus destination site identifier | Prevents a draft for one site from being confused with an item for another. |
| Source-document link | Link to the identified source and, where useful, its revision date | Gives reviewers a defined comparison point. |
| CMS draft link or ID | WordPress edit link or post ID | Lets the QA or publishing owner find the private destination record. |
| Intended destination | Post type, section, or other agreed location | Makes the intended use of the draft explicit before release. |
| Live URL | Public canonical page URL | Remains blank until the page is published and the URL is known. |
| Last updated | Date and time of the latest meaningful tracker change | Helps coordinators find records that need follow-up. |
The live URL should remain blank while an item is drafting, under review, awaiting CMS QA, or merely scheduled. Filling it with a guessed slug makes an unconfirmed destination look like a completed release. If a team needs to retain an expected permalink, add a separate planned URL field and label it as planned.
For multi-site teams, the site field must be more specific than a client name. One client may have a main site, regional site, staging environment, or distinct WordPress properties. Record the particular destination that the CMS draft belongs to.
Tenwrite can fit the location-visibility part of this process because its content index lets users view and manage content across multiple sites. It also supports exporting MS Word DOCX files in Google Drive to WordPress and Blogger. Those capabilities can help a team locate content and move a source into a destination, but the tracker should still record the resulting draft, its approvals, and its live-page verification separately.
Sample record before and after publication
The same item should gain evidence as it progresses rather than becoming a new row at every handoff.
| Field | Before publication | After verification |
|---|---|---|
| Item ID | NB-042 | NB-042 |
| Client or site | Northbank / northbank.example WordPress | Northbank / northbank.example WordPress |
| Source-document link | Q3 onboarding guide — revised 14 May | Q3 onboarding guide — revised 14 May |
| CMS draft link or ID | WordPress post #1842 | WordPress post #1842 |
| Intended destination | Resources / standard post | Resources / standard post |
| Live URL | Blank | https://northbank.example/resources/q3-onboarding-guide/ |
| Last updated | 14 May, 10:30 | 16 May, 15:10 |
A worked handoff from draft to verified live page
The following is an illustrative record for a fictional WordPress article. It shows why a tracker needs both status and exception data.
Item: NB-042, “Q3 Onboarding Guide”
Site: Northbank / northbank.example WordPress
Approval owner: Mara, client editor
CMS QA owner: Leon, publishing coordinator
Release owner and live-page verifier: Inez, WordPress publisher
Start with a recorded decision, not an assumed one
Mara approves the identified source document on 14 May. Leon creates WordPress post #1842 as a draft and enters that edit link in the tracker. The record moves from Awaiting review to Approved for CMS QA.
That move means the source has a recorded editorial decision and a destination draft exists. It does not mean the page can be published. Leon opens both the WordPress editor and its preview, checking the article title, headings, body, internal links, featured image, excerpt, and any required destination fields against the approved package.
Keep the record blocked until the exception is resolved
The text and links pass, but the featured image in the preview is an outdated product screenshot. Leon records the following exception:
| Exception | Impact | Assignee | Next check date | State |
|---|---|---|---|---|
| Featured image is outdated; replacement asset required | Blocks publication | Priya, asset owner | 15 May, 14:00 | Approved for CMS QA |
The tracker does not move to Ready to publish. A generic “QA complete” label would conceal the one issue that still prevents the release.
On 15 May, Priya replaces the asset and Leon confirms in the WordPress preview that the new image is attached, displayed as expected, and has the agreed alt text. He marks the exception resolved, adds the resolution date, and moves the item to Ready to publish. Inez is now clearly responsible for the next action.
Treat publication and verification as separate events
Inez publishes the post on the intended WordPress site. She enters the actual public URL rather than copying a planned slug. The record is not complete yet: it is live, but it has not been verified.
Inez opens the public URL and checks that it resolves to the intended article, shows the expected title and headings, displays the corrected image, and has working key links. She also confirms there is no unresolved tracker exception. Only then does she change the state to Live—verified and update the timestamp.
This distinction protects against a common false completion: seeing a published status in WordPress and assuming the public page is correct. The tracker’s completion rule is explicit: an item is complete only when the required live-page checks pass and every release-blocking exception is resolved or formally accepted by the person with authority to do so.
How to evaluate a spreadsheet or tool against the workflow
A spreadsheet can be sufficient when a small team has a limited number of items, one or two sites, stable handoffs, and a clear person responsible for keeping the record current. It is not inherently less controlled than a tool; a well-designed sheet with disciplined updates can make ownership and exceptions visible.
Manual upkeep becomes a concern when people cannot reliably locate the current row, source, or CMS draft; when several sites use different rules; or when a coordinator spends more time reconciling duplicates than managing the work. At that point, evaluate a tool by whether it preserves the record your publishing process needs—not by the length of its feature list.
Run a short two-item trial using real but low-risk handoffs. Choose two items for different sites, preferably with a difference that matters to your process, such as distinct approvers, categories, or image requirements.
The two-item trial
For each item, enter the complete field map: item ID, site, source link, CMS draft link or ID, intended destination, live URL field, state, owners, exception, and last-updated date. Then carry out these checks:
| Test | Pass | Fail |
|---|---|---|
| Locate the correct source | A reviewer opens the identified source without asking which version to use. | The record has multiple possible sources or no defined revision. |
| Locate the correct CMS draft | The CMS QA owner reaches the relevant private draft for each site. | A link points to the wrong site, a generic dashboard, or no draft. |
| Assign a reviewer | Each item shows who must make the next editorial decision. | “Waiting for approval” appears with no named owner. |
| Flag one exception | One item records a concrete blocker, assignee, and next check date. | The issue lives only in email or chat, or has no accountable owner. |
| Distinguish release from verification | The released item has a public URL and a separately recorded live-page check. | Publishing automatically turns the record into “complete.” |
| View the two sites together | A coordinator can identify the site, state, and next owner for both items without merging duplicate records. | Site-specific records are ambiguous or require manual reconstruction. |
Treat any failed required check as a workflow problem to solve before wider adoption. It may be a missing field, a permissions issue, an unclear ownership rule, or a tool limitation. Do not work around it by telling people to remember the missing information elsewhere; that recreates the fragmented handoff the tracker is supposed to prevent.
For a broader view of publishing-tool criteria beyond the tracker itself, see our framework for evaluating publishing tools. The tracker is the coordination record; other tools may handle transfer, editing, review, or release.
Start with the field map in this article and trial it on two real publishing handoffs. If you need to view content across multiple sites or move supported Google Drive DOCX files toward WordPress or Blogger, Tenwrite may help with the content-location and transfer portion of the process. Keep the approval, CMS QA, exception, and live-page verification fields in view until each handoff has a clear, accountable outcome.