SAMPLE PROJECT · SEO AUDIT DEMONSTRATION

Content website audit

An illustrative audit showing how findings, affected pages, priorities and recommended actions can be organised.

Demonstration only. This is a fictional example, not a paid client project. No measured outcomes are claimed.

BACKGROUND & PROBLEM

The example brief.

A fictional content website needs a practical way to separate crawl issues, overlapping topics and page-level improvements.

Imagine a small publishing website with an introduction, a service page and several related guides. Its owner has a crawl export but needs to decide which findings deserve attention first. Some URLs may have been replaced intentionally, while others may have unclear headings or weak links to useful supporting information. A practical audit would distinguish those situations before recommending a change.

The example begins with a limited page inventory and a purpose beside each URL. A guide might answer an early research question, while a service page should explain the offer and the next step. Comparing those purposes helps identify genuine overlap without assuming that every shared phrase makes two pages duplicates.

For an actual assignment, the brief would confirm the site version, available Search Console access, the crawl date and the pages important to the business. It would also define who approves implementation. The audit deliverable would separate a verified problem from a question that needs more evidence, giving the owner a clear basis for choosing the next task.

ROLE & SCOPE

Demonstration planning.

Illustrative content, structure and deliverable planning for this portfolio. No live client implementation is represented.

  • A structured review of indexability, titles, headings and internal links. The audit plan would begin with important public URLs and compare their intended purpose with what visitors can read. A crawl result would be checked against the live page. Search Console, when available, would provide separate evidence about Google’s processing of a URL. Page titles and headings would be reviewed for clarity, and supporting links would be examined in their reading context.
  • A finding format with evidence, affected URLs, priority and suggested action. Each proposed finding would include the URL, observation, report date, supporting screenshot or response and an explanation of its effect. The suggested action would be small enough to review. An intended redirect, restricted administration screen or duplicate archive would need its purpose confirmed before being treated as a defect.
  • A roadmap separating investigation, implementation and measurement. The roadmap would identify decisions still awaiting evidence, approved repairs and the checks needed after those repairs. Ownership and dependencies would sit beside each task. A content revision and a cache setting would have different verification steps, so the handover would specify the relevant test instead of using one completion label for every change.

ILLUSTRATIVE AUDIT FINDINGS

A useful finding links evidence to an action.

EXAMPLE · HIGH PRIORITY

Indexability check

Illustrative URL: /service-example/
Check: Is the intended page blocked or marked noindex?
Action: Confirm the intended visibility before changing directives.

EXAMPLE · MEDIUM PRIORITY

Overlapping page topics

Illustrative URLs: /guide-a/ and /guide-b/
Check: Do both pages target the same intent?
Action: Define distinct purposes or consider consolidation.

EXAMPLE · MEDIUM PRIORITY

Internal link gaps

Illustrative URL: /topic-example/
Check: Can readers reach the relevant supporting page?
Action: Add contextual links where they help the reader.

An implementation roadmap.

  • Confirm the finding. Compare the affected URL with the current website and the dated crawl. For the illustrative indexability row above, establish whether the page is meant to be public, then inspect the available crawl and indexing evidence. Keep the original observation with the task. If the report describes an older version or an intentional exclusion, record that explanation before proposing a repair. This stage should leave a clear finding or a specific question for the owner.
  • Implement an agreed, limited repair. Choose the page, text field, link or setting that needs attention and retain its original state. For the overlapping-topic example, compare the questions answered by both guides before recommending distinct content or consolidation. If a URL is replaced, review the destination and links pointing to it. Make the change through the editor or plugin that owns the content, and note any shared template that also needs checking.
  • Verify and report the result. Repeat the original check on the live page and follow the affected reader journey. Re-crawl the relevant URLs when the report needs to reflect the repair. For an internal-link change, verify both the link label and its actual destination. Keep the new crawl date, observations and unresolved items with the work record. Search-performance reporting would use an agreed period and real data; a saved change or improved audit score would not establish a traffic gain.

EVIDENCE & OUTCOME

What this sample demonstrates.

All findings here are illustrative. No real website has been audited in this demonstration, and no ranking or traffic gains are claimed.

This sample shows how to connect an observation with a decision. The indexability example asks whether a page should be accessible, the topic example asks what each guide should explain and the internal-link example asks whether readers can reach the supporting material. Each one needs its own evidence and a relevant verification method. That is the organising principle a reviewer can assess here.

A real audit handover would contain the page inventory, dated crawl, finding register and implementation queue. The register would include the evidence source, task owner, current status and check needed to close the task. Screenshots would show the affected section or response clearly enough for another person to reproduce the observation.

Completion would mean that the agreed checks have been performed and their results recorded. Items requiring access, a content decision or an approval would remain identified in the handover. Later outcome reporting could compare real search or enquiry data over a stated period, with other changes noted where relevant. The portfolio demonstration itself supplies the example method and findings, rather than a client result.

The examples on this page are the demonstration itself. Real project screenshots, dates, role details and sourced metrics can replace this content later.

LET’S WORK ON YOUR NEXT STEP

Have a website or SEO project in mind?

Send your website link, the service you need and what you want to improve. We can start with a clear brief and an agreed scope.