Website Audit in 2026: The Complete SEO, Core Web Vitals, Accessibility and Security Checklist

In 2026, an audit needs to be carried out in layers. Google still bases visibility on technical foundations and people-first content, although results may also be presented through AI-powered features. Core Web Vitals should be assessed using real-user data, accessibility cannot be confirmed by a scanner alone, and security requires more than the presence of an SSL certificate.

This guide walks through the complete process: from indexing and SEO, through LCP, INP and CLS, to WCAG 2.2, security headers, forms, analytics and the order in which fixes should be implemented.

TL;DR: Start with critical failures: website downtime, indexing blocks, incorrect redirects, HTTPS problems and vulnerabilities. Then improve Core Web Vitals, the accessibility of key journeys, content and internal linking. A 100/100 score in one tool does not replace Search Console data, testing on real devices or manual verification.

Standards, thresholds and sources were last verified on 23 July 2026.

The main audit areas

Area	What to check	What a good result looks like	Priority
Indexing	robots.txt, noindex, sitemap, canonical, HTTP status codes	important pages are accessible and indexable, duplicates are consolidated	critical
SEO and content	search intent, titles, headings, internal links, structured data	every important page has a clear purpose and unique value	high
Performance	LCP, INP, CLS, TTFB, JavaScript, images, fonts	CWV are in the “good” range at the 75th percentile	high
Accessibility	keyboard, focus, semantics, contrast, forms, screen readers	key journeys meet WCAG 2.2 AA	high
Security	HTTPS, headers, cookies, dependencies, authorisation, backups	no critical vulnerabilities or unnecessary exposure	critical
UX and conversion	mobile, forms, navigation, errors, trust	users can complete the main task without unnecessary friction	high
Measurement	Search Console, analytics, logs, monitoring	data is complete, privacy-compliant and actionable	medium

What does a website audit actually cover?

A complete audit combines at least six perspectives:

1. Technical SEO - whether a crawler can access the website, render it, follow its links and identify the correct canonical URL.
2. Content quality - whether a page answers a real user need, has a logical structure and does not duplicate other pages.
3. Performance - how quickly the main content appears, how promptly the page responds and whether the layout shifts while loading.
4. Accessibility - whether the service can be used with a keyboard, screen reader, zoom and without relying on colour alone.
5. Security and privacy - whether communication, sessions, forms, dependencies and user data are adequately protected.
6. UX and business objectives - whether visitors understand the offer and can complete the most important action without unnecessary steps.

Automated tools are an excellent starting point, but they cannot assess everything. Lighthouse can detect some performance and accessibility issues, but it cannot determine whether an offer is understandable, a form reflects customer needs or an error message genuinely helps someone recover.

Before you begin: define the scope and URL sample

The most common mistake is scanning only the homepage. In practice, representative page types should be tested:

• the homepage,
• the most important service or product page,
• an article or guide,
• a category or listing page,
• a contact form, registration or checkout,
• a search-results page,
• a language version,
• the 404 page and other error states,
• an authenticated page, where applicable.

For a small website, a sample of several or a dozen URLs may be sufficient. In an online store, portal or application, audit templates rather than random URLs. If one product template has an incorrect canonical tag or loads a heavy script, the problem may affect thousands of pages.

Before the audit, collect:

• access to Google Search Console and analytics,
• a list of the most important business goals,
• the sitemap and key templates,
• information about recent changes, migrations and traffic drops,
• error-monitoring data and server logs,
• the devices and browsers most frequently used by customers.

1. Technical SEO and indexing audit

Check HTTP status codes and domain variants

Every important URL should return the correct status:

• 200 for a working page,
• 301 or 308 for a permanent redirect,
• 404 or 410 for removed content,
• 5xx only for a genuine server error, not as a permanent state.

Check http/https, www/non-www, trailing slashes and letter case. They should resolve to one consistent version. Avoid redirect chains and situations where many old URLs are redirected to an unrelated homepage.

Verify robots.txt, noindex and resource access

The robots.txt file controls crawler access at the retrieval level, but it is not a mechanism for removing a page from search results. A blocked URL can still appear in the index if Google learns about it elsewhere. To exclude a page, use measures such as noindex, password protection or removing the resource.

