Applications and scope
Use the principles. Adapt the page jobs.
A service business, an online store and a publisher can all need clear subjects and useful routes. Their facts, decisions and maintenance duties differ, so their pages should not be planned from one fixed template.
Free learning from Semantec SEO.
Start with the audience and the operating facts.
Identify what the organization does, who the website serves and what readers need to decide. Record the sources that can establish the offer, product information or editorial claims. Then assign pages to tasks rather than filling a standard set of headings.
Google’s helpful content documentation emphasizes an intended audience and useful original work. Its SEO starter documentation connects understandable content with logical organization. Neither makes every site type require the same number or shape of pages.
The examples below are invented planning exercises. They contain no measured demand, customer outcomes or claims about a real organization.
For the general definition, use what Semantic SEO means. This page applies that work to three different operating situations. A topic, a query and a keyword are different planning inputs; group the reader tasks before treating every wording variation as a new page.
Meaningful document roles support the usable page, while matching language is a separate question about words and context. Use visual meaning and semantic HTML for document roles, or semantic and lexical matching for that distinct explanation. Neither assigns a product fact or proves a business outcome.
Service example: a specialist agency.
Imagine a research agency offering a defined website review. Its homepage introduces the business. A service page explains the commissioned work, inputs, exclusions and next action. A free explanation answers a learning question without forcing an immediate enquiry.
Keep the agency, its people and its services distinct. Confirm the service area and any conditions that affect delivery. A business can serve customers remotely without maintaining an office in every named city.
Proof should describe work that happened and the permission to publish it. If there are no approved case studies, explain the method or use a clearly hypothetical example. Do not invent a testimonial or turn an internal plan into a client result.
The buyer may need to compare scope, identify required access and understand who approves release. A useful learning resource may instead explain a term or demonstrate a planning decision. Connect them where the next task is relevant, while preserving their different purposes.
Give the specialist service a complete evidence brief.
The invented research agency needs several different explanations, not one repeated sales page. Its business identity, commissioned review, free method, permitted proof and enquiry answer different reader questions. A shared subject does not make those tasks interchangeable.
Start with the operating facts and accountable source owner. Confirm the work offered, required material, exclusions, delivery arrangements, review responsibilities and request conditions before drafting a service promise.
| Page job | Input and evidence obligation | Accepted output and useful route |
|---|---|---|
| Homepage: identify the agency | The business owner’s accepted identity, scope and contact information. Keep the agency distinct from its staff and services. | An orientation that helps the reader choose the commissioned review or an appropriate learning resource, without inventing local offices. |
| Service: explain the commissioned review | Confirmed inputs, access boundaries, inclusions, exclusions, delivery scope and responsible approver. | A clear description of what may be commissioned and what the buyer must prepare; route to an actual enquiry with its review conditions. |
| Method: answer the learning question | A complete explanation, suitable sources and a clearly fictional example where real evidence is unavailable. | A useful free answer. Offer the service only where the next task requires commissioned work; do not make enquiry a prerequisite for understanding. |
| Proof: substantiate work that occurred | An actual scoped work record, outcome basis and permission to publish. Those records are not supplied in this hypothetical case. | Keep proof claims on hold. Explain the method or label a teaching scenario rather than inventing a client, testimonial or completed project. |
| Enquiry: request a discussion | A working route, required project information, access limitations and the business’s real receipt/fit process. | A request for review, not automatic acceptance, a booked meeting or a guaranteed result. Preserve the explanation of the next state. |
The evidence brief returns a page and route plan with source obligations and review responsibilities. It does not return a promise of rankings, enquiries or delivery dates. Reject a proposed page claiming a city office when no office record exists; remote service coverage does not establish a physical local team.
Catalog example: a product family with real differences.
Imagine a range of storage boxes with two capacities and two lid designs. Record the supported dimensions, storage volume, material and compatibility for each variant. Those differences can affect the buyer’s choice; merely changing a color name does not establish a new educational task.
A category page helps someone assess the range. A product page explains the selected item and its confirmed availability. A comparison can help when the choice depends on consistent criteria. A filter helps a visitor narrow the list but can also create many URLs.
Google’s faceted navigation documentation explains the crawl implications of filter combinations. Decide which destinations need independent search access before allowing every possible combination to become a crawlable route.
Do not copy attributes between variants without checking them. An image, stock statement or compatibility claim can become wrong even when most of the description is shared. Use a trusted product record and assign responsibility for changes.
Useful distinction comes from the selection task and supported differences. Repeated pages that add little for readers should not be justified by the number of keyword combinations available.
Plan the product family from supported differences.
The family of storage boxes above has two capacities and two lid designs. To make the planning record inspectable, this additional fictional catalog stipulates capacities of 10 litres and 20 litres, with a plain lid or a lid with a handle. These values describe a teaching fixture, not real products or measured stock.
Capacity and lid design can change a selection question, but they do not supply dimensions, material, availability or compatibility between variants. A lid shown beside a box is not evidence that it fits another box. Keep every variant’s own source and review state.
| Variant and stipulated volume | Dimensions, material and compatibility | Availability and media | Page proposal and check |
|---|---|---|---|
| S-PLAIN: 10 litres, plain lid | Dimensions and material NOT SUPPLIED. Exact lid fit and any compatibility between variants NOT VERIFIED; do not copy another variant’s values. | Stock NOT ACQUIRED. Require the correct variant image and a source owner’s approval; conceptual artwork here is not that product evidence. | A candidate item record for the smaller capacity with a plain lid. Hold unsupported attributes and any destination whose necessary product facts remain unresolved. |
| S-HANDLE: 10 litres, lid with a handle | Dimensions and material NOT SUPPLIED. A handle in this fixture does not establish load capacity, safety or compatibility with the plain lid. | Stock NOT ACQUIRED. Obtain media for this exact item and check the stated lid design rather than borrowing a generic picture. | Retain the smaller capacity with a lid with a handle in the range plan. Do not infer a separate learning task or publish unverified performance claims. |
| L-PLAIN: 20 litres, plain lid | Dimensions and material NOT SUPPLIED. A larger volume does not establish a particular external size or fit with a lid for the 10 litre box. | Stock NOT ACQUIRED. Require current item availability and a reviewed image linked to this variant. | A candidate item record for the larger capacity with a plain lid. Check the distinction with the category and comparison before accepting another destination. |
| L-HANDLE: 20 litres, lid with a handle | Dimensions and material NOT SUPPLIED. Compatibility, load and handle performance remain unverified. | Stock NOT ACQUIRED. Use this item’s actual record and media; do not propagate another variant’s stock or photograph by assumption. | A candidate larger capacity with a lid with a handle. Keep the required evidence and human acceptance separate from the proposed URL. |
Keep useful filters separate from accepted page ownership.
In this fixture, filtering to 20 litres and the lid with a handle expresses a real capacity/design choice. It is a useful selection state, but an independent search destination still requires a distinct supported answer, sufficient product records and a reviewed access decision. The filtered state alone does not approve indexing or a new educational page.
A second proposed destination that changes only an unverified color label while returning the same products and answer is redundant in this scenario. Reject that separate page proposal while keeping any genuinely useful user filter. Do not invent a product color or demand estimate to justify another URL. Require distinct value in generated destinations and choose owners for facet URLs before technical implementation.
Separate the automated proposal, checks and human decision.
- Accepted inputs. Supply the permitted catalog records, exact variant identifiers, supported facts, available media and existing destinations. The fixture’s unresolved values remain unresolved.
- Proposal. A tool may suggest category, item, comparison or filtered destinations and their page jobs. A proposed destination is not approved or published.
- Fact and duplicate review. Compare every attribute with the specific variant record. Inspect whether another destination already answers the same selection task. Reject copied stock, unsupported compatibility and redundant answers.
- Exception handling. If one item lacks material, media or availability evidence, hold the relevant claim or destination and request the missing source. Do not fill it from the neighboring variant merely to finish a batch.
- Named acceptance. Assign a catalog owner and editorial reviewer to accept or reject the proposal, record the source/version and release requirements, and preserve the decision. These are responsibilities to assign; no actual person or unattended publication is asserted here.
Publisher example: a large educational archive.
Imagine a publisher with introductory articles, detailed methods and older news. Build a matrix of subject, reader task, author or reviewer, evidence date and current destination. The matrix helps identify missing answers, competing explanations and articles whose facts need review.
An author page explains the relevant person and their contribution. A topic overview helps readers choose a focused article. An archive listing can organize material without pretending that every historical post remains the best current answer.
Suppose an older introduction and a newer explanation answer the same task. Compare their evidence and useful detail before choosing to retain, combine or distinguish them. Record the replacement route if a page is retired; avoid redirecting every old article to a generic homepage.
Keep corrections and update dates meaningful. A historical event report can remain useful as a historical record, while current advice may need a revision or warning. Do not erase that distinction merely to make the archive appear fresh.
A proposed matrix does not establish that the archive has been audited. Record each reviewed article and its remaining uncertainty rather than reporting the entire collection complete.
Keep current explanations and historical records distinct.
The fictional publisher needs an inventory that describes each article’s actual subject, reader task, responsible author or reviewer, evidence date and maintained destination. An overview helps a reader select a resource. An author page explains a person’s contribution. A dated archive organizes records without declaring every old article current advice.
The proposed rows below are planning examples. They do not establish that an archive has been fully audited, that an article is approved or that a redirect has been made.
| Subject and reader task | Responsibility and evidence | Destination decision and next action |
|---|---|---|
| An older introduction and a newer explanation both teach the same planning distinction. | Read both complete articles. Record each author/reviewer, actual source dates, unique examples and any unsupported claim. Those real values are NOT ACQUIRED in this fixture. | Hold an independent duplicate introduction. Preserve the useful older case in the maintained explanation if the full comparison establishes the same task. Accept a destination only after ownership review; a newer date alone is insufficient. |
| A detailed method teaches a procedure beyond the introductory answer. | Retain its prerequisites, full steps, worked example and accountable reviewer. Check that the operation adds a different completion task rather than only a longer title. | A distinct method destination can be proposed when the full evidence supports it. The overview should route to it after the introductory explanation, not substitute for the local answer. |
| Historical news reports what happened during a past event. | Preserve the event date, attributed sources and original reporting context. Review corrections without silently recasting the article as current instructions. | Keep a clearly historical record where useful. Offer a current explanation for a current task only when a suitable maintained destination exists; do not redirect all old news to a generic homepage. |
Record a relevant replacement route before any retirement. Preserve useful detail, source history and open conflicts in the decision. Review changed archive facts and plan versioned documentation when the task depends on a particular release.
Adapt for place, language and evidence.
Country, language and service coverage can change an answer. Google’s international site documentation distinguishes language versions from country targeting. Translation alone does not confirm that a product, price or policy applies in another market.
Location pages need a supported reason to exist. Confirm the service, local information and route available to the reader. Do not invent an address, local team or customer proof to make a template appear specific.
Google’s spam policies address scaled content created to manipulate rankings without helping people. Automation does not remove responsibility for page purpose, factual evidence or useful distinctions.
Change the local answer only when its facts change.
Language identifies the wording needed by the reader. Country targeting concerns the intended market. Service coverage identifies where an actual offer is available. These are separate facts; translating a page does not prove that the same price, policy, stock or service applies elsewhere.
For each proposed local or translated destination, record the source that changes the answer, its owner, date and applicability. If the only supplied difference is a place name in the title, an independent page remains unjustified until its reader task and factual distinction are established.
- Service example
- An approved coverage record could support different delivery arrangements in a named area. No such local record is supplied here. Do not turn a remote agency’s coverage into an office address or invent staff and customer proof.
- Catalog example
- A product record for a particular market may change availability, compatibility, units or conditions. Verify the exact item and market; translation alone does not approve those values.
- Archive example
- A rule applicable to a particular country or language need may change the explanation. Keep the applicable source and historical period with that answer; a different language is not evidence of a different legal rule.
Localize the answer and evidence for that distinct task. For a commissioned plan for location content, prepare the operating and coverage evidence instead of manufacturing locality.
Choose the next task by the problem.
Use topic architecture for page ownership, entity learning for identity and relationships, and content refresh for changed facts and archive decisions.
This resource covers three site applications and introduces the wider branch. Detailed location, international, regulated subject and platform work remains scoped separately. Return to the learning overview or describe the website and its constraints.
Compare acceptance across the three applications.
The same principles produce different obligations because the task and evidence differ. Each proposed destination must add a useful answer supported by available records. A keyword list, automated draft or repeated layout does not settle that decision.
| Acceptance question | Specialist agency | Storage box catalog | Educational archive |
|---|---|---|---|
| Reader task | Understand commissioned review scope or learn the method, then choose a suitable next action. | Select a supported capacity and lid design, then inspect the exact item and its availability. | Choose an introduction, deeper method or historical record for the actual question. |
| Facts to establish | Business identity, work offered, accepted inputs, exclusions and delivery conditions. | Each variant’s volume, dimensions, material, compatibility, current stock and correct media. | Article subject, task, author/reviewer, evidence date, historical scope and maintained destination. |
| Distinct page role | Homepage orientation, service explanation, free method, permitted proof and enquiry have different jobs. | Category, item, comparison and useful filter state need their own evidence; a redundant color label does not create a new task. | Overview selects resources, method teaches a deeper operation, and historical news retains its dated purpose. |
| Evidence owner | The actual business/service owner confirms scope; an authorized reviewer accepts factual and release claims. | The catalog owner confirms the exact variant record and a named reviewer accepts the page proposal. | The author, subject reviewer and editorial owner supply the article’s evidence and maintenance responsibility. |
| Visual need | Approved proof only where it exists; otherwise an honest conceptual method example. | Correct item media and a readable comparison with unsupported attributes left unresolved. | A useful route or relationship model with full text and a clear distinction between historical and current material. |
| Useful next route | An actual scope discussion after the reader understands the required material and review conditions. | The exact item, supported comparison or selection state; no promise that a proposed filter is an indexed destination. | The maintained explanation, full method or clearly historical article matching the unresolved question. |
| Maintenance trigger | A changed service boundary, delivery arrangement, input requirement or publication permission. | A changed variant fact, media, stock condition, compatibility record or ownership decision. | A changed source, correction, competing explanation, version boundary or retired task. |
Reject the unsupported proposal claiming a city office, the redundant destination differing only by color and the duplicate introduction for their actual evidence or task defects, not because of low keyword volume. Keep any useful information and relevant route while the ownership decision is reviewed.
Assign page jobs and website structure when the unresolved problem is architecture. For commissioned planning, discuss a topical map project with the website, operating facts, source material and constraints. No example on this page promises an accepted engagement or business outcome.
Choose the next evidence or method task.
The local explanation remains the starting point. These resources address distinct next tasks; this page does not establish that the complete learning branch has been reviewed or accepted.
- Documentation and technical resources
Plan the reader tasks, versions, evidence and routes needed by a technical documentation collection. Begin with the actual question or procedure and identify the product, platform, release and audience to which the answer applies. Record the prerequisites, permissions and starting state before describing an action. A procedure for one release must not silently become advice for another.
Attach the applicable source, configuration and test record to the explanation. Distinguish an instruction supported by a source from an action actually tested in the stated environment. Keep expected results, observed results, error conditions and recovery steps separate; leave unsupported behavior, compatibility and missing evidence unresolved rather than inventing a successful result.
Assign a distinct page owner when the reader task requires its own complete explanation. Keep necessary prerequisites and conditions with that answer, and route to the actual related concept, procedure or troubleshooting task when the reader needs it. Do not create competing pages solely because folder names or versions differ. Name a maintainer and a review trigger for changed sources, releases, dependencies or observed failures. This is a planning method, not evidence that a documentation collection has been built, tested or accepted.
- Language and Regional Content: Localize the Answer and Its Evidence
- Identify the actual language or market difference and its source before localizing the answer.
- Versioned Technical Documentation: A Tested JSON Troubleshooting Example
- Keep inputs, procedures and troubleshooting evidence for the stated version with the applicable release.