100 Site Errors Costing Businesses $$$ | Website Audit Service Experts

A website audit should turn observed problems into a useful order of work. It should explain what was checked, what failed, why it matters and how the correction will be verified. A long report is not valuable simply because it contains a large number of warnings.

This guide covers 100 checks across discovery, performance, usability, content, accessibility, security, measurement and operations. Use it as a reference for the areas relevant to your site. Not every finding applies to every platform, and no item carries a guaranteed traffic or revenue uplift.

What a useful audit establishes

An SEO audit concentrates on search-related issues, while a broader website review can also examine tasks, editing workflows and operational reliability. Define the scope before commissioning the work. A crawler report is not a complete accessibility, security or conversion assessment.

Begin with the site's purpose and important journeys. For a service business, follow an enquiry through to the team receiving it. For a shop, review product selection and the order handover. Identify valuable existing content and URLs so that improvements do not discard what already works.

Prioritise by consequence and confidence, not by adding speculative percentages. Security incidents and blocked essential tasks may require immediate attention. Cosmetic refinements can follow once the important routes work. The review schedule should reflect changes and risk rather than an arbitrary rule for every website.

1. Technical SEO and discovery

These checks ask whether the intended public content can be reached and understood. Make changes in context: a directive that is wrong on a service page may be correct on a private or duplicate resource.

1. Broken internal links

Follow links from important pages and compare their destinations with the intended journey. A crawl can reveal failures, but review the source page before choosing a fix. Correct a mistyped link directly; preserve an old URL with an appropriate redirect only when there is a genuine replacement. Do not redirect every missing page to the homepage. Recheck the actual link after the change, including its label, because a working destination can still be the wrong one for the reader.

2. Redirect chains

A chain sends a request through intermediate addresses before reaching the final page. Identify repeated hops and update internal links to the intended destination where practical. Simplify redirects with awareness of the old addresses that external visitors may still use. Keep a record of the mapping and test it after deployment. The aim is a dependable route, not an unsupported claim that every extra hop loses a fixed amount of ranking value.

3. Missing pages on important journeys

Review missing URLs that receive visits, appear in navigation or have relevant external references. A genuine removed page can return an appropriate not-found response; not every 404 is an error to eliminate. Where useful replacement content exists, decide whether a redirect is appropriate. Improve the not-found page so people can recover. Keep the HTTP response accurate rather than disguising every missing resource as a successful page.

4. Conflicting canonical information

Canonical information identifies a preferred version among duplicate or very similar pages. Check whether a template accidentally points unrelated pages to one address, and compare the declared preference with internal links and sitemap entries. A canonical is not a substitute for access control or an instruction guaranteed to be followed in every circumstance. Investigate the actual duplication before changing all pages. Distinct products should not be collapsed into a category merely to make a report look cleaner.

5. Parameter URLs without a clear purpose

Parameters can represent tracking, sorting, filtering or genuinely different content. Classify them before deciding how they should be linked, crawled or indexed. Do not automatically strip every parameter or canonicalise all filtered results to a page that does not represent them. Keep useful customer functionality intact. A documented policy helps developers avoid generating unnecessary URL variants while allowing meaningful states to remain available.

6. Incorrect language relationships

For multilingual or regional content, check that equivalent pages are paired accurately and that language annotations use supported values. Review return references and each page's own entry. An x-default value can identify an appropriate fallback; its absence is not automatically an error for every site. Do not connect unrelated pages simply because they share a language. Test the human language-switching journey as well as the technical annotations.

7. Unintended indexing restrictions

Inspect page-level and HTTP-header directives on content that should appear in search. A development noindex setting can be left behind at launch. Remove it only where public indexing is intended, and verify the served response afterwards. Nofollow and noindex describe different controls and should not be treated as interchangeable. Keep deliberate restrictions on pages that need them, and record the reason so a future cleanup does not reverse the decision blindly.

8. Robots rules blocking intended crawling

Review robots.txt against the public sections the site expects crawlers to fetch. A broad development rule can accidentally remain active. At the same time, robots.txt is not a reliable way to keep confidential information private or guarantee removal from search. A crawler must be able to access a page to see its noindex instruction. Coordinate those controls rather than combining them without understanding the effect.

9. Stale or misleading sitemaps

A sitemap should help identify the public URLs you want discovered. Check for removed pages, unintended variants and entries that disagree with the site's preferred URLs. Review how the CMS generates updates and whether the submitted sitemap remains accessible. Inclusion does not guarantee indexing. A clean sitemap supports discovery, but it does not replace useful navigation or repair a page that search engines cannot otherwise access.

10. Useful pages with no internal route

Compare the content inventory with the pages reachable through navigation and contextual links. A valuable article or project can become isolated after a redesign. Add a relevant route from the appropriate hub or related explanation, using a label that describes the destination. There is no universal quota of links that every page must receive. The objective is an understandable connection for readers and crawlers, not a mechanical number.

11. Pagination that hides deeper content

Check how visitors and crawlers reach items beyond the first list view. Infinite scrolling may need another discoverable route. Review the URLs and links for later pages, and avoid pointing every distinct page of results to page one as though the content were identical. Test returning from an item to the list. A technically available second page can still be frustrating if the user's place is repeatedly lost.

12. Essential content dependent on fragile rendering

