How do you audit an existing page?
Capture the current title, description, main answer and relevant performance context before editing. Record each mismatch as expected versus actual behavior, choose the smallest useful correction and retest the public URL. Keep a copy of the original evidence so the revision can be reviewed later.
What does a useful on-page revision look like?
Illustrative example: a service page promises pricing in its title but only displays a contact form. The revision is to provide accurate pricing information and conditions if the business can publish them, or to change the promise. Adding the phrase pricing repeatedly would not resolve the missing answer. This is a hypothetical example.
When should you switch to a technical or sitewide audit?
Use the technical checklist when the problem concerns status codes, robots rules, indexing directives, canonicals or rendering. Use the SEO audit checklist when you need to compare templates, quantify affected scope and prioritize issues across a website. Keep this page focused on one URL at a time.
How does the page format change the on-page review?
The page’s purpose determines which information must be present. An explanatory article should answer the question and support its claims. A service page should describe a real offering and the next appropriate action. A product page should identify the actual item and relevant purchase information. A tool page should let someone perform the promised task.
Do not review every page as though it were a long blog post. More headings do not repair a product page with missing specifications, and a large introduction does not help a visitor who arrived to use a checklist. Keep the essential qualification or limitation close to the information it changes.
The examples below are editorial criteria, not universal ranking factors. Apply them to the actual page and verified offering. If the necessary information cannot be published, adjust the promise honestly instead of inventing an answer.
Creating helpful, reliable, people-first content
What does a complete page-level revision look like?
Consider an illustrative service page whose title promises a repair estimate, but whose body contains only a broad company introduction and a contact form. The page also links to an old contact route. This invented example shows a review method; it is not a real customer audit or a claim of measured improvement.
Firstly, write the intended task: help a potential customer understand the service scope and how to request an estimate. Secondly, verify what the business can truthfully publish. If a public fixed price is not available, the page should not imply that an exact price is already on the page. It can explain the information needed for an estimate and the genuine request process.
Thirdly, align the title, heading and opening with that verified promise. Describe the actual service, relevant exclusions and the next step before adding general background. Include evidence for claims such as coverage, qualifications or availability only when the business can substantiate them. Do not insert invented credentials to make the page look more trustworthy.
Finally, fix the old contact link and test the public route after publication. Check the title element, visible heading, main answer and mobile interaction. Record the content changed and the date. The successful result is a more accurate page and a working path; any later change in search performance is a separate observation with its own limits.
Title links in Google Search · Creating helpful, reliable, people-first content · Crawlable links and descriptive anchor text
How do you build a useful heading outline?
A heading outline should describe the page even when the paragraphs are hidden. Start with the principal task, then divide the answer into the sections a reader needs to understand or act. Use subheadings to show genuine relationships within a section, not merely to make another keyword prominent.
For an illustrative service page, a meaningful outline might include what the service covers, when it is suitable, what the request process needs, and what happens after the enquiry. For a checklist page, the outline should follow the testing sequence and group related actions. These structures differ because the visitor tasks differ.
Check the resulting hierarchy in the published HTML. A large bold paragraph is not necessarily a heading, and a heading should not be chosen just for its visual size. Keep one clear main page topic and use appropriate nested levels for its sections. Avoid skipping around merely to obtain a preferred font treatment.
Do not force question wording onto every heading. A short task heading can be clearer for a procedure, while a question can be useful for a genuine follow-up. The opening sentence should answer or begin the task directly. This is a writing and accessibility practice, not a claim that a fixed heading pattern guarantees search results.
WAI page headings
Which page claims need a source or verification record?
Prioritize claims that could change a reader’s decision or become outdated. That includes availability, prices, qualifications, product behavior, policy conditions, numerical comparisons and statements about observed results. A general connective sentence needs less support than a specific promise that someone may rely on.
Keep the evidence appropriate to the claim. A platform rule should point to applicable official guidance. A business offering should match the organization’s real information. A customer outcome needs a real authorized record and permission to use it. A hypothetical example should say that it is hypothetical rather than borrowing the appearance of a case study.
Check what the source actually supports. A link to a respected domain does not validate an unrelated statement, and a dated screenshot does not establish that the same interface or result still exists. When the evidence is weaker than the claim, narrow the wording or remove the assertion.
The following ledger is an editorial review aid. It does not require publishing private evidence or adding a citation to every sentence. Store sensitive supporting material appropriately and show only the information the audience is authorized to receive.
Creating helpful, reliable, people-first content
How do you choose internal links for one page?
Choose links from the reader’s next useful question. A service page may need a relevant process explanation or contact destination. An audit checklist may need the deeper technical test for a finding. A definition page may need an example. The purpose is to connect real tasks, not to satisfy an arbitrary number of links.
Read the sentence around each link. The anchor should give enough context to predict the destination without stuffing several keyword variants into it. Check the actual target, including redirects and fragments. A descriptive anchor pointing to the wrong page is still a bad link.
Look for useful incoming links as well. A well-written page that is absent from relevant navigation or contextual paths can be difficult for visitors to find. Identify an existing page where a link genuinely helps. Avoid adding the new URL everywhere or creating a block of unrelated links solely to increase a count.
After publication, follow the changed path from the source page on a small screen and with the keyboard. If the destination is not ready, do not publish a placeholder link that promises an unavailable resource. Record the dependency and add the link when the actual page exists.
Crawlable links and descriptive anchor text
What makes an image useful to the page?
A useful image explains something that is harder to understand from the nearby text alone. It can show a real product detail, clarify a process, illustrate a comparison or provide an example. Decoration can support the design, but it should not be counted as evidence for a factual claim.
Choose the subject from the task, then write the surrounding explanation and alternative text for that context. An informative process image needs its important meaning available in text. A decorative image should not force assistive-technology users to hear a redundant description. An image used as a link or control needs an accessible name that explains its function.
Keep generated illustrations distinct from observations. Do not create a realistic analytics dashboard to imply an audit took place, or a fabricated product screenshot to show a feature that has not been verified. Use an explicit illustrative label when the visual depicts a hypothetical example.
Check the delivered asset on mobile and after publication. Verify that it loads, remains legible and does not obscure nearby content. For technical delivery problems, use the performance and rendering checks rather than imposing a universal image-size threshold on every page.
Image SEO best practices · Decorative images and alternative text
When should an updated date change?
An updated date should represent a real update to the content. Correcting an important fact, adding necessary evidence or materially revising the guidance can justify a new date. Merely changing the year in a heading or the copyright line does not establish that the page has been reviewed.
Keep different events distinct in your record: original publication, a substantive revision, a source check and a user’s own test result. A checklist source-review date should not imply that every visitor’s website was inspected on that date. If you display structured publication or modification dates, align them with the real page history and visible information.
For an existing page, keep a short change note that explains what actually changed and why. It helps another editor decide when the evidence needs another review. Avoid future dates, invented author activity or automatic daily freshness claims that the work does not support.
Publication and modification dates
