Website Audit

1. 1

   Language and tone

   Shared

   Keeps the answer clear, positive and understandable. It prevents the AI from hiding simple ideas behind jargon or presenting useful criticism as a fault-finding exercise.

   language-and-tone.partial

   1

   Write in clear, unambiguous, plain English.

   2

   Assume the reader runs a business and may have no specialist knowledge of marketing, websites, search engines, analytics or social media.

   3

   Do not use jargon when an ordinary word or short phrase will do.

   4

   If a technical or specialist term is genuinely necessary, use the term, explain it immediately in plain English, explain why it matters here, and provide a reliable reference confirming the meaning.

   5

   Keep the framing positive, balanced and constructive.

   6

   Where something is working, say so before describing the issue or risk that remains.

   7

   Do not soften a serious issue so much that it becomes unclear.

   8

   The aim is to eliminate ambiguity and create clarity.

2. 2

   Evidence and certainty

   Shared

   Stops the AI from presenting guesses as facts. It makes the report show what was actually found, what is a reasonable interpretation, and what could not be confirmed.

   evidence-and-certainty.partial

   1

   Use publicly available information you can actually find.

   2

   For important factual claims, provide the source used to confirm them.

   3

   Clearly distinguish between Observed, Inferred and Not verified.

   4

   Never present an inference as a confirmed fact.

   5

   Do not invent missing information.

   6

   Do not imply that you tested, visited, clicked, searched or verified something unless you actually did.

   7

   Do not treat absence from search results as proof that something does not exist.

3. 3

   Source hierarchy

   Shared

   Encourages the AI to use the most reliable explanation available instead of casually relying on marketing blogs or unsupported opinion.

   source-hierarchy.partial

   1

   Prefer references in this order:

   2

   1. Official provider or platform documentation where the subject relates to a specific service or product.

   3

   2. A recognised neutral reference such as Wikipedia for general concepts.

   4

   3. Another authoritative source only when the first two are not suitable.

4. 4

   First 30 seconds

   Tests what a new visitor can understand almost immediately.

   first-impression.partial

   1

   Assess what the homepage of [WEBSITE] communicates in the first moments of a visit.

   2

   Can a new visitor understand what the business does, where it operates, who it serves and what to do next?

   3

   Judge this from the perspective of [MAIN CUSTOMER].

   4

   Separate unclear wording from missing information.

5. 5

   Can people find what they need?

   Looks at menus, page structure and information placement in plain customer terms.

   information-architecture.partial

   1

   Check whether common customer questions can be answered without unnecessary searching.

   2

   Look at navigation labels, page grouping and obvious dead ends.

   3

   Do not turn this into a formal information-architecture study.

6. 6

   Mobile experience

   Checks whether the site remains practical for people using a phone.

   mobile.partial

   1

   Review visible mobile usability: layout, text size, tap targets, menus, forms, contact actions and obvious overflow or obstruction.

   2

   Use actual observed behaviour where available and avoid claiming device coverage you did not test.

7. 7

   Words, offers and explanations

   Checks whether the copy answers customer questions clearly rather than sounding impressive but vague.

   content-clarity.partial

   1

   Look for unclear headlines, unexplained jargon, vague claims, missing prices or process information where relevant, and unanswered customer questions.

   2

   Highlight strong clear wording as well as weak areas.

8. 8

   Trust and reassurance

   Looks for the signals that help a visitor believe the business is real, current and safe to deal with.

   trust.partial

   1

   Review contact details, location, team or business identity, reviews, testimonials, policies, photographs, credentials and other relevant trust information.

   2

   Do not treat every possible trust signal as mandatory.

9. 9

   Can the customer take the next step?

   Checks whether calling, booking, visiting, buying or enquiring is obvious and easy.

   actions.partial

   1

   Treat [WEBSITE GOAL] as the main intended customer action.

   2

   Check whether that action is visible, understandable and usable throughout the relevant journey.

   3

   Flag unnecessary steps or competing calls to action.

10. 10

    Forms and contact routes

    Looks at visible friction in contact and enquiry processes without submitting anything.

    forms-and-contact.partial

    1

    Review public forms and contact routes without submitting them.

    2

    Look for unnecessary fields, unclear expectations, missing confirmation information or inaccessible alternatives.

11. 11

    Accessibility basics

    Flags obvious barriers without pretending to perform a formal accessibility conformance audit.

    accessibility-basics.partial

    1

    Look for obvious accessibility concerns visible through normal use, such as weak contrast, missing labels, keyboard-obvious issues, unreadable text or meaningful images lacking useful text alternatives where inspectable.

    2

    Explain accessibility terms in plain English and reference authoritative guidance.

    3

    Recommend a dedicated accessibility audit where appropriate.

