A practical website process

Topical Map Process: From Research to Website Review

A topical map is useful when its decisions shape the pages people use. To learn how to create a topical map, follow one small hypothetical service website from its business facts through research, briefs, public review and maintenance.

Carry the decision from research into the published page. Keep facts, responsibilities and remaining uncertainty visible at every stage.

Free learning from Semantec SEO.

Planning folio, reference cards and website page beside folders, a magnifying glass and pencil.

Follow one preparation task through seven stages

The same stable record, W02, follows the preparation task throughout this example. Its reader task survives changes in draft wording and layout. Every stage records an input, an output and the person responsible for the next decision.

This is a Semantec SEO editorial process. The furniture workshop, its records and proposed decisions are fictional. No real business, audience research, published workshop website or measured outcome is represented.

Confirm the project.
Input: the proposed workshop goal and available inventory. Output: W02 scope record. The proposed task is preparing an assessment request; service area, information requirements, contact process and the named fact owner remain unknown. Responsible actor: the workshop decision maker, with a named person to be recorded in a real project.
Research the preparation question.
Input: confirmed scope, permitted reader questions and appropriate sources. Output: W02 research record, carrying the synthetic question “What information should I gather before requesting an assessment?” No customer research is supplied; the required information awaits business confirmation. Responsible actor: the researcher; the business fact owner confirms its own process.
Assign the answer owner.
Input: the question, existing pages and neighboring tasks. Output: W02 ownership decision, pending review of the complete existing service answer. A short preparation summary can remain in W01; a separate preparation resource needs a distinct supported task. Responsible actor: the content planner.
Write the brief.
Input: the accepted task and evidence. Output: W02 brief, with the reader, promise, required answers, fact owner, illustration purpose, limits, next action and acceptance checks retained. Unconfirmed request requirements stay open. Responsible actor: the editor.
Draft and illustrate.
Input: the brief and approved factual material. Output: W02 draft P1, a proposed explanation linked to the brief and its evidence. Instructions awaiting business confirmation remain unwritten; no publication status is implied. Responsible actors: the writer and designer, with fact confirmation retained.
Check the saved public version.
Input: the accepted candidate and saved page. Output: W02 public review record, marked not performed in this example. Public URL, saved version, reviewer and test observations remain unknown; no release is certified. Responsible actors: the site operator and reviewer.
Measure and maintain.
Input: an agreed question, permitted observations and later changes. Output: W02 maintenance record, with changed request requirements or contact details named as review triggers. A published version and measured outcomes remain unknown. Responsible actor: the named measurement or maintenance owner.

Confirm the project and inventory before researching

Imagine a local furniture repair workshop planning a clearer website. This is an invented process example. It contains no verified business offer, customer findings or measured search results.

The proposed goal is to help visitors assess the confirmed work and request an assessment. The workshop must supply its service scope, area, contact process and any conditions. The writer should not infer qualifications, prices or repair outcomes.

Inventory the existing pages and useful media. Record the current destinations before proposing replacements. Identify who confirms facts, who writes, who changes the website and who approves release. The plan needs real responsibilities rather than an assumed general owner.

Furniture joint samples, folded navy fabric, a blank service record and two page cards.

Keep the existing destination separate from the planned action

For W02, the current owner URL is UNKNOWN because no real workshop inventory is supplied. The proposed action is to inspect the service page and decide if a preparation explanation needs its own destination. That is a planning decision, not evidence that a new URL already exists.

Required business inputs: Confirmed service scope, area, contact process, conditions and any limits on the information supplied by a visitor.
Inventory inputs: Current URLs, useful passages, media identities, publication rights, existing request routes and the date each item was checked.
Accountability: Name the person confirming business facts, the researcher, editor, site operator and release reviewer. The example names responsibilities; it supplies no real staff identities.
Output: A scope record, an unchanged inventory reference and a list of facts that must be confirmed before their dependent instructions can proceed.

Use the source context record to make the business and audience boundary explicit before expanding the topic list.

Research questions and label their evidence

Collect available customer questions, business records and appropriate original sources. If query or result research is carried out, record its date, market and limits. A missing estimate should stay missing rather than becoming an invented zero.

Separate the topic from the reader task. “Furniture repair” can lead to learning about a service, comparing choices or requesting work. Decide which questions share a useful answer and which require different evidence or actions.

For the example, propose a service page, a preparation explanation and contact information. A repair versus replacement comparison remains conditional on obtaining reliable subject evidence. Record that dependency rather than treating every idea as ready.

Google’s helpful content documentation supports starting with an intended audience and a useful goal. It does not prescribe this exact page set.

