Final Project: Technical SEO Audit and Repair Plan

Audit the System, Not the Score

Technical SEO is maintenance of agreements: links point somewhere real, servers answer honestly, directives do not conflict, machine-readable data matches visible content, and monitoring checks whether those agreements still hold.

The audit must cover:

1. discovery and internal links
2. status codes and redirect paths
3. robots and index directives
4. sitemap accuracy
5. canonical consistency
6. initial and rendered content for representative JavaScript routes
7. mobile content parity
8. structured data on at least one eligible page
9. Search Console or Bing evidence when access exists
10. HTTPS and Core Web Vitals integration, referring back to the performance pathway

Required Workflow

Phase 1 - Define scope

Name the site, owner or permission, date, environment, and page sample. State business or user outcomes for the most important pages. Identify constraints and unavailable accounts.

Phase 2 - Collect evidence

Inventory scoped URLs. Capture status, final URL, canonical, index directive, sitemap membership, incoming links, title/H1, and rendered-content check. Retain screenshots only when they prove a finding.

Phase 3 - Classify findings

Severity is impact plus scope, not tool colour.

Evidence standards

Good audit evidence is specific enough for another person to reproduce. For each finding, record:

• exact URL tested
• date and time or reporting date range
• tool and environment
• status code, final URL, directive, canonical, or rendered-content observation
• screenshot or export only when it proves the point
• what the evidence does not prove

Avoid vague findings such as "SEO is bad" or "page not indexed." Replace them with findings like: "/summer-menu is listed in the sitemap, redirects to /menu, and should be removed from the sitemap generation rule." That finding has evidence, a cause, and a testable fix.

Severity examples

Severity should reflect harm and scope:

When unsure, choose the lower severity and explain the uncertainty. Overstating severity makes the audit less useful.

Phase 4 - Prioritise

For each finding include the finding, affected URLs, evidence, reproduction steps, consequence, smallest fix, owner, dependency, change risk, and verification method. Prioritise blockers and signal conflicts before cosmetic metadata refinements.

Repair planning with confidence

Each proposed repair should answer four questions:

1. What exact behaviour will change?
2. What could break if the change is wrong?
3. How will we verify the result?
4. When should we recheck search-engine reports?

For example, changing a URL slug may create more risk than benefit if the current URL is already indexed, linked, and understandable. Updating internal links to point directly to the canonical URL may be lower risk and still improve signal consistency.

Phase 5 - Repair a bounded sample

Implement or describe three fixes: one discovery/link or sitemap fix, one response/directive/canonical fix, and one rendering or structured-data fix. If you lack permission, provide exact implementation instructions and a safe local demonstration instead.

Phase 6 - Retest

Repeat the original test. "Code changed" is not verification. Record actual versus expected results and remaining uncertainty.

Required Final Artefacts

• executive summary of no more than 250 words
• scope and limitations
• URL inventory/evidence sheet
• issue register with severity and proof
• prioritised 30-day repair plan
• before/after evidence for three fixes
• monitoring plan for after deployment, monthly review, and major route/domain changes
• short reflection: "Which assumption did the evidence overturn?"

Assessment Rubric

Passing recommendation: 70/100 overall and at least half marks in Technical accuracy and Evidence quality. A severe privacy or security mistake is an automatic resubmission condition.