Inspect what is delivered and what appears after scripts run. JavaScript is not inherently incompatible with search, but failures or delayed dependencies can prevent important content from appearing. Use real links for navigation and test the rendered result with suitable tools. Server rendering or static generation may be appropriate, but should follow the architecture and problem rather than be prescribed automatically. Confirm the actual content remains available under the expected conditions.

13. Unbounded filter combinations

Faceted navigation can create many combinations that provide little distinct search value. Identify which states are useful public destinations and which mainly serve an interactive task. Choose crawling and indexing controls deliberately, using current guidance and the site's architecture. Do not apply noindex behind a crawl block and assume it will be read. Check empty results, repeated parameters and impossible combinations as part of the investigation.

14. Inconsistent URL variants

Review casing, trailing slashes and protocol variants where they produce duplicate routes unintentionally. Choose a consistent supported form and align internal links with it. Do not rename established slugs merely to impose a new aesthetic convention. If a change is necessary, test the mapping and preserve meaningful old routes. The audit should reduce ambiguity without creating an unnecessary migration project.

Archived companion: Download ERROR List [PDF]. This older PDF is retained for reference; its uplift estimates and some technical recommendations are superseded by the contextual guidance in this article.

2. Performance and responsiveness

Measure representative pages under relevant conditions. Loading, interaction and stability are related but different. A better laboratory score does not by itself establish a commercial result or describe every real user's experience.

15. Slow initial server response

Investigate the time before the server begins responding and compare relevant regions and page types. The cause may involve application work, database queries, caching or infrastructure. A CDN can help some workloads but does not repair every slow origin process. Use measurements to identify the bottleneck before changing hosting. Recheck both anonymous and signed-in behaviour where relevant, because the caching and processing paths may differ.

16. A delayed main visual or content element

Identify the element contributing to the largest contentful paint on the page being tested. It may be an image or text, and it may change across layouts. Review discovery, file size and competing work. Avoid lazy-loading an important initial image without assessing the effect. Preload or priority hints should solve an observed problem, not be added to every asset. Confirm the change in a comparable test.

17. Stylesheets delaying useful rendering

Inspect stylesheet loading and the amount of CSS needed by the current page. Removing unused rules or changing delivery can help, but careless deferral may produce unstyled content or layout changes. Test the actual appearance during loading as well as the final state. Shared styles may be useful across the site, so do not delete them solely because one page does not use every rule. Keep the implementation maintainable.

18. Scripts blocking page processing

Review where scripts load and which dependencies they require. Deferred and asynchronous execution have different ordering behaviour; applying them indiscriminately can break functions. Load optional features only where they are needed and remove obsolete dependencies after checking their purpose. Verify menus, forms and other key interactions after any delivery change. A faster initial render is not a successful fix if the action the visitor needs stops working.

19. Images larger than their useful display

Compare delivered dimensions and file size with the role of the image. Resize and compress appropriately, then inspect the result for lost detail or artefacts. A diagram with small text may need different handling from a photograph. Modern formats can be useful, but no single quality setting suits every image. Preserve originals appropriately and establish a repeatable preparation process so later uploads do not recreate the problem.

20. Missing space for images and embeds

Reserve suitable space using accurate dimensions or aspect ratios so content does not jump when media arrives. Test responsive crops and embeds with variable sizes. Avoid simply fixing a height that cuts off important content on another screen. Watch the page during loading and interaction, not just after it settles. A stable layout helps people keep their place and reduces the chance of activating a moving control.

21. Font delivery that disrupts reading

Review the number of font files, required character coverage and loading behaviour. A sensible fallback should remain readable while custom fonts arrive. Subsetting can reduce transfer size, but must retain characters needed by the content and languages. Preloading every weight can compete with other resources. Test wrapping and layout movement as well as whether the preferred font eventually appears. The best choice balances readability, performance and the visual system.

22. Long work delaying interaction

Profile a slow interaction to identify work occupying the browser's main thread. Reduce unnecessary computation and consider yielding between appropriate chunks or moving suitable work to a worker. Merely splitting code into microtasks does not necessarily allow rendering or input handling to proceed. Test the actual interaction again after the change. Avoid introducing complex scheduling when removing redundant work would solve the problem more simply.

23. Third-party tools with no current owner

Inventory analytics, chat, marketing and embedded services. Record who needs each one and what happens if it is removed. Duplicate or abandoned tags can add work and complicate data handling. Scope services to relevant pages where appropriate and test the effect of delayed loading. A tool should not remain indefinitely simply because nobody remembers who installed it. Confirm the business function before removing an active dependency.

24. Ineffective browser caching

Review cache behaviour for static assets and changing content separately. Versioned files can often use a different policy from personalised responses. Do not apply a public long-lived cache rule to private or user-specific information. Test how an update reaches returning visitors and how stale assets are replaced. The objective is efficient repeat loading without displaying the wrong version or exposing content to the wrong person.

25. Delivery protocol or connection problems

Check the protocols and connection behaviour supported by the hosting and delivery services. Improvements may be available through provider configuration, but confirm the actual bottleneck and compatibility needs. HTTP versions do not guarantee a particular speed result, and every leg of the delivery path need not use the same protocol. Compare the relevant experience before and after a change rather than using a protocol label as a performance score.

26. Resource hints without evidence