Content page sheets grouped under topic divider tabs on a planning folio.

Keep the observation and its interpretation in separate fields

A research record should retain the exact question or query, its source, collection date, country, language, dataset and returned metric. Add the proposed task and a separate uncertainty note. A constructed question is an editorial suggestion until real evidence establishes its origin.

A relevant phrase can deserve investigation when a provider reports zero. Keep that returned zero unchanged. If a project uses an interpretation such as 0–9, label it separately. A missing report or missing estimate remains UNKNOWN; it cannot become zero or a result claim.

In this workshop example, no customer question, query volume or result study has been measured. The preparation question is a synthetic lead: “What information should I gather before requesting an assessment?” Its purpose is to show how an editor records an unanswered task.

The researcher asks the workshop to confirm the information needed, permitted ways to supply it and the limits of an initial assessment. The output is a source record attached to W02. Unsupported instructions wait for that confirmation. Use candidate topic discovery when collecting and reviewing the leads that enter this process.

Group tasks and assign an answer owner

Compare the required answer, audience, conditions, evidence and next action before grouping phrases. Learning what the workshop can assess, gathering information and sending a request share a subject but each asks the page to do different work.

A short preparation summary can complete the service task locally. A fuller preparation resource needs a distinct useful answer and enough evidence to support it. Compare those possibilities against the complete existing page before assigning another URL.

The repair versus replacement comparison remains pending because the record lacks reliable subject criteria and qualified review. Its place in the map preserves the unanswered question without presenting a speculative comparison as ready.

Use query grouping to compare shared answer needs and page and content block decisions to choose their content boundary.

Three page records with a chair, folder and envelope are grouped beside a separate card.

Record the map as decisions rather than a topic list

These four complete records keep the stable node, task, relationship, current owner, proposed action, evidence, prerequisites, review state and next route together. All workshop URLs remain unverified; no fictional route is presented as a working link.

A parent relationship describes meaning or navigation. A nested URL alone does not establish a prerequisite. Record the information that would be missing if a dependency were removed, then name the source and person who can resolve it. The content dependencies lesson covers that decision in more detail.

W01 · Service explanation

Reader task: Identify which furniture work the workshop can assess and how to request that assessment.
Parent relationship: Main service task; W02 supplies preparation context and W03 provides the request route.
Existing owner URL: UNKNOWN. This fictional example supplies no verified live workshop inventory.
Proposed action: Review the existing service page first. Improve that owner if suitable; create a page only if no existing owner can answer the task.
Evidence: Workshop service scope, area, conditions and request process must come from the designated business fact owner.
Prerequisites: Verify the offered work and a usable request destination before accepting service claims.
Review state: Proposed; factual inputs and current route remain unconfirmed.
Next route: Explain W02 beside the request instructions; offer W03 when the visitor has the required information.

W02 · Prepare an assessment request

Reader task: Find the information the workshop needs before it can assess a proposed furniture repair.
Parent relationship: Supports W01. Its distinct preparation task is retained while the final page or content block boundary is reviewed.
Existing owner URL: UNKNOWN. No current preparation page or passage has been verified in this invented project.
Proposed action: Compare the complete preparation answer with W01. Keep a short local summary and use a distinct resource only if the fuller task justifies it.
Evidence: The workshop must confirm required descriptions, acceptable media, permission needs and any limits on remote assessment.
Prerequisites: Confirm what information can be requested, how it is supplied and which person receives it.
Review state: Proposed; brief can record open questions, while unsupported request instructions wait.
Next route: W03 after its request requirements and destination are confirmed; return to W01 for service scope.

W03 · Request an assessment

Reader task: Use the confirmed contact process and learn what happens after sending a request.
Parent relationship: Action route serving W01 and W02; it does not replace their explanations.
Existing owner URL: UNKNOWN. The example contains no working contact form, email destination or booking system.
Proposed action: Inspect and reuse the verified request route. Add clear requirements and the confirmed next step.
Evidence: Business confirmation of the receiving contact, required fields, privacy information and response process.
Prerequisites: A real supported contact service and authorization for any test that would send a message.
Review state: Proposed; no submission, delivery, assessment or appointment is claimed.
Next route: Explain the business’s confirmed acknowledgement and follow up process once confirmed.

W04 · Repair or replacement comparison

