Decide what the page should do
Identify the reader’s main question and what belongs on other pages. A purchase-focused page needs a clear offering. A guide needs to help readers understand or do something.
Two pages using similar words may serve different purposes. Document their boundaries before rewriting them.
On-page SEO concerns the content and page components that help visitors and search engines understand a particular page. Technical SEO also covers conditions such as crawling and indexing, while off-page work concerns signals outside the website. If a page cannot be fetched or indexed, that problem needs to be addressed alongside the content work.
Illustrative example: “What should a requirements specification include?” and “Help building a business website” are closely related but need different answers. The guide gives readers a basis for commissioning the work. The service page describes the delivery, process and conditions. Let the pages support each other through relevant links instead of using the same sales copy on both.
What evidence is needed before changing the text?
Collect the page’s current questions, verified business information and the answers missing from the reader’s decision. Use Search Console data for the specific URL where available, together with real customer questions and a review of relevant search results. Distinguish observed questions from your own proposals. A proposal does not become demonstrated demand simply because it fits a heading.
| Question to address | Evidence needed | Location and reason |
|---|---|---|
| Which parts should the specification describe? | An explained structure covering pages, features and responsibilities. | Main section: the answer is needed to use the guide. |
| How is the contact form approved? | A test case identifying the recipient, test environment and expected confirmation. | A subsection on acceptance: part of the same commissioning task. |
| Can SOVRA Digital build the website? | Actual delivery, scope and terms. | A relevant link to the service page: the guide should not repeat the whole offering. |
Write an acceptance criterion for each important question: what should the reader be able to decide after the answer? Then identify the paragraph, example or table row that makes this possible. If information is missing, obtain it from the responsible person or a relevant source. Adding synonyms does not resolve a missing fact.
Review the page’s elements together
Review the title, main heading, answers, supporting evidence and links as parts of the same page. Use the list to find gaps between what the page promises and what it actually helps readers with.
- The title describes the specific page.
- The H1 identifies a clear main topic.
- The introduction provides the main answer or explains the commercial offering.
- Subheadings divide genuine subtopics.
- Facts, conditions and evidence sit close to important claims.
- Internal links help readers meet a relevant next need.
How do the title, H1 and meta description work together?
The title, H1 and meta description should describe the same page purpose, each with its own role. The title names the page, the H1 introduces its main topic, and the meta description summarises what readers will find. A guide to requirements specifications should therefore not promise a completed website project in its metadata.
Google’s guidance on title links describes several sources that may be used for the search result’s title.
For a page that needs a better summary in its metadata, the meta description guide shows how to check the text against the actual content. This is a different component from the visible main heading.
Resolve a conflict between the title and content by first deciding which promise the page actually fulfils. If the title says “price and comparison” but the page merely defines the service, an answer is missing, not just better wording. Either add verified pricing evidence and comparable conditions, or limit the title to what the page genuinely covers. Also check card headings and sharing metadata so visitors do not receive different promises before and after clicking.
Google can generate its title link from several sources, including the title element, visible main heading and link text. Write a descriptive, concise title in the page’s language; its exact reproduction in search results cannot be guaranteed. A truncated title link alone is not evidence that the content is wrong. Check the context before changing the title.
How should subtopics be divided between H2 and H3?
H2 headings divide the main topic, while H3 headings group a subtopic within an H2 section. Under a heading about mobile testing, a contact form and an error report may need separate explanations. A short explanation that already fits clearly within a paragraph, however, does not need its own heading. Choose the order according to what readers need to understand first, and provide a direct answer before expanding on the details.
Test the relationship between headings without the body text. If the H2 concerns pricing, H3 headings can explain scope, one-off work and recurring costs. A separate subject such as Business Profile verification does not belong under the same H2 merely because it also concerns the company’s marketing. First explain the shared question, then organise the necessary conditions and subsidiary decisions beneath it.
A quick answer must retain the conditions that make it true. If delivery timing depends on approved content, that condition must remain when the answer is shortened or bolded. Then explain how the process works and what needs checking. Bold text helps readers find the conclusion; it cannot replace the explanation or evidence.
How should internal links be chosen?
Link when another page provides the information readers need next. The anchor text should explain where the link leads, and the surrounding sentence should make the connection clear. A link to a technical guide meets a need for greater depth; a link to a service helps readers assess support with implementation. Avoid several links serving the same purpose in a short section.
Compare “Read more” with “Use a requirements specification to record responsibilities and acceptance”. The second wording explains both the topic and why the link belongs in the section. Do not add more keywords than readers need to understand the next page. Also check that the destination genuinely contains the promised answer and that the link does not use an outdated or incorrect address.
The link also needs to work technically. Google recommends an a element with an actual href address and descriptive anchor text. An area that only responds to a script is not equivalent to an explicitly defined link. Google’s link guidance explains the distinction. Assess both the link from this page and how readers find this page from a relevant parent page.
What should images and structured data add?
Images and structured data should clarify content the page actually contains. Place an explanatory image close to what it illustrates, and provide a relevant text description when the image conveys information. Critical conditions should be readable without the image. If the page uses structured data, the information must match the visible content. The structured data guide explains this check in more depth.