Preconnect and preload can help important resources become available sooner when used carefully. Review whether a hinted resource is genuinely needed early and whether the browser requests the same asset twice because the attributes disagree. Remove unnecessary hints that compete with more important work. Test the loading sequence on representative pages. A long list of preloads can be less useful than making the main content easy to discover normally.

27. Animation causing repeated layout work

Inspect effects that run during scrolling or pointer movement. Repeated measurements and style changes can create unnecessary work. Prefer a simpler implementation where it delivers the same useful feedback, and test reduced-motion behaviour. Do not apply will-change to large numbers of elements without a reason. The final assessment should include comfort, control and responsiveness, not only whether the animation appears smooth on one powerful machine.

28. One oversized image for every screen

Where the implementation supports responsive images, provide appropriate candidates and accurate sizing information. Check which resource the browser actually chooses. An incorrect sizes value can undermine an otherwise well-prepared set of files. Preserve the detail needed by the content and test high-density displays as well as narrow screens. Responsive delivery should reduce unnecessary transfer without making evidence screenshots or product details unreadable.

Archived companion: Download ERROR List [PDF]. Use the current article's explanations rather than the PDF's speculative growth percentages.

3. Usability and meaningful actions

Follow real tasks from the first relevant page through the result. The purpose of these checks is to reduce confusion and failure, not to pressure every visitor into an action they did not intend.

29. An unclear service explanation

Ask whether a new visitor can explain what is offered, who it serves and what the next step involves. Vague slogans may need supporting context rather than a larger font. Use language grounded in the actual service and avoid adding unsupported outcomes to make the headline sound stronger. Test the explanation with someone unfamiliar with the business. Their interpretation is more useful than an internal vote on which phrase sounds most impressive.

30. An action that is hard to identify

Review the relevant button or link in its surrounding content. It should be visually identifiable and describe the action accurately. More contrast can help, but it cannot resolve wording that promises a different result from the destination. Follow the link and complete the task. Keep alternatives available when they support an informed decision, without giving every option identical visual emphasis regardless of its role.

31. Competing requests throughout a page

A page can ask visitors to subscribe, chat, book, download and buy before explaining why any action is useful. Identify the main purpose and place relevant next steps at natural decision points. Secondary routes do not always need another large button. Review the page as a continuous explanation. The solution may be a clearer sequence rather than a rigid rule allowing only one action across the entire screen.

32. Unnecessary form effort

Examine why each field exists and whether it is needed at this stage. A complex service may justify more context, but the form should explain the request and help the person complete it. Use appropriate autocomplete and input behaviour where suitable. Test with realistic information and on a phone. Removing fields indiscriminately can leave the team unable to respond, so balance effort with the actual purpose.

33. Errors that do not explain recovery

A validation message should identify the problem and help the person correct it without losing unrelated work. Associate the message with the field and make it available through the relevant assistive technology. A format example such as name@company.com can help where appropriate, but do not reject valid personal addresses merely because a form is aimed at businesses unless there is a genuine requirement. Test both client and server responses.

34. Unsupported reassurance

Review testimonials, ratings, guarantees and logos for accuracy and context. A genuine example relevant to the service is more useful than an unexplained badge. Confirm permission and the scope of any claim. Do not invent a review total or a service promise to fill a design component. Place evidence where it answers a likely question, and remove decorative reassurance that creates an impression the business cannot substantiate.

35. Navigation labels that require guessing

Compare the menu's wording with the terms visitors use for their task. Internal labels can make sense to staff while confusing everyone else. Group related destinations and check that a link leads where its label suggests. Test deeper pages as well as the homepage. There is no fixed number of menu items that suits every site; the structure should reflect the content and make important routes recognisable.

36. Interruptions that obscure the content

Review pop-ups, banners and overlays together, particularly on a phone. Check whether they cover essential information, trap focus or make closing difficult. Delaying an intrusive message by a few seconds does not automatically make it useful. Consider a less disruptive placement or whether the message is needed at all. Preserve required controls and information while making the reading journey understandable and easy to resume.

37. Fixed controls that create new obstacles

A sticky action can be useful on some long pages, but it may cover content, errors or other controls. Test the combined layout with the on-screen keyboard, consent interface and chat button visible. Make sure the fixed element does not consume an unreasonable share of the screen. Its value should be assessed through the task it supports, not assumed from a generic conversion claim.

38. Sections with no readable hierarchy

Use headings to show the structure and paragraphs to develop related ideas. A list can clarify parallel choices, but turning every sentence into a bullet or card fragments the explanation. Review the line length and spacing with real content. Keep the main argument open rather than hide it behind repeated accordions. The reader should be able to scan for a relevant section and then follow its explanation comfortably.

39. Pricing without enough context

Check whether a visitor can understand what is included, what changes the price and what recurring costs may apply. A starting figure needs assumptions; a bespoke quote needs a clear process. Use comparisons only for genuinely comparable attributes. Avoid forcing a service into three packages merely because the template contains three columns. The presentation should help the customer judge fit without implying certainty the business cannot yet provide.

40. Inputs poorly suited to the information

Use field behaviour that helps people enter the required value, and test it on relevant devices. A telephone number is not an arithmetic quantity, so a number input may be inappropriate. Consider international formats and valid variations before imposing a mask. Autocomplete can help with familiar information, but its configuration should match the field's actual purpose. The goal is fewer avoidable corrections, not a visually tidy but restrictive form.

