Black Swan Bistro - Part 7
Audit the Live Website
Inspect the deployed Bistro before changing code, then record evidence that can guide calm, professional improvements.
Pause Before You Fix
The Bistro is live. That is exciting, but it also changes the job. You are no longer only building pages; you are caring for a public website.
A professional first step is not to start changing colours, moving sections, or chasing every warning. It is to audit the live site, record evidence, and decide what deserves attention.
- What could be different on the live URL compared with your local files?
- Which problems would matter most to a restaurant customer trying to read the menu or make contact?
- What evidence would help you explain an improvement to a client?
This lesson follows Part 6's deployment work. You will use the public Bistro URL as the source of truth and prepare evidence for Part 8.
Learning Objectives
By the end of this lesson, you'll be able to:
- Explain Explain the purpose of a live-site audit before improvement work begins
- Use an audit record to capture repeatable evidence
- Check accessibility, responsive behaviour, performance, SEO, content, links, console output, and maintainability
- Classify findings by impact and urgency
- Separate observations, likely causes, and proposed fixes
- Prepare a shortlist of findings for Part 8
Why This Matters:
An audit is a thinking tool. It slows the work down just enough to protect users, avoid unnecessary changes, and make improvement decisions easier to defend.
Before You Start:
You should be familiar with:
- Black Swan Bistro Part 6: Deploy the Site Review here
- Test and Validate Your Site Review here
- Testing Accessibility as You Build Review here
The Audit Mindset
An audit is not a redesign session. It is a structured look at how the current site behaves for real visitors, search engines, browsers, and future maintainers. The main question is: what can we prove from the live site?
Observe first
Record what happened before deciding why it happened. "Menu image is missing on mobile at 390px" is stronger than "the CSS is bad".
Protect what works
Positive findings matter. If the keyboard order works, headings are clear, or images are well compressed, record that so later changes do not damage it.
Connect to users
Prioritise findings that affect a customer trying to read the menu, understand the venue, contact the restaurant, or use the site on a phone.
Student Resource: Audit Record
Black Swan Bistro live-site audit record
Use this Markdown worksheet while testing the live Bistro URL. It includes the audit checklist, findings table, severity guide, and evidence notes.
A finding should contain five parts
| Part | What to record |
|---|---|
| Location | Page, section, component, link, selector, or file path. |
| Observation | What you saw, heard, clicked, tested, or measured. |
| Impact | Who is affected and why it matters. |
| Evidence | Screenshot name, viewport, tool note, console message, or URL. |
| Next action | Retest, investigate, improve, monitor, or leave unchanged. |
What to Check
You have met most of these topics in earlier lessons. The audit does not reteach all of them; it asks you to apply them to one live site.
| Area | Checks | Useful evidence |
|---|---|---|
| Accessibility | Headings, landmarks, alt text, keyboard focus, link purpose, contrast, form labels, reduced-motion assumptions. | Keyboard notes, screenshots, accessibility tree or inspector notes. |
| Responsive behaviour | Mobile, tablet, desktop, zoom, touch target spacing, line length, image cropping, navigation layout. | Viewport width, screenshot, page section, exact behaviour. |
| Performance | Large images, render-blocking assets, unnecessary JavaScript, layout shift, slow first view, caching clues. | Network panel notes, file sizes, Lighthouse or PageSpeed notes if used. |
| SEO and content | Title, description, one clear H1, useful headings, internal links, image alt text, restaurant details, page intent. | Rendered page notes, page source where useful, metadata screenshots. |
| Links and forms | Navigation, footer links, menu links, contact links, external links, form behaviour, missing destinations. | Clicked path, expected result, actual result. |
| Maintainability | Repeated content, unclear file names, fragile CSS, hard-coded values, comments that no longer match the site. | File path, selector, duplicated text, reason it may slow future changes. |
Severity: Impact Before Preference
Severity is not how much a finding annoys you. It is a judgement about user impact, business impact, technical risk, and how urgently the issue should be handled.
High
Blocks a key task, excludes users, breaks the live site, exposes private information, or creates a serious trust problem.
Medium
Makes an important task harder, weakens search or performance, or risks future breakage if ignored.
Low
Small polish, minor consistency, or maintainability work that can wait until higher-impact items are handled.
If you are unsure, write the uncertainty down. "Likely medium; needs keyboard retest" is more honest than pretending the audit is certain.
Check Your Audit Thinking
Before you begin the full audit, check that your evidence will be useful.
- Why should you audit the deployed Bistro before changing the code?
- What makes a finding useful rather than vague?
- Why should positive evidence be recorded too?
Check Your Answers
- The live site may have hosting, path, asset, routing, metadata, or device behaviour that did not appear locally. Auditing first protects evidence and prevents random changes.
- A useful finding names the page or component, describes the observed behaviour, explains the impact, includes evidence, and suggests a next action without overclaiming.
- Positive evidence shows what should be preserved. It also prevents the audit from becoming a defect hunt that ignores working accessibility, content, or deployment decisions.
How confident are you with this concept?
Still confused | Getting there | Got it | Could explain it to a friend
Guided Practice: Complete the First Audit Pass
Use the record to inspect the live Bistro without making any code changes yet.
Set up the audit record
Download the audit record template, add the deployed Bistro URL, and note the date, browser, viewport sizes, and tester name. Start with facts, not judgements.
Need a hint?
Complete a first visitor pass
Open the site like a visitor: home page, menu, about page, contact page, header links, footer links, and any booking or contact calls to action. Record only observable findings.
Need a hint?
Test three viewport sizes
Check mobile, tablet, and desktop widths. Watch for horizontal scrolling, cramped text, cropped images, hidden navigation, buttons that are hard to tap, or layout shifts while assets load.
Need a hint?
Inspect technical evidence
Use DevTools for Console and Network checks. Record missing files, JavaScript errors, failed image requests, large assets, missing metadata, or anything that changes how the live site behaves.
Need a hint?
You're on track if you can:
- The audit record names the tested live URL and date
- At least one positive finding is recorded
- Findings separate observation, impact, evidence, and next action
- Mobile, tablet, desktop, keyboard, Console, and Network checks are represented
- No code changes are made during the audit pass
Independent Challenge: Produce the Audit Record
Now try this on your own without hints!
Your task
Complete a live-site audit record for Black Swan Bistro. Your goal is not to find the most problems. Your goal is to produce evidence that another person could understand and retest.
Requirements:
- Record the deployed URL, date, browser, and viewport sizes used
- Complete each audit area at least once
- Include at least six findings, with at least one positive finding
- Mark each finding as high, medium, low, monitor, or no action
- Choose three findings to carry into Part 8
Stretch Goals (Optional):
- Add named screenshots or short screen recordings as evidence
- Ask another learner to retest one finding and compare notes
- Add a short paragraph explaining what you will not change yet and why
Success Criteria:
| Criteria | You've succeeded if... |
|---|---|
| Evidence quality | A reviewer can reproduce or understand each finding from the record. |
| Scope control | The audit records findings without turning into unplanned coding work. |
| Prioritisation readiness | Three candidate findings are clear enough to prioritise in Part 8. |
Recap
You now have an audit record for the live Bistro. It should show what works, what needs attention, what evidence supports each finding, and what should happen next. That record is the raw material for Part 8.
Lesson Complete: Audit Before You Improve
Key Takeaways:
- A live-site audit records evidence before code changes begin.
- Good findings are specific, observable, and tied to user impact.
- Accessibility, responsive behaviour, performance, SEO, links, console output, content, and maintainability all belong in the audit.
- Severity is about risk and impact, not personal annoyance.
- Part 8 will turn the audit record into a small, justified improvement plan.
Learning Objectives Review:
Look back at what you set out to learn. Can you now:
- Explain the purpose of a live-site audit before improvement work begins Check!
- Use an audit record to capture repeatable evidence Got it!
- Check accessibility, responsive behaviour, performance, SEO, content, links, console output, and maintainability Can explain it!
- Classify findings by impact and urgency Could teach this!
- Separate observations, likely causes, and proposed fixes Check!
- Prepare a shortlist of findings for Part 8 Got it!
If you can confidently answer "yes" to most of these, you're ready to move on!
Think & Reflect:
Judgement
- Which finding matters most for a real visitor, and why?
- Which finding is tempting but should wait?
Evidence
- Could someone else retest your top finding from your notes?
- What evidence do you wish you had captured more clearly?
Looking Ahead:
Continue to Part 8, where you will prioritise the audit findings, make a small set of deliberate improvements, test before and after, and record the work in an improvement log.
Recommended Next Steps
Continue Learning
Ready to move forward? Continue with the next tutorial in this series:
Black Swan Bistro — Part 8 (Prioritise and Improve)Additional Resources
Deepen your understanding with these helpful resources:
- web.dev: Lighthouse - Audit your site for performance, accessibility, and SEO.