Check whether:

• important sections are not accidentally blocked,
• the staging environment is protected rather than merely hidden in robots.txt,
• Google can fetch CSS, JavaScript and images required for rendering,
• the sitemap is located correctly and contains canonical pages only,
• a noindex tag was not left behind after production deployment.

Assess canonical tags and duplicates

A canonical URL indicates the preferred version of duplicate or highly similar content. Google treats canonicalisation as a strong signal, but may select another URL if the remaining signals conflict.

Check consistency between:

• rel="canonical",
• redirects,
• internal links,
• XML sitemaps,
• language versions,
• protocol and host.

A canonical should normally point to a working 200 URL, not an error page, redirect or URL marked noindex.

Check JavaScript rendering

Google processes JavaScript applications in stages: crawling, rendering and indexing. Client-side content may be processed later than immediately available HTML, so critical information and links should not depend on a fragile script.

For SPAs and hybrid-rendered services, check:

• HTML available before JavaScript executes,
• links implemented as real <a href> elements,
• status-code handling,
• metadata generated for each URL,
• behaviour when a subpage is opened directly,
• hydration errors and failed API calls,
• indexability of pagination and infinite-scroll listings.

Audit language versions

On a multilingual website, each version should have its own stable URL. Check:

• valid hreflang attributes,
• reciprocal references between versions,
• an optional x-default,
• a canonical pointing to the same language version,
• no automatic redirects that block crawlers,
• translated titles, descriptions, content and navigation.

Technical SEO checklist

• Important URLs return 200.
• Redirects are single-hop and logical.
• There are no accidental robots.txt blocks.
• Production does not contain unintended noindex.
• The XML sitemap contains canonical URLs only.
• Canonicals, links and the sitemap agree.
• JavaScript does not hide critical content from crawlers.
• 404 pages return a genuine 404 status.
• Language versions use correct hreflang.
• Parameters and filters do not create mass duplication.

2. Content and on-page SEO audit

Every page should have one primary purpose

The title, H1, opening, body content and call to action should serve the same intent. If one page simultaneously tries to sell a service, define basic concepts and rank for a dozen unrelated queries, it usually does none of those jobs particularly well.

Check:

• whether the title is unique and descriptive,
• whether the main H1 reflects the content,
• whether the search snippet encourages a click without exaggerated promises,
• whether H2 and H3 headings form a logical hierarchy,
• whether the answer appears early rather than after a long introduction,
• whether the article demonstrates experience, examples and sources,
• whether the update date represents a real content change.

Google recommends useful, reliable content created primarily for people rather than pages designed solely to manipulate rankings.

Internal linking should create structure

Good internal linking helps users move to the next step and shows search engines how topics relate. Use descriptive anchor text rather than many generic “click here” links.

Natural next steps from this article include:

• POLPROG Website Health Check,
• Core Web Vitals in practice,
• Web Strategy,
• Performance,
• Security,
• How to plan a business website that generates leads.

Also look for orphan pages: URLs that receive no internal links.

Images, structured data and Open Graph

Images should have meaningful filenames, appropriate dimensions and alternative text when they convey information. A purely decorative image should usually use an empty alt="". Google supports common formats including JPEG, PNG, WebP, SVG and AVIF.

Audit:

• width and height to prevent layout shifts,
• srcset and sizes,
• compression and format,
• lazy loading below the fold,
• alternative text,
• structured data that matches visible content,
• og:title, og:description, og:image and og:url.

For practical checks, use the Image Converter & Optimizer and Open Graph Preview.

SEO in AI-powered search experiences

Google states that the same foundational SEO practices continue to apply to AI features in Search. No special files or new markup are required solely to appear in AI Overviews or AI Mode. A page still needs to be indexable and comply with normal Search requirements.

The most sensible strategy is to:

• publish clear, complete answers,
• use sources and practical examples,
• update rapidly changing information,
• avoid mass-produced repetitive content,
• maintain semantic structure and internal linking,
• monitor traffic and queries in Search Console.

3. Core Web Vitals and performance