41. Small text that makes a false promise

Review the wording around forms, prices and buttons. “Cancel anytime”, “instant quote” and “reply within an hour” are operational promises, not decorative phrases. Confirm that the business can honour them and explain relevant conditions clearly. Replace vague reassurance with useful information where possible. A small line of copy can materially change a visitor's expectation, so include it in content approval rather than treating it as a design detail.

42. No useful route after the current task

A page should make relevant next information available without forcing another action. An article may link to a deeper explanation or a related service. A confirmation page should first confirm what happened and what to expect. Do not distract from an essential acknowledgement with a collection of unrelated promotions. Follow the complete journey and check whether the next step helps the person rather than merely extending their time on the site.

Archived companion: Download ERROR List [PDF]. The original checklist is retained as a historical download, not a forecast of results.

4. Content and information structure

Content quality is about answering the relevant question accurately and usefully. Word counts, component counts and keyword repetitions are poor substitutes for that judgement.

43. Content that leaves the main question unanswered

Identify what the page promises and whether it delivers enough information to satisfy that purpose. A short page is not automatically thin, and a long one is not automatically helpful. Add missing explanation, evidence or examples where they improve understanding. Do not pad the page with generic sections just to meet a supposed ranking length. Review the resulting journey and make the next useful source of detail easy to find.

44. Information that is no longer accurate

Check prices, features, dates, screenshots and external references against appropriate current sources. A cosmetic date change does not refresh the substance. Preserve historical examples when useful, but label their context accurately. Assign an owner to information likely to change. If a screenshot is retained as an archive, avoid presenting it as proof of today's interface or capabilities. Record the meaningful changes made during the review.

45. A page that answers a different intent

A visitor seeking an explanation may be disappointed by a page that only sells a service. Review the query or route that brought them and the question the content actually answers. Search results can provide context, but copying the leading pages' structure is not a substitute for original useful content. Clarify the purpose and offer an appropriate next step. Avoid claiming every mismatch can be diagnosed from a bounce rate alone.

46. Internal links without a useful relationship

Links should connect the explanation to relevant detail. Review vague labels, accidental duplicates and references that now point to unrelated pages. Preserve valuable established links when refreshing content, and place them where the relationship remains clear. There is no fixed quota of service links an article needs. A natural connection helps the reader; a forced insertion can interrupt the argument and make the page less trustworthy.

47. Overlapping articles with no clear role

Map related content and identify whether each page answers a distinct question. A useful overview can connect supporting explanations, but a topic cluster does not need an arbitrary number of articles. Avoid creating near-duplicates solely to fill a content plan. Where pages overlap, review their traffic, links and purpose before considering consolidation. Protect established URLs and document any necessary change rather than deleting content because a spreadsheet looks crowded.

48. Headings chosen only for appearance

Headings should express the relationship between the page and its sections. Use styles to control visual size rather than selecting a deeper heading level because it looks smaller. Review the outline with the surrounding template, including the page title. A meaningful hierarchy helps readers and assistive technology navigate the content. Avoid making every bold phrase a heading, and check that section titles describe the explanation that follows.

49. Titles that do not distinguish pages

Check whether page titles accurately identify their individual purpose. Repeating “Bespoke Web Design Agency” across unrelated pages can make them difficult to distinguish. Write specific wording without stuffing multiple near-identical phrases into the title. Descriptions should also reflect the actual content, while recognising that search engines may display a different snippet. Review the template that generates metadata so the next new page does not inherit the same mistake.

50. Archives that provide no orientation

A chronological feed can work for regular readers, but a newcomer may need guidance by subject or task. Consider a short introduction and curated routes where they help. Keep labels and summaries accurate and maintain the selection over time. Do not add a hub page merely to repeat links already available elsewhere. Its purpose is to help someone understand the available material and choose a useful starting point.

51. Categories and tags without a purpose

Review empty archives, inconsistent names and tags that differ only slightly. Decide which classifications help readers find related material and which create unnecessary maintenance. A single-item category is not automatically an error if it serves a clear purpose. Before removing or merging an archive, check its existing use and links. Choose indexing and redirect behaviour deliberately rather than applying the same rule to every low-count category.

52. Attribution that overstates expertise

Provide accurate information about who wrote or reviewed content where it helps readers assess the source. Do not invent credentials, a reviewer or first-hand experience. A biography should explain relevant responsibilities rather than function as a ranking badge. For specialist topics, establish the appropriate review process and keep it meaningful. An “updated” or “reviewed” label should reflect work that actually took place, with an accountable person or process behind it.

53. Lists that are difficult to explore

Test finding an older article or a specific kind of project in a long archive. Filters, search or pagination may help, depending on the content. Use clear empty states and a way to recover from an overly narrow selection. Check keyboard behaviour and the route back from an item. Do not add every possible filter when a few meaningful choices would make the task easier.

54. Structured data based on outdated promises

Use supported structured data that accurately represents visible content and satisfies the relevant requirements. Validate it, but do not confuse valid markup with guaranteed search treatment. Google's supported rich results change; FAQ and HowTo markup should not be sold as an automatic route to extra search features. Keep implementation aligned with current documentation and the page's real content. A tool-generated block still needs editorial and technical review.