Reader task: Compare relevant repair and replacement considerations for the furniture and circumstances involved.
Parent relationship: Related decision task; the evidence requirement differs from the service and request tasks.
Existing owner URL: UNKNOWN. No existing comparison owner has been inspected in the fictional workshop.
Proposed action: Defer drafting a recommendation until suitable subject evidence and qualified review are available.
Evidence: Reliable criteria, applicable conditions and an accountable specialist; prices and outcomes remain unknown.
Prerequisites: Obtain the evidence needed for the comparison, including limits and circumstances that change the answer.
Review state: Pending evidence. A position in the map does not make this comparison ready to publish.
Next route: Offer W01 only when its confirmed service scope fits the reader’s circumstances; preserve alternatives fairly.

Write briefs that carry the source and the route

For each proposed page, record its audience, purpose, required answers, evidence, example, limits and next route. Keep the existing URL and proposed action in separate fields so the team can distinguish a revision from a new page.

The service brief should explain what can be requested, what information the visitor needs to supply and what happens after the request. A preparation resource can explain the information to gather without pretending to diagnose a repair remotely.

Check overlap before drafting. A short preparation summary can belong on the service page with a link to the fuller explanation. The same entire article should not be copied across both pages merely to fill a template.

Use page or content block decisions when the destination is unclear.

Open editorial folio with a page assignment, checklist and reference sheets.

Carry W02’s evidence into the brief

W02’s stable ID does not change when its heading changes. The brief links the preparation question to the business confirmation it needs, records who checks those facts and states which route completes the task. The writer can draft supported orientation while leaving unconfirmed requirements unresolved.

The three filled briefs below show different page jobs. Each names the promised answer, the evidence owner and the conditions for acceptance. W04 has no completed brief because its comparison evidence is still missing.

W01 · Service brief

Reader: A furniture owner considering an assessment request.
Promise: Explain the confirmed scope and the information needed for the next decision.
Needed answers: What can be assessed; applicable area and conditions; what information to gather; what happens after a request.
Fact owner: The workshop’s designated assessor confirms service facts. A real project must record that person’s name and confirmation date.
Illustration purpose: Orient the reader to planning records. Use approved documentary photographs only when they truthfully represent the work.
Limits: No inferred qualifications, prices, repair result, remote diagnosis or guaranteed appointment.
Next action: Read the preparation summary, then use the confirmed assessment request route.
Acceptance checks: The title and opening match the confirmed offer; all conditions stay beside their claims; both preparation and request routes work.

W02 · Preparation brief

Reader: A person gathering information before an assessment request.
Promise: Explain the information the workshop has confirmed it needs and the limits of sending it.
Needed answers: Required description; permitted images and their purpose; relevant conditions; where information goes; the next expected step.
Fact owner: The person responsible for receiving and assessing requests confirms requirements; identity remains to be supplied in this fictional record.
Illustration purpose: Show a preparation folio and source records. Keep the confirmed required information in visible HTML.
Limits: No invented information requirement and no diagnosis from an uploaded photograph. Any unsupported instruction remains open.
Next action: Return to the service scope when uncertain, or continue to W03 once the requirements are confirmed.
Acceptance checks: A new reader can identify every confirmed requirement, distinguish optional information and find the confirmed request route.

W03 · Request brief

Reader: A person ready to send the information required by the workshop.
Promise: Explain and provide the confirmed request process with its requirements and expected follow up.
Needed answers: Who receives the request; required fields or attachments; contact and privacy information; acknowledgement and next step.
Fact owner: The business contact owner confirms the process; the site operator verifies the observed destination and supported controls.
Illustration purpose: A conceptual envelope can orient the example. It cannot demonstrate successful delivery or stand in for a working contact control.
Limits: The example includes no active submission service. An assessment request remains distinct from a confirmed appointment.
Next action: Show the confirmed acknowledgement and follow up route, including an honest path for errors or an unavailable service.
Acceptance checks: Labels and instructions agree with the real service; permitted function tests support the stated behavior; unperformed checks remain visible.

Draft, illustrate and connect the complete answers

Draft the direct answer first, then add the explanation and qualifications the reader needs. Preserve quantities, conditions, responsible actors and the strength of the source claim. A confident sentence is not a substitute for evidence.

Use documentary images only when they genuinely represent the work and can be published. A generated illustration can explain a concept but cannot prove a completed repair or customer result. Keep needed wording in ordinary page text.

Link the preparation explanation beside the request instructions. Use a label that explains the destination. Make the contact route match the business process: a request for assessment is not a confirmed appointment.

The SEO starter documentation recommends clear organization and useful connections. Apply that guidance to the task instead of adding a fixed number of links.

Keep the same task in the draft and its links

For W02, an initial supported opening can explain the purpose of gathering information and tell the reader that the workshop’s confirmed request instructions determine what to send. Add the confirmed requirements only after the responsible person supplies them. Do not invent a photograph list or collection method to make the example look finished.

