Coverage matrices and gap decisions
Record what each page answers and what remains open.
A coverage matrix connects defined reader tasks to required answers, sources, examples and proposed page owners. It helps an editor see gaps, duplication and unresolved work. A filled row or an assigned URL is a planning record, not proof that the published answer is complete.
Free learning from Semantec SEO.
Define a node before counting coverage.
A node is a stable record for a bounded subject or reader task in the map. Give it an identifier, a plain task statement, relevant conditions and a boundary. “Inventory software” is a broad subject; “compare the stock records needed across two sites” is a task that can have inspectable answer requirements.
Do not count keyword variants as separate completed tasks by default. Different phrasings can share an answer, and similar phrasings can require different work. Record the grouping reason and revisit it when audience or source evidence changes.
A map can include broad orientation nodes and focused child tasks. Keep those levels visible. Publishing a hub that introduces a child does not establish that the child’s full method, example and evidence have been delivered.
Make the acceptance requirements inspectable.
For each node, list the questions and qualifications the answer must cover. Specify the example needed to show how the method works, the sources required for claims, the intended owner URL and any content block anchor. Add exclusions so a writer does not expand into unrelated work.
Separate a source requirement from a source obtained. A link in a brief does not prove that it supports a later claim. Record the relevant source scope, date, document version if applicable and unresolved conflicts.
Use a named reviewer and explicit state. Proposed owner, drafted, reviewed and published describe different facts. Topical acceptance should identify which requirements are met and which remain open, even when the page itself is already live.
| Record field | Question it should answer |
|---|---|
| Node ID and definition | What bounded task is being tracked? |
| Required answers | Which explanations and qualifications must be present? |
| Sources | What supports the factual claims, and what is missing? |
| Worked example | Can the reader see the method applied to a concrete case? |
| Owner and anchor | Where is the maintained answer located? |
| State and omission | What has been observed, what remains open and who checks next? |
Worked example: ten nodes, four candidate pages.
A fictional website teaches the planning of an inventory system review. The ten nodes and four page roles below are invented for this lesson. They do not describe a real software product, client project, search study or measured business result.
The editor proposes four candidates: A introduces the review process, B defines the requirements record, C explains comparison and exceptions, and D explains migration preparation. These are proposed editorial roles, not claims that four live pages already exist.
Assign each node to a main answer location, then inspect the draft against its requirements. In the example, some nodes have sufficient draft material, some need research or examples, and one lacks a confirmed owner. This is a more useful result than marking ten assigned rows complete.
| Node | Bounded task | Candidate owner | Observed state in this fictional review | Open requirement |
|---|---|---|---|---|
| N01 | Learn about the review process | A: overview | Draft explanation present | Independent review |
| N02 | Identify the people using stock records | B: requirements | Draft explanation present | Check example roles |
| N03 | Record item and movement data | B: requirements | Draft with missing source | Obtain suitable data definitions |
| N04 | Record location requirements | B: requirements | Draft explanation present | Check cross location qualification |
| N05 | Set comparison criteria | C: comparison | Draft explanation present | Independent review |
| N06 | Handle unusual item or unit cases | C: comparison | Incomplete | Add a worked exception |
| N07 | Check product specific connections | C: comparison | Research needed | Verify current named product facts |
| N08 | Prepare existing data for migration | D: migration | Outline only | Write supported steps and example |
| N09 | Assign migration responsibilities | D: migration | Draft explanation present | Confirm accountability boundaries |
| N10 | Review unsupported legacy cases | No confirmed owner | Unresolved | Define task and choose owner |
Reconcile the counts without hiding unfinished work.
The matrix has ten nodes and four proposed pages. Nine nodes have candidate owners; N10 does not. That is ownership coverage in the plan, not nine complete answers. The table also shows missing research, a missing exception example, an outline and pending independent checks.
For each candidate, read the full draft and point to the content that meets each requirement. If a paragraph merely names an exception, do not count it as an explained method. If a table lists a source but no claim has been checked against it, keep the research state open.
A draft can cover more than one node if it answers each task clearly and preserves the required context. Also, assigning one page per node does not prove a better structure. Use task boundaries, evidence and navigability to choose the grouping.
Classify omissions before adding pages.
An omission can be a missing answer, absent example, unsupported claim, unassigned owner, broken route or an intentionally excluded task. Each needs a different action. A missing example can be added within the existing owner when it supports the same task.
Record deliberate exclusions with reasons. A product specific question may be outside a general educational site’s scope, or a business may not offer the service a query implies. Do not invent facts or a local offer to make the matrix look complete.
Keep contested requirements visible. If sources conflict or the audience task is not established, record the unresolved question and its next research step. Replacing an unknown with “not applicable” requires a defensible scope reason, not a desire to close a row.
Prioritize work from dependencies and reader need.
Start with defects that prevent a reader completing the main task: a false claim, absent prerequisite, missing owner or inaccessible answer. Then address missing worked examples, unclear distinctions and navigation gaps. Use the website purpose and available evidence to set the order.
A map does not need a universal numerical completeness score. If the project uses counts, name exactly what is being counted: nodes defined, owners proposed, drafts inspected or requirements accepted. Keep the denominator and exclusions visible.
Do not infer commercial demand, search volume or conversion benefit from the number of gaps. Those conclusions require their own evidence. The matrix is an editorial control for coverage, not a measurement of audience size or ranking potential.
Review the matrix against the current website.
Use stable node identifiers and current page records. Recheck the current owner, required content, links and public route after revisions. Keep the source evidence and review attached to the version inspected; a later layout or content change can invalidate affected checks.
Track page publication separately from the acceptance of each node. A published overview can remain incomplete for a focused task. A completed draft is still unpublished until the current release is verified. This separation prevents a green publication row from being mistaken for full branch acceptance.
Google’s helpful content questions supply broad audience and purpose checks. The node fields, example counts and review states here are editorial methods, not a Google coverage metric.
Use topic ownership to resolve candidate owners and page roles to organize related resources. Return to the topical mapping overview or the learning overview.