Archived companion: Download ERROR List [PDF]. Check current search documentation before applying its older structured-data recommendations.

5. Accessibility and readable interaction

Accessibility review should include real tasks and the way the site is implemented. Automated checks are useful but incomplete. Record what was assessed and avoid declaring the whole site compliant from a single score.

55. Insufficient contrast in important states

Check text, controls and relevant visual states against the applicable contrast requirements. Review text over images across the actual crops, not only a carefully chosen preview. A translucent overlay may work in one area and fail over a bright detail elsewhere. Include focus and selected states. Do not rely on colour alone to communicate an error or status. The result should remain understandable when the visual distinction is not perceived as intended.

56. Image alternatives that miss the purpose

An informative image needs an alternative that communicates its relevant role, while decorative imagery may need an empty alternative. A complex chart may require a fuller explanation near the image. Avoid filenames, keyword lists or descriptions that repeat surrounding text without helping. Check what the reader needs to understand if the image is unavailable. The right treatment depends on context, so a media-library field cannot always be reused unchanged everywhere.

57. Controls built from inappropriate elements

Use elements that match the action: links for navigation and buttons for actions. A clickable container does not automatically provide the keyboard behaviour or meaning of a native control. If a custom component is necessary, implement and test its full behaviour rather than adding a role and assuming the work is complete. Review activation, focus and accessible naming. A visually clickable surface should function for people using other input methods.

58. Focus that disappears or becomes trapped

Follow the interface with a keyboard and observe where focus moves. Modal dialogs need appropriate focus handling and a way to close and return to the initiating context. Ordinary navigation menus do not all need the same trapping behaviour as a modal. Hidden controls should not unexpectedly remain in the tab sequence. Test the actual component pattern and preserve a visible indication of the current position.

59. Form labels and errors without association

Visible labels help people understand fields after typing begins, unlike placeholder text that disappears. Ensure the programmatic association matches the visible meaning. Connect relevant instructions and errors appropriately, using correct attributes such as aria-describedby when needed. Preserve entered information and avoid announcing the same error repeatedly through several mechanisms. Test with the relevant assistive technology as well as visually. A form can look labelled while still lacking a usable association.

60. Reading order that changes the meaning

Compare the underlying content sequence with the meaningful visual order. CSS positioning can make a page look logical while keyboard or screen-reader navigation follows a confusing route. Keep related explanations and controls together. A responsive layout may change placement, but should preserve an understandable sequence. Test expanded panels and dynamic content as well as the initial page. The goal is equivalent comprehension, not a superficial match of coordinates.

61. Targets that are difficult to activate

Review small controls and crowded links on actual devices. WCAG 2.2's minimum target criterion uses 24 by 24 CSS pixels with defined exceptions; the enhanced criterion uses a different standard. Larger comfortable targets can be a useful design choice, but do not misstate one measurement as the universal requirement. Check spacing, overlap and the practical task. An icon's visible size and its usable activation area are not necessarily identical.

62. Status changes available only visually

A successful submission, updated result count or added item should be understandable without watching a small visual toast. Use appropriate programmatic status communication and manage focus where the interaction requires it. Avoid making every update an urgent alert. Excessive or duplicate announcements can be disruptive. Test the sequence from the action through the resulting state, including whether the person can continue the task without losing their place.

63. Motion without a usable alternative

Review auto-rotation, looping media and large movement effects. Provide relevant controls and respect reduced-motion preferences. A reduced-motion version should remain understandable and functional, not simply remove information. Consider whether the movement has a useful purpose at all. Test stopping and resuming where appropriate. The aim is to let people access the content comfortably rather than require them to tolerate a particular animation to complete a task.

64. Media without appropriate alternatives

Plan captions, transcripts and descriptions according to the content and applicable requirements. Captions represent meaningful audio; they do not automatically explain an essential action that is only visible. Review automatic captions for names, terminology and timing. Check that the player exposes the alternatives and controls properly. A transcript can be useful for reference, but its presence alone does not establish that every accessibility need of the recording has been met.

65. Missing routes around repeated content

Use meaningful page regions and appropriate navigation aids so people can move through the site efficiently. A skip link should lead to the intended content and become available when needed. Avoid creating a large number of redundant landmarks that makes navigation noisier. Review the surrounding template as well as the article body. A well-structured page helps people reach the relevant explanation without repeatedly traversing unrelated controls.

66. Content lost at narrow widths or zoom

Test reflow and text enlargement under the relevant conditions. Look for clipped text, overlapping controls and containers that hide overflow instead of solving it. Some content, such as a genuinely two-dimensional data table, may need a suitable local scrolling treatment. Do not let that create horizontal scrolling across the whole page. Check that the task remains possible and that the reading order still makes sense after the layout changes.

Archived companion: Download ERROR List [PDF]. Use current accessibility guidance and a scoped assessment rather than treating the PDF as a compliance certificate.

6. Security and data responsibilities

Security work needs appropriate expertise and a defined scope. These checks identify questions to investigate, not a guarantee that a site is secure. Assess legal requirements against the actual data and activities involved.

67. Insecure transport or mixed resources

Confirm that the intended site and its resources load through an appropriate secure connection. Investigate mixed-content warnings and outdated references. HTTPS protects transport but does not establish that the application is trustworthy or free of vulnerabilities. Plan settings such as HSTS carefully, including their effect on subdomains, rather than enabling irreversible commitments without preparation. Recheck after hosting or CDN changes and assign responsibility for the configuration.