12. 12

    Speed and obvious technical friction

    Checks practical visible performance problems without becoming an engineering benchmark exercise.

    performance-basics.partial

    1

    Note clearly observable slow loading, layout movement, broken assets or other user-visible technical friction.

    2

    Use provider or browser tooling only where appropriate and explain what the measurement means.

    3

    Do not overstate small synthetic-score differences.

13. 13

    Obvious technical flags

    Surfaces things like broken links, insecure connections or certificate warnings without probing the system.

    technical-flags.partial

    1

    Check for obvious public-facing technical issues such as broken links, missing pages, certificate warnings or mixed secure/insecure content.

    2

    Do not probe endpoints, scan vulnerabilities or attempt security testing.

14. 14

    Finding format

    Shared

    Gives every finding the same useful structure. The reader sees what is already working, what may need attention, the evidence, why it matters and exactly what can be done next.

    positive-finding-format.partial

    1

    Report each finding using these headings, in this order:

    2

    - Finding: A short plain-English description of the issue or opportunity.

    3

    - Status: Shows whether the finding was directly observed, reasonably inferred, or could not be fully verified.

    4

    - What is working: Recognises useful things already in place so the review remains balanced and does not manufacture faults.

    5

    - What may need attention: States the issue clearly and proportionately in plain English.

    6

    - Evidence: Shows the page, profile, search result, listing or other source supporting the finding.

    7

    - Why this matters: Connects the finding to a real customer or business consequence.

    8

    - How to put it right: Provides a practical step-by-step route to improvement rather than vague advice.

    9

    - References for the fix: Provides reliable guidance supporting the recommended process.

    10

    - Effort: Uses Small, Moderate or Larger to give a rough sense of the work involved without inventing precise cost or time estimates.

15. 15

    Recommendation discipline

    Shared

    Prevents the AI from defaulting to rebuilds, subscriptions or fashionable tools when a smaller change would solve the problem.

    recommendation-discipline.partial

    1

    Prefer simple, realistic improvements over large projects.

    2

    Fix or improve what already exists before recommending replacement.

    3

    Do not recommend a paid product, subscription, redesign, rebuild or new platform simply because one exists.

    4

    Keep recommendations proportionate to the business and the evidence found.

    5

    Do not create an exhaustive improvement list when a smaller set of meaningful actions will do.

16. 16

    What should be fixed first?

    Separates meaningful customer-impacting changes from cosmetic improvements.

    priorities.partial

    1

    Prioritise issues by customer impact and practical effort.

    2

    Prefer fixing blockers and confusion before cosmetic refinement.

17. 17

    Action prioritisation

    Shared

    Turns a long analysis into a small number of useful next steps. You should finish knowing what to do first, not merely knowing what is wrong.

    action-prioritisation.partial

    1

    Finish with the three actions most worth considering first.

    2

    For each action include what to do, why it comes before the other findings, the first practical step, and the best supporting reference.

    3

    Prefer small, realistic improvements where they can produce a meaningful result.

18. 18

    Something useful I learned

    Shared

    Adds the quiet educational layer. Instead of delivering a lecture, the prompt explains one useful marketing, customer-experience or technology concept that arose naturally from the work.

    teaching-note.partial

    1

    Briefly explain one marketing, customer-experience or technology concept that arose naturally from this review.

    2

    Explain what it means, why it matters to this particular business, and provide one reliable place to learn more.

    3

    Keep this short and practical.

    4

    Do not turn the report into a lesson.

19. 19

    Research boundaries

    Shared

    Defines what the AI must not do. It keeps a broad review from quietly becoming security testing, legal advice, invasive research or an unrelated technical audit.

    research-boundaries.partial

    1

    Stay within the stated purpose of this prompt.

    2

    If something deserves deeper investigation, identify it, explain why it may matter, and recommend the appropriate deeper review instead of attempting that entire review here.

    3

    Do not perform vulnerability scanning, penetration testing, endpoint probing, login attempts or other security testing.

    4

    Do not submit forms, make bookings, place orders, contact the business or change anything.

    5

    Do not claim legal or regulatory compliance or non-compliance from a broad review.

    6

    Do not guess private information such as revenue, profitability, customer numbers, budgets, internal systems, staffing or business plans.

    7

    Do not infer motives, competence or intentions of owners, staff, agencies or competitors.

20. 20

    Limits of this particular prompt

    The boundaries that apply to this prompt specifically, on top of the general research limits.

    scope-notes.partial

    1

    Do not perform penetration testing, vulnerability scanning or invasive technical testing.

    2

    Do not claim formal WCAG, legal, SEO or security compliance.

    3

    Do not redesign the site in this prompt; identify what deserves redesign and why.

SharedSections marked shared are the same in every prompt in the library. The rules on tone, evidence, recommendations and limits are deliberately identical wherever you meet them, so you only have to learn them once — and so no prompt can quietly hold itself to a lower standard than the others.