Improve the answer before the wording
If a page about cost does not explain the scope, repeating “price” more often will not help. Add what the amount covers, relevant conditions and a comparable unit.
The guide to writing SEO content in Swedish gives examples of how to write the answer clearly.
A clear answer requires the page’s elements to describe the same thing. The following is an editorial example, not a customer result: the title could be “Website requirements: content and responsibilities”, the H1 “Website requirements: content, responsibilities and approval”, and the first answer “Specify pages, features, responsibilities and how the delivery will be approved.” A specific requirement could be: “A test enquiry from the agreed mobile environment must reach the correct recipient and give the visitor a confirmation.” The client specifies the recipient and an assigned reviewer submits the test enquiry. The record identifies the test environment, actual receipt and the message shown to the visitor. This gives approval a traceable basis; an on-screen confirmation alone does not show that the enquiry arrived.
A relevant link in that example could read: “Once responsibilities and content have been agreed, the requirements specification can be used to check the delivery.” The link promises a task the guide actually covers. Do not add a source simply because it is well known; it must support the specific claim.
When does an answer need more explanation?
Develop the answer when readers still lack a necessary step, condition or evidence for deciding the question. A page can mention every relevant term and still leave the decision unanswered. “What is included?” requires a bounded delivery description. “How is it checked?” requires a procedure and an expected outcome.
- Definition: is it clear what the term means and what it excludes?
- Mechanism: is it explained why the action could solve this particular problem?
- Implementation: are the required information, access and steps described?
- Conditions: does the answer explain when the advice is insufficient or another check is needed?
- Example: does it show how the reasoning is applied without presenting an invented case as a real result?
This is a review method, not a requirement for five new subheadings beneath every question. Keep what readers need for the task and direct genuine further detail to its existing owner page. Google’s questions for assessing helpful content emphasise completeness, originality and reliability. A particular word count does not demonstrate that those requirements are met.

Check what visitors receive
Review the rendered page and its mobile version. Confirm that links and contact journeys work and that the metadata matches the approved content.
Assess each component by what it helps visitors do. A table should make options comparable, and a form should be submittable with understandable feedback. Important conditions and conclusions need to exist as readable text even when they also appear in an image or diagram.
Position on the screen does not, on its own, determine what counts as main content. A pricing condition or decisive piece of evidence further down the page can still be central to the page’s purpose.
Save a short change record with the page address, previous problem, new answer and completed check. In the example above, the check could establish that the test enquiry actually arrived and that the heading, instructions and confirmation describe the same journey. A content review does not prove that the form works; that needs checking in the actual implementation.
Then track relevant queries and page outcomes using the same scope as before the change. A rise in clicks need not be caused by the changed heading. Record other simultaneous work and separate technical delivery checks from later outcome measurement. This makes it possible to improve the page without confusing a completed change with a proven business result.
An improved page needs to be followed up with relevant data. A tool score is not, by itself, a customer result. If the review finds that the page lacks a clear answer or verified supporting information, the content needs further work. Read how SOVRA Digital’s content work is coordinated with the page’s purpose.
Improve the page within the wider SEO engagement
SOVRA Digital coordinates content, headings and internal links with the website’s technical foundation and measurement. On-page work is included in an SEO package with eight connected areas of work.