68. Certificate renewal without ownership

A certificate can expire even when the website's content has not changed. Confirm how renewal is handled, who receives failure alerts and which domains are covered. Test the alert route rather than assume an old administrative inbox is monitored. Use appropriate provider guidance for the supported configuration. A high score from a certificate-testing service is useful evidence within its scope, not a complete application-security assessment.

69. Security headers added without testing

Review relevant browser protections with the implementation's requirements in mind. A content security policy can help constrain resource execution, but an unsuitable policy can break forms or integrations. Use a considered rollout and investigate reports before enforcement where appropriate. Avoid copying a generic header block without understanding it. Record the intended configuration and recheck it when scripts, hosts or embedded services change.

70. Weak administrative access controls

Identify who can access administration and what privileges they need. Use suitable authentication, account recovery and protection against abusive attempts. Changing an admin URL is not a replacement for those controls. Review inactive accounts and shared credentials, and establish a process for departures. Restrictions must fit the team's legitimate access needs. The audit should verify the actual account configuration rather than infer security from an unfamiliar login address.

71. Dependencies without a maintenance process

Inventory important software, extensions and custom components. Track relevant provider advisories and assign someone to assess and apply updates. An abandoned dependency may need replacement, but investigate its role before removing it. Test changes proportionately and respond to urgent vulnerabilities according to the risk. A fixed monthly review alone may be insufficient for a serious active issue. Keep enough documentation for another maintainer to understand the system.

72. Forms protected only in the browser

Client-side validation can help users, but the server must also handle untrusted input appropriately. Review authentication, request handling, rate limits and other protections relevant to the action. Anti-bot services do not replace application security, and a CAPTCHA can introduce usability barriers. Test the intended protection without obstructing legitimate submissions unnecessarily. The exact controls depend on the architecture and should be reviewed by the responsible technical team.

73. Privacy information that does not match practice

Compare the stated data uses with the website's actual forms, tools and integrations. A generic policy may omit important processing or describe services no longer used. Establish the appropriate owner and review process. Do not assume every organisation must appoint a data protection officer, or that a policy alone establishes compliance. The business needs an accurate account of its responsibilities and a workable route for relevant enquiries and rights requests.

74. Storage and tracking behaviour not assessed

Inventory cookies and similar technologies by purpose, then assess the applicable current rules and exceptions. The ICO's guidance has changed, so blanket statements about every analytics implementation can be misleading. Where consent is required, verify behaviour before and after the choice. A banner's appearance does not prove that the underlying tags follow it. Check hard-coded services as well as those managed through a tag manager.

75. Missing records for relevant data decisions

Keep the records needed to demonstrate how the applicable requirements were assessed and implemented. Consent records, retention decisions and impact assessments have different purposes. A data protection impact assessment is not automatically required for every ordinary website change. Seek appropriate review for the actual processing and risk. Avoid collecting unnecessary additional personal information merely to create an audit trail. The record should be proportionate and useful.

76. Personal information exposed in URLs or logs

Inspect form destinations, query strings, event payloads and logs for information that should not be there. URLs can be copied, stored and shared through several systems. Moving a value into a request body does not by itself make the whole process safe. Review collection, access and retention together. A hashed identifier is not automatically anonymous. Correct the data flow and assess any existing exposure through the appropriate incident process.

77. Files accessible beyond their intended audience

Review public storage, uploads and generated documents. Disabling a directory listing can reduce accidental browsing, but it does not protect a file whose address is known. Use appropriate access controls for private information and check how links are created and shared. A missing index page is not a complete security boundary. Test the actual access requirements and keep public marketing assets distinct from restricted records.

78. Backups without a tested recovery route

Confirm what is backed up, how copies are protected and who can restore them. Test recovery in an appropriate environment and record the result. The required frequency and retention depend on the site's activity and risk; a universal schedule is not enough. Include incident responsibilities and escalation. A successful backup job is useful, but the business needs to know whether the relevant content and functionality can actually be recovered.

Archived companion: Download ERROR List [PDF]. Its general checklist does not replace current legal guidance or a security assessment of the actual implementation.

7. Analytics and reliable interpretation

Measurement should answer a defined question. More events and dashboards do not automatically create better evidence. Verify the collection and document its limits before using it to justify a redesign or campaign.

79. Missing or inconsistent page measurement

Check the intended analytics configuration across representative templates and navigation behaviours. A single-page application may need different handling from ordinary page loads. Use the provider's supported debugging process and verify the actual events. Missing data can reflect configuration, consent choices or browser behaviour. Do not treat every gap as something to bypass. Keep development activity separate and describe what the measurements can and cannot represent.

80. Events counted more than once

Look for overlapping installations in templates, plugins and tag managers. Confirm whether the same action generates duplicate events. Multiple properties can have a legitimate purpose, so do not collapse them solely to achieve a one-property rule. Document ownership and deduplication where needed. Test a recognisable action and trace the resulting records. A plausible dashboard total does not prove the collection is accurate.

81. Important outcomes defined imprecisely

Agree what constitutes an enquiry, purchase or booking before naming the event. A click, a submitted form and a qualified opportunity are different stages. Check that the event fires at the intended point and only under the appropriate conditions. In GA4, review the current key-event terminology and settings rather than follow an old interface label. Validate against operational records while accounting for the limits of each source.

