This is a practice project. The site is my own test site. There is no client, no budget and no commercial outcome. Every number in the before-and-after section is an illustrative example created to demonstrate the reporting format, not a measurement of real traffic, rankings or conversions.
Project overview
| Project type | Self-directed practice audit |
|---|---|
| Site | My own small static test site (multiple templates, under 20 URLs) |
| My role | Auditor and implementer: I found the issues and fixed them |
| Duration | [Add your dates], kept as a placeholder until accurate |
| Deliverables | Issue log, prioritised fix list, before-and-after table, re-crawl notes |
Context: why this site
I wanted a site where I could make a change and inspect the result immediately, without waiting for permission or risking someone else's traffic. A static site is ideal for this: the HTML is the whole page, there is no database, and nothing is hidden behind a build step I do not understand yet.
That simplicity is also the limitation. This audit says nothing about how I would handle a site with JavaScript-rendered content, faceted navigation, or hundreds of thousands of URLs. Those are different problems, and I would need different evidence to talk about them honestly.
Audit objectives
- Confirm that every page I intended to be indexable was actually reachable and free of blocking directives.
- Find inconsistencies between the XML sitemap, internal links and the pages that exist.
- Review every indexable page against an on-page checklist.
- Produce a prioritised fix list small enough to complete in a few sessions.
- Re-crawl the same URLs afterwards and record what changed.
Tools and methods
| Tool or method | Used for | Limitation I hit |
|---|---|---|
| Local server + manual review | Reading raw HTML, checking titles, canonicals and headings | Nothing about indexing can be tested locally |
| Free crawler | Collecting URLs, status codes, duplicate titles and missing descriptions | Free tiers cap the number of URLs |
| Browser developer tools | Rendered DOM, network weight, layout shift, console errors | Manual, so only practical on a sample |
| Lighthouse (mobile) | Performance, accessibility and basic SEO checks per template | Lab data only, not real visitor experience |
| Spreadsheet log | One row per issue: URL, evidence, severity, fix, status | Only as useful as the notes I write in it |
Issues identified
Eight issues, sorted by severity. "Severity" here means how much damage the issue does to discovery or interpretation, not how difficult it is to fix.
| Issue | Evidence | Severity |
|---|---|---|
| Two pages shared the same title | Blog index and homepage both titled with the site name only | High |
| Canonical tags used a placeholder domain | your-domain.com in every page head |
High (blocking at launch) |
| Article template had no breadcrumb markup | Only a visible "back" link | Medium |
| Internal links used vague anchors | "Read more" and "here" across card footers | Medium |
| Diagram images had no dimensions | <img> without width and height |
Medium (layout shift) |
| Sitemap omitted one article | Three articles on disk, two listed in the sitemap | Medium |
| Mobile menu button had no accessible name | Icon-only button, no label | Medium (accessibility) |
| One H2 used for visual size only | Heading level chosen to match a font size | Low |
Recommended fixes
| Fix | Effort | Priority |
|---|---|---|
| Replace the placeholder domain in canonicals and sitemap | Low | 1 (blocking) |
| Rewrite duplicate and generic titles | Low | 2 (structural) |
| Add breadcrumb navigation and BreadcrumbList markup | Medium | 2 (structural) |
| Add width and height to every image | Low | 3 (performance) |
| Replace vague anchors with descriptive link text | Medium | 3 (performance) |
| Regenerate the sitemap from the real file list | Low | 2 (structural) |
| Give the menu button an accessible name | Low | 4 (polish) |
| Correct the heading level used for styling | Low | 4 (polish) |
Note the shape of that list: the blocking item takes minutes, while the "polish" items take just as long but matter less. Doing them in severity order is what makes a short audit useful.
Before and after (illustrative)
The table below shows the reporting format I would use for a real project. The values are invented to demonstrate structure and must never be presented as measured outcomes.
| Check | Before (example) | After (example) |
|---|---|---|
| Pages with a unique title | 5 of 9 | 9 of 9 |
| Pages with a unique meta description | 3 of 9 | 9 of 9 |
| Canonical pointing at the production domain | 0 of 9 | 9 of 9 |
| Internal links with descriptive anchors | 62% | 100% |
| Images with width and height set | 1 of 4 | 4 of 4 |
| Sitemap URLs matching real, indexable pages | 8 of 9 | 9 of 9 |
That is the honest shape of a technical audit: mostly binary checks, not percentages of traffic. Traffic and ranking movement are outcomes you hope for; these are things you can actually verify.
Results
| Metric | Baseline | After 4 weeks | Notes |
|---|---|---|---|
| Impressions | Not yet measured | Not yet measured | Requires a live site and Search Console |
| Clicks | Not yet measured | Not yet measured | Requires a live site and Search Console |
| Average position | Not yet measured | Not yet measured | Compare like-for-like date ranges |
| Core Web Vitals (field) | Not yet measured | Not yet measured | Field data needs real visitors |
This section stays empty until the site is published, verified and has enough data to compare. If it never fills in, the honest thing is to say so, not to invent a number.
Lessons learned
- Audit the sitemap against the file system, not against memory. I was confident all three articles were listed. One was not.
- Placeholder values survive longer than you expect. The canonical domain was the single most damaging issue on the site and also the easiest to fix.
- Severity and effort are different axes. Sorting by effort feels productive and produces the wrong order.
- A change log is the deliverable. Without it, the "after" state is just a claim.
- Small sites hide big lessons. Everything above also happens on large sites; here it is just visible enough for a beginner to see.
What I would do next
- Publish to a real domain and replace every placeholder URL.
- Verify the site in Search Console, submit the sitemap, and record the baseline.
- Re-run the same eight checks after four weeks and fill in the results table with real data.
- Repeat the audit on a second, deliberately more complex test site with a blog pagination and category structure.
The methods behind each step are written up in the technical audit walkthrough and the on-page checklist.