Current thresholds

Core Web Vitals consist of three metrics. Assessment should use the 75th percentile of real visits, separately for mobile and desktop.

Metric	What it measures	Good	Needs improvement	Poor
LCP	when the largest content element appears	≤ 2.5 s	2.5-4.0 s	> 4.0 s
INP	interaction response delay	≤ 200 ms	200-500 ms	> 500 ms
CLS	visual stability of the layout	≤ 0.1	0.1-0.25	> 0.25

Field data describes the experience of real users, while laboratory data helps reproduce a problem. Do not confuse the two. A website may score well in a local Lighthouse run but have poor INP on older phones or slow LCP in a particular country.

How to improve LCP

Common causes of poor LCP include:

• slow server response or missing cache,
• an oversized hero image,
• the LCP resource being discovered only through JavaScript,
• render-blocking CSS and fonts,
• long request chains,
• heavy logic executed before rendering.

Actions:

• improve TTFB and caching,
• serve the image at the correct dimensions,
• use a modern format and compression,
• prioritise the main resource,
• do not lazy-load the LCP image,
• reduce critical CSS and scripts,
• use a CDN where it genuinely shortens the path to users.

How to improve INP

INP is harmed by long tasks on the main thread, excessive JavaScript, expensive component rendering and event handlers that perform too much work.

Check:

• task duration in the Performance panel,
• third-party scripts,
• components rerendering after every change,
• large lists without virtualisation,
• synchronous memory and DOM operations,
• form validation and animations running during interaction.

Break up long tasks, defer non-critical work and ship as little JavaScript as possible.

How to improve CLS

Common sources of layout shifts include:

• images and iframes without dimensions,
• adverts without reserved space,
• cookie banners inserted above content,
• fonts loaded late,
• components added before existing content,
• animation of properties that affect layout.

Reserve space, use stable placeholders and test the full loading sequence rather than only the final screenshot.

Do not optimise only for a Lighthouse score

Lighthouse is a laboratory test run under controlled conditions. A strong process combines:

• Search Console and its Core Web Vitals report,
• CrUX or RUM data,
• Lighthouse and the Performance panel,
• testing on a slower device,
• regression monitoring after deployment.

4. Accessibility audit against WCAG 2.2

WCAG 2.2 defines criteria that can be tested through a combination of automated and human evaluation. A scanner alone cannot confirm full conformance because some criteria require contextual judgement and interaction testing.

Keyboard and focus

Complete the key journey without a mouse:

• can every interactive element be reached,
• is focus order logical,
• is the focus indicator clearly visible,
• does a modal contain focus and return it after closing,
• is there any keyboard trap,
• is there a way to skip repeated navigation.

Semantics and screen readers

Check:

• one logical H1 and a valid heading hierarchy,
• header, nav, main and footer landmarks,
• real buttons and links instead of clickable div elements,
• accessible names for icons,
• announcements for dynamic changes,
• correct reading order,
• the document language in the lang attribute.

ARIA should enhance semantic HTML, not replace it without good reason.

Forms and errors

Every field should have a visible label and a programmatic association with its description. An error should explain what needs to be corrected and must not rely on colour alone.

Test:

• labels and instructions,
• required fields,
• autocomplete attributes,
• tab order,
• error messages,
• an error summary after submission,
• behaviour when zoomed and on narrow screens,
• time limits and the ability to extend them.

Contrast, zoom and motion

Audit the contrast of text, icons and focus states. Test the website at 200% and 400% zoom, with larger text and in a narrow viewport. Content should not require horizontal scrolling except where it is genuinely necessary.

Animations should respect prefers-reduced-motion, and automatically moving content should provide a way to pause it when it affects comprehension.

Accessibility checklist

• The full journey works with a keyboard.
• Focus is visible and follows a logical order.
• Headings and landmarks describe the structure.
• Buttons and links have understandable names.
• Forms have labels and useful errors.
• Contrast meets WCAG 2.2 AA.
• Content works with zoom and reflow.
• Informative images have appropriate alternative text.
• Motion can be reduced.
• Key tasks have been tested with a screen reader.

5. Security and privacy audit