82. Journeys split across systems without explanation

If a visitor moves between domains or third-party services, assess whether the measurement setup can represent the intended journey. Cross-domain configuration may be relevant, but subdomains and external checkout services do not all require identical handling. Test the actual route with the provider's supported tools. Document gaps that cannot be resolved appropriately. Do not claim uninterrupted attribution merely because the pages look like one branded experience.

83. Server-side collection used without a clear need

Server-side events can support some measurement architectures, but they add operational and data-handling responsibilities. Define the intended benefit and verify the payloads, access and deduplication. They are not permission to ignore consent choices or collect information a browser implementation should not send. Compare the resulting data carefully. Recovering a larger event count is not automatically evidence of greater accuracy.

84. Campaign labels used inconsistently

Agree a simple naming convention for campaign parameters and keep it available to the team. Different casing or spelling can split what should be one reporting category. Test that links retain the necessary destination and work after redirects. Avoid adding campaign parameters to ordinary internal links without understanding the reporting effect. Keep the convention useful enough to maintain rather than creating a complex taxonomy nobody can apply reliably.

85. Consent signals mistaken for legal approval

A platform's consent settings describe technical behaviour; they do not determine the legal basis for your processing. Configure them according to the assessed requirements and verify each relevant state. Modelled results are estimates subject to provider conditions, not recovered observations of every missing person. Explain that distinction in reporting. Do not promise that a particular mode will close a fixed data gap or make all tracking compliant.

86. Internal testing distorting the evidence

Identify staff, development and quality-review activity where appropriate so it is not mistaken for customer behaviour. Test filters before applying changes that may permanently exclude data. Remote teams and shared networks can make simplistic IP rules unreliable. Document the chosen method and keep production and development configuration clear. Review sudden changes in recorded activity alongside releases and testing sessions before attributing them to customer demand.

87. Missing evidence of failed discovery

Not-found pages and internal search can reveal useful questions about broken routes or missing content. Collect only appropriate information and avoid sending sensitive search text into tools without assessment. Review actual examples before proposing redirects or new pages. A frequent search may reflect demand, a navigation problem or an ambiguous label. Use it as a prompt for investigation rather than automatic proof of what content to create.

88. Recordings treated as explanations of intention

Session recordings and heatmaps can show interaction patterns, but they do not tell you everything a person was thinking. Check masking, access, retention and applicable requirements before use. Review representative examples and reproduce suspected issues. Pair observations with feedback or task testing where useful. A repeated click may indicate a broken control, impatience or another cause; verify it rather than label every pattern as a proven conversion barrier.

89. Metrics without shared definitions

Write down the formula, source, time period and owner for important measures. A “lead” might mean a form submission to one team and a qualified opportunity to another. Keep raw counts visible alongside rates, especially with small samples. Review definitions when the site changes. A single dashboard can still be misleading if the underlying terms are inconsistent or if a new implementation counts a different event under the same name.

Archived companion: Download ERROR List [PDF]. The updated article distinguishes observed activity, modelled results and business outcomes.

8. CMS, hosting and operational continuity

The website should remain manageable after a release. These checks focus on the systems and responsibilities behind the public pages, including how the team detects failures and recovers from them.

90. Delivery infrastructure that does not fit the audience

Review where content is served and whether an existing platform already provides a CDN or image service. Adding another layer without understanding the current setup can create complexity. Measure the relevant regions and content types before deciding what to change. Confirm ownership, configuration and cache behaviour. A delivery service should address a demonstrated need and remain understandable to the people maintaining the site.

91. Server caching without correct boundaries

Assess which responses can be shared safely and what invalidates them when content changes. Personalised or authenticated information needs appropriate handling. A high cache-hit rate is not a success if one person receives another person's content or editors cannot publish corrections promptly. Test representative states and updates. Keep the rules documented, including the route for clearing stale content during an incident.

92. Slow data access without profiling

When the application is responsible for database work, use appropriate profiling to identify slow or repeated queries. Indexes and caching can help particular patterns but also have trade-offs. Do not add them randomly because a generic audit recommends them. Test with representative data and workload. On a managed platform, the practical action may be to change the query or template rather than attempt infrastructure changes the team does not control.

93. Media cleanup that removes still-used assets

Inventory files before deleting anything. An image that is absent from the current CMS record may still be used in older articles, email campaigns or external references. Check dependencies and preserve appropriate recovery options. Distinguish unused public marketing material from information that should never have been public. The objective is an organised, maintainable asset collection, not the smallest possible storage figure at the expense of broken content.

94. A test environment that misrepresents production

Keep the relevant configuration and dependencies representative enough for the intended checks. Use suitable test data and prevent accidental real-world actions such as customer messages or live payments. A staging site need not copy every production condition, but its differences should be understood. Record which behaviours still need verification in the final environment. Do not declare a migration complete solely because a simplified preview worked.

95. Releases without a repeatable process

Document how reviewed work reaches the live site and which checks are required. Automation can help consistency, but the process should fit the project rather than imitate a complex deployment architecture unnecessarily. Keep change notes and a suitable recovery route. Confirm that a rollback can address the actual change, including data transformations or external actions. Reverting code is not always enough to reverse what happened.