Place any preparation link beside the service page’s request instructions. On the preparation answer, make the return to service scope and the onward request route clear at the point where each helps. Repeating the same complete preparation article across both pages makes its evidence and later revisions harder to govern.

For every image, record its purpose, visible content, permission or generation status, alternative text and placement. The wordless workshop illustrations on this learning page are conceptual. Required stages, conditions and records remain ordinary page text, so their meaning survives unavailable imagery.

Review the saved public page and record open checks

Review facts, source claims and links. Then inspect the rendered page, its heading order, meaningful structure, image alternatives and controls. Test the intended task using the access conditions a normal visitor will have.

Check the published URL, redirects, metadata, canonical preference and any structured data. A draft in an editor is not proof that the public page contains the same version. Keep the accepted body and the final saved result traceable.

Record unresolved limitations. A desktop screenshot cannot establish narrow screen behavior, a mail draft cannot prove a sent enquiry, and a sitemap entry cannot prove indexing. Fix observed defects and avoid certifying checks that were not performed.

An open content folio, tablet, source folders and an unmarked checklist await review.

Compare three versions explicitly

Accepted candidate: record the exact draft, media bindings, routes and review outcome.
Native saved content: read back what the website stored and compare the required text, image attributes and structure.
Public version: open the intended public URL under normal visitor access and check what renders and works there.

Use a release checklist with observable results

Check business claims against their responsible source and preserve the qualifications near each claim.
Check title, opening, heading order, landmarks and the meaning conveyed by image alternatives.
Follow contextual links to their observed final destinations, including meaningful fragments where used.
Inspect wide, narrow and intermediate layouts for readable text, intentional image placement and complete records without horizontal scrolling.
Use the keyboard to inspect focus, reading order and the skip route. Test safe controls and their visible states.
Record which functions were observed and which remain untested. Sending an enquiry requires authority for that external action.
Compare public content with the saved candidate. Check observed redirects, canonical preference, metadata and the active structured data output owner.
Record each defect, its repair, the exact revised version and the checks repeated after the change.
Preserve open evidence limits. A checklist entry becomes complete through an observed result, not through its presence in the record.

W02’s public review record would identify the exact version, URL, review date, observed checks, reviewer and remaining limits. No real workshop page has been saved or tested in this fictional example. Use post publication verification for the focused handoff.

Measure the declared task and maintain the map

Define the later question before collecting data. For the workshop, a review might examine if visitors can find the required project information and use the request route. Traffic and valid enquiries need separate definitions.

Record the baseline, dates, collection method and other changes. Report uncertain or negative findings as well as positive ones. A rise after release does not establish that the map caused it.

Assign review triggers: changed services, a broken contact destination or revised policy wording can reopen a page. Preserve the earlier decision and explain the reason for the update.

This example follows the complete process conceptually; it does not claim the fictional website was built or tested. Return to topic architecture or the learning overview for the next focused question.

A page record in a navy sleeve sits beside blank review slips, a calendar and an envelope.

Keep measurement questions separate

Task usability examines how a visitor finds the required project information and understands the request route. Traffic asks about visits under a defined collection method. Valid enquiries need an agreed business definition. None of these counts can silently stand in for the others.

Before collection, record permission, the baseline, observation period, sample, method and other changes that might affect the result. Retain uncertain, negative and inconclusive findings. Use task measurement planning to define the records before interpreting outcomes.

W02 · Example maintenance record

Stable node and version: W02, preparation answer; version remains proposed because this example includes no published workshop page.
Review trigger: The workshop changes the information it requests, its contact destination, a service condition or the source supporting an instruction.
Responsible actor: The business fact owner confirms the change; the editor identifies affected wording; the site operator and reviewer verify the revised saved version.
Affected commitments: Preparation instructions, the service summary, request labels, media meaning and every link or claim depending on the changed information.
Acceptance evidence: Updated source confirmation, versioned copy, saved readback and the repeated public checks relevant to the change.
History and outcome: Preserve the previous record, reason for revision and remaining limits. Measured business effects remain UNKNOWN unless suitable observations exist.

Q&A

Can a topical map be completed when some pages are pending?

A bounded map can have a reviewed set of decisions while named page commitments remain open. Report the map’s decision coverage separately from drafts, published pages and verified functions. W04 stays visible as pending evidence in this example.

Does AI search need a separate map?

Begin with the same supported reader tasks, useful answers and page ownership. Any claim about a particular search provider’s eligibility or observed citations needs its own current evidence. This process gives no visibility or citation guarantee.