HTTPS is the beginning, not the end

The entire website should operate over HTTPS with no active mixed content. Check certificate validity, trust chain, supported protocols, automatic renewal and HTTP-to-HTTPS redirects. Lighthouse flags pages that do not use HTTPS, but it is not a full penetration test.

You can verify the domain and certificate with the DNS & SSL Inspector.

Security headers

Headers do not fix broken authorisation, but they limit several classes of attack and unsafe browser behaviour. The OWASP Secure Headers Project maintains current recommendations and examples.

At minimum, review:

• Content-Security-Policy,
• Strict-Transport-Security,
• X-Content-Type-Options: nosniff,
• Referrer-Policy,
• Permissions-Policy,
• framing protection through frame-ancestors,
• secure cookie attributes: Secure, HttpOnly and an appropriate SameSite.

CSP is best introduced in stages, beginning with Content-Security-Policy-Report-Only, reviewing reports and only then enforcing the policy. A copied configuration must be adapted to the resources the website actually uses.

Use the Security Headers Inspector for a quick check.

OWASP Top 10:2025 as a risk map

The current OWASP Top 10:2025 covers broken access control, security misconfiguration, software supply chain failures, cryptographic failures, injection, insecure design, authentication failures, software or data integrity failures, security logging and alerting failures, and mishandling of exceptional conditions.

In practical terms, verify:

• whether one user can read or modify another user's data,
• whether the administration panel has additional protection,
• whether the API validates permissions on the server,
• whether dependencies and container images are maintained,
• whether secrets are kept out of repositories and client-side code,
• whether input is validated and output encoded,
• whether sessions expire and can be revoked,
• whether logs avoid passwords, tokens and sensitive data,
• whether errors hide stack traces and infrastructure details,
• whether backups exist and restoration has been tested.

For applications handling authentication, payments or customer data, use OWASP ASVS to define the test scope instead of relying only on a short header checklist.

Privacy and analytics

Check:

• which scripts run before consent,
• whether forms collect only necessary data,
• data-retention periods,
• employee and vendor access,
• the ability to withdraw consent,
• Consent Mode configuration where used,
• logging of IP addresses and identifiers,
• whether the privacy policy reflects actual website behaviour.

Do not assume that the presence of a cookie banner automatically ensures compliance. What matters is what the website actually loads and transmits.

6. UX, mobile and conversion

A technical audit can pass while the website still fails its purpose. Complete the most important journey as a new visitor:

• is it clear in the first screen what the company does,
• does each CTA describe a specific action,
• does navigation avoid guesswork,
• does the form request only necessary information,
• can errors be corrected easily,
• are phone numbers and email addresses tappable on mobile,
• do elements avoid overlapping,
• do pop-ups leave the content usable,
• are success messages unambiguous,
• does the website cope with a slow connection and failed requests.

Also test the 404 page, empty search results, unavailable products or services, expired sessions and failed payments. Exceptional states often determine whether someone returns.

For lead-generation websites, see How to plan a business website that generates leads.

7. Measurement, monitoring and data quality

Search Console shows how the website performs in Google Search, while analytics shows what users do after arriving. Combining both perspectives helps distinguish a visibility problem from a conversion problem.

Check:

• whether the Search Console property covers the correct domain variant,
• indexing errors and manual actions,
• queries, pages, countries and devices,
• changes in clicks and impressions after deployment,
• completeness of analytics events,
• exclusion of internal and bot traffic,
• accuracy of the conversion funnel,
• JavaScript and server error alerts,
• uptime and certificate monitoring.

Do not fix everything at once without a baseline. Record the starting point and deploy changes in groups so that their impact can be measured.

How long does an audit take?

The following are practical estimates, not an official standard. Scope depends on template count, data access, technology and risk level.

Scope	Indicative time	Includes
Quick check of one URL	15-30 min	status, metadata, basic CWV, HTTPS and major errors
Small business website	2-6 hours	page sample, SEO, CWV, accessibility, security and UX
Content or multilingual website	1-3 days	templates, indexing, hreflang, links, data and priorities
Online store	3-7 days	categories, products, filters, checkout, structured data and performance
Web application	5-10+ days	roles, authorisation, workflows, API, error states and manual testing
High-risk security audit	separate scope	threat modelling, ASVS, application and infrastructure testing

Cost grows less with the raw number of URLs than with the number of distinct behaviours. A thousand products based on one template may be easier to assess than an application with ten roles and many states.

How should fixes be prioritised?

Use a simple model: impact × reach × risk ÷ implementation cost.

P0 - fix immediately

• the website or a critical function is unavailable,
• important sections are blocked from indexing,
• data leakage or an authorisation bypass exists,
• the certificate has expired or active mixed content is present,
• a migration produces widespread errors and lost URLs,
• a form fails to deliver enquiries.

P1 - high priority

• poor CWV on the most important templates,
• serious keyboard and form barriers,
• incorrect canonicals or hreflang,
• an unclear offer and difficult conversion path,
• critical dependencies left unpatched,
• no monitoring of important failures.

P2 - schedule for the next cycle

• duplicate titles and weak internal linking,
• missing alternative text,
• heavy images below the fold,
• inconsistent structured data,
• weak 404 and empty states,
• issues affecting less popular templates.

P3 - optimisation and growth

• additional structured data,
• further weight reduction,
• experiments with copy and CTAs,
• content expansion,
• component and documentation cleanup.

A 30-, 60- and 90-day repair plan

First 30 days

Resolve P0 issues, indexing, redirects, HTTPS, forms and data-loss problems. Establish a baseline for measurement.

By day 60

Work on the most important templates: Core Web Vitals, keyboard operation, forms, content, internal linking and application security. Introduce regression monitoring.

By day 90

Improve lower-priority templates, standardise the publishing process, add automated checks to CI and schedule recurring audits after major releases.

Complete checklist before closing the audit

SEO and indexing

• Crawlers can fetch important pages and resources.
• The XML sitemap is current.
• Canonicals, redirects and links are consistent.
• There is no unintended noindex.
• Important pages have a unique title, H1 and content.
• Internal links lead to commercially important pages.
• Language versions use correct hreflang.
• Structured data matches visible content.
• Open Graph metadata is complete.

Performance

• LCP, INP and CLS meet thresholds in field data.
• The LCP image has the correct dimensions and priority.
• JavaScript does not block interaction.
• Images have dimensions and an appropriate format.
• Fonts and critical resources do not create avoidable delays.
• Results are monitored after deployment.

Accessibility

• The website works without a mouse.
• Focus is visible.
• Semantics and heading order are logical.
• Forms have labels and useful errors.
• Contrast and reflow meet WCAG 2.2 AA.
• The interface has been tested with a screen reader.

Security and privacy

• HTTPS works everywhere and the certificate is monitored.
• Session cookies use secure attributes.
• Headers are tailored to the application.
• Permissions are checked on the server.
• Dependencies and secrets are controlled.
• Logs and alerts support a response.
• Backups have been tested.
• Tracking scripts respect consent.

UX and business

• The offer is understandable without reading the entire page.
• CTAs lead to the intended action.
• Forms and checkout work on mobile.
• Error states help the user recover.
• Events and conversions are measured correctly.
• Every fix has an owner, priority and due date.

How to use POLPROG Website Health Check

Website Health Check lets you start an audit from a single URL and review SEO, performance, accessibility, security and best practices. Tests run server-side and the tool does not require registration.

A practical process is:

1. Scan the homepage and every important template.
2. Record critical issues and repeated patterns.
3. Confirm CWV with real-user data.
4. Manually test the keyboard, forms and key journeys.
5. Separately check security headers, DNS and SSL and Open Graph.
6. Prioritise the backlog by impact and risk.
7. Repeat the test after deployment and monitor regressions.

Final conclusion

The best website audit in 2026 does not end with a document containing a hundred warnings. It ends with a short, ordered action list that separates critical problems from cosmetic ones, assigns ownership and allows the result to be verified after implementation.

First make sure the website is available, indexable and secure. Then improve key user journeys, Core Web Vitals and accessibility. Only after that should you optimise smaller details. This order usually creates more value than chasing a perfect score in one scanner.