96. Secrets exposed to the wrong environment

Review credentials in source code, browser bundles, logs and configuration. Some public identifiers are designed for client use, while secret credentials are not. Apply the provider's intended model, restrict privileges and rotate exposed secrets through the appropriate process. Removing a value from the latest file does not necessarily remove it from history or caches. Use approved handling and avoid printing sensitive values during investigation.

97. Background work failing silently

Scheduled imports, email jobs and synchronisation tasks can stop while the public website still appears normal. Identify the important jobs, their expected behaviour and the person responsible for failures. Design retries to avoid duplicate actions, and provide a way to investigate unresolved work. A success notification should reflect the actual outcome, not merely that a job started. Test the failure route as part of the operational review.

98. Frontend bundles containing unnecessary work

Inspect the code delivered to representative pages and identify dependencies that are unused or loaded too early. Route-based splitting and deferred modules can help where appropriate, but too many fragments can also complicate delivery. Measure the result and verify interactions after changes. Keep a reasonable budget for future additions. The audit should explain which work is unnecessary, not prescribe a fashionable build tool without evidence.

99. Monitoring without a response owner

A monitor is useful when it checks an important behaviour and reaches someone who can act. A homepage responding successfully does not prove that a form or checkout works. Choose appropriate checks and intervals for the business, then test the alert route. Agree escalation and support arrangements honestly. Do not promise a fixed recovery time merely because a monitoring product can send a notification quickly.

100. Logs that cannot support investigation

Keep enough structured information to connect a failure with the relevant request, job or release, while avoiding unnecessary sensitive data. Define access and retention. More logs are not automatically better if nobody can locate the useful evidence. Test whether the team can investigate a representative problem using the available records. For a small site, a modest coherent setup may be more useful than several disconnected enterprise dashboards.

Choose tools for the evidence you need

The following twelve references cover different tasks. Confirm current availability, limits and terms directly; this is not a promise that every feature is free or that one product can complete the whole audit.

Treo and DebugBear are performance references to investigate. Understand whether the report uses observed user data, a simulated test or both. Compare similar conditions and read the findings rather than treating a score as a complete verdict.

SEObility and Ubersuggest can be assessed for relevant search and content investigation. A tool's estimate of another website's activity is not the same as access to that site's verified analytics. Use estimates as context and keep their uncertainty visible.

Screaming Frog can support crawling, while Google Search Console provides information about Google's interaction with a verified property. Their views answer different questions. Compare findings and inspect representative pages before applying broad changes.

QuestionDB and AlsoAsked are question-research references. Use the results to understand possible audience needs, then write a useful answer based on the business and reliable sources. A list of suggested questions is not a requirement to add every one to the page.

Schema Validator and Schema Generator can assist with structured-data review or preparation. Validate the generated output against the actual content and current requirements. Syntactically valid markup does not guarantee a supported search feature or an improved click-through rate.

Dead Link Checker can help identify link failures, and Moz Link Explorer is a backlink research reference. Investigate the relevant destination and context. Do not remove or disavow links simply because an automated metric gives them an alarming label.

Turn the findings into a practical work plan

Start by separating confirmed failures from improvements worth considering. A form that cannot submit, a private file exposed publicly and a misleading service claim deserve different responses from a suggestion to change a colour. Record the evidence and the consequence.

Group repeated findings by their likely cause. If a shared template produces incorrect table spacing across many articles, correct that pattern and check representative instances. If only one page contains a wrong link, a targeted edit may be enough. This makes the work more efficient without treating every finding as identical.

Assign an owner and define verification before implementation. The person fixing a problem should know which task must work afterwards. A completed code change is not the same as a confirmed improvement in the final environment.

Work in manageable batches and read back saved changes. For content, confirm the final text, links and media rather than assuming a successful save proves the result. For functionality, repeat the affected journey. Keep a clear distinction between source inspection, automated testing and review of the rendered page.

A worked example of prioritisation

Imagine a hypothetical service site with three findings: a contact form that sometimes fails, a large decorative image and an inconsistent heading colour. Begin by reproducing the form failure and checking whether submissions reach the team. That task directly affects the intended enquiry route.

The image may be the next priority if measurement shows that it delays useful content. Resize or change its delivery, then compare the page under similar conditions. The heading colour can be corrected through the shared style once the important route and performance issue are understood.

Do not attach an invented revenue figure to each change. The business can measure subsequent enquiries and review their quality, but demand, campaigns and other conditions may also change. The audit can identify a real problem without predicting a precise commercial uplift.

For Fit Design, a useful audit connects the public experience with the content system and the people operating it. The result should be a clear, prioritised explanation of what to improve and how to know it is better.

Historical download: Download ERROR List [PDF]. Its original estimates and blanket prescriptions are not the basis for the updated recommendations above.

Sources and scope

For implementation details, use the current primary guidance: Google on canonical URLs, Google on noindex, Google on language variants and Google's search documentation updates.

Further references include Core Web Vitals, Chrome's explanation of yielding long tasks, W3C accessibility tutorials, WCAG target-size guidance, OWASP ASVS and ICO guidance on storage and access exceptions.

This guide is a starting structure for a review. The actual scope, requirements and risk determine which checks apply and what specialist assessment is needed. A completed checklist is not a guarantee of rankings, conversions, security or compliance.