Public sector technical SEO checks for UK websites

What to take away

What the GDS service standard expects from a public sector website

The Government Digital Service (GDS) sets the service standard that UK central government departments and many arms-length bodies must meet. The standard is published in the GDS Service Manual, which covers planning, building, running and retiring digital services.

For a technical SEO lead, the manual is not a marketing document. It is the source of the accessibility and performance points that shape your audit scope.

Accessibility is a named point in the standard. Teams must identify and meet accessibility requirements, test with users who have access needs, and publish an accessibility statement. That statement is a public page, and it should be linked from the footer of every template.

If your accessibility statement is orphaned or blocked in robots.txt, you have both a compliance gap and a crawl problem.

The performance point asks teams to define performance metrics and monitor them. GDS does not prescribe a single tool, but it does expect evidence that the service works for users on slow connections and older devices.

In technical SEO terms, you cannot treat core web vitals as a one-off audit. You need field data from real users, segmented by device and connection type, and a process for acting on regressions.

The service standard also covers data and privacy, which affects analytics implementation. Consent management must not block crawlers, but it must also not fire tracking before consent.

A misconfigured consent banner can break your analytics, hide vitals data and create duplicate pageviews. Test it in a staging environment before launch, and include it in your technical SEO launch review.

Finally, the standard expects teams to iterate. That means your technical SEO checks should be repeatable and scheduled, not a one-off project. A quarterly crawl, a monthly vitals review and a pre-release accessibility check are the minimum cadence for a public sector estate.

Accessibility duties and WCAG standards for public sector websites

The Equality Act 2010 places a duty on public bodies not to discriminate against disabled people in the provision of services. Separately, covered public sector bodies must comply with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Government guidance, Understanding accessibility requirements for public sector bodies, explains who is covered, what an accessibility statement must contain, and how to report non-compliance.

The guidance sets out who must comply, what an accessibility statement must contain, and how to report non-compliance.

The accessibility regulations' conformance baseline is WCAG 2.1 Level AA, not WCAG 2.2. WCAG 2.2 adds further success criteria, including focus appearance, dragging movements and target size; it can be an additional benchmark, but should not be presented as the legal baseline for these regulations. For a technical SEO audit, check the applicable criteria alongside crawlability and indexation.

Consider heading structure. A page with a single H1 and logical H2s is easier for screen readers and for search engines to parse. Consider link text. Descriptive anchors help assistive technology users and give crawlers context.

Consider form labels. A missing label breaks accessibility and can cause a form page to be excluded from search results because the content is unclear.

Checks against WCAG 2.1 AA should include keyboard-only use, screen-reader testing and zoom up to 200 per cent. Automated tools can identify some issues, but manual testing is required for a full assessment.

Record every failure with a page URL, a success criterion number and a severity rating. That record becomes your remediation backlog and your evidence for the accessibility statement.

Accessibility defects also affect SEO metrics. Pages with poor contrast and tiny tap targets get high bounce rates, which can depress engagement signals. Pages with unlabelled images lose image search traffic. Fixing accessibility is therefore a technical SEO win, not a parallel workstream.

If you need a structured way to sign off fixes, use a technical SEO quality checklist that covers WCAG 2.1 AA and can include WCAG 2.2 checks as additional criteria.

Turning service standard performance points into core web vitals checks

The service standard expects teams to measure performance and act on it. For a public sector website, the practical translation is core web vitals. These are the field metrics Google uses: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

Public sector sites often fail LCP because of large hero images, slow server response times or render-blocking scripts from third-party tools.

Start with field data. Use the Chrome User Experience Report or your own Real User Monitoring to see how real citizens experience your pages. Segment by device and by connection type. A page that passes on a fast office connection may fail on a mobile phone in a rural area.

That matters for public sector accessibility requirements, because citizens in remote parts of Scotland, Wales or the South West may have slower connections.

Next, set thresholds. Google's published thresholds are a good baseline: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. But for a public sector site, you may need stricter internal targets for key journeys such as benefit claims or licence applications. Document those targets in your service manual measuring success plan.

Then fix the causes. Common fixes include compressing images, using modern formats, deferring non-critical JavaScript, caching at the edge and reducing third-party tags. Each fix should be tested in a staging environment and measured after release. Do not assume a fix worked; verify with field data.

Finally, monitor continuously. Core web vitals change as content and third-party scripts change. Set up alerts for regressions and include vitals in your technical SEO reporting dashboard. A monthly review with your dev team is enough for most estates, but high-traffic services may need weekly checks.

Crawl, index and metadata checks for GOV.UK-style content estates

GOV.UK-style estates have specific crawl and index challenges. They often run on a shared publishing platform with thousands of pages, multiple taxonomies and complex navigation. Small configuration errors can cause large-scale index bloat or exclusion.

Start with robots.txt. It should allow crawl of all public content and block only staging, admin and search result pages. Check for disallow rules that accidentally block CSS or JavaScript files, because Google needs those to render pages. Also check for noindex tags on pages that should be indexed, and for canonical tags that point to the wrong URL.

XML sitemaps should be generated automatically and split by content type. They should include only canonical, indexable URLs. Submit them in Google Search Console and monitor the index coverage report. Look for pages excluded by 'Crawled - currently not indexed' or 'Discovered - currently not indexed'. These often indicate thin content, duplicate content or slow server responses.

Metadata is another common failure. Title tags should be unique and descriptive, with the service name and the department. Meta descriptions should summarise the page and include a call to action.

Avoid duplicate titles across similar pages, such as multiple 'Apply for...' pages. Use structured data where appropriate, such as GovernmentService or FAQPage, but validate it with the Rich Results Test.

Internal linking matters. A flat architecture with clear breadcrumbs helps crawlers and users. Orphan pages, which have no internal links, are hard to find and often miss updates. Run a crawl to find orphans and add links from relevant parent pages. For a full audit sequence, see our guide to technical SEO service standards.

Measuring success and reporting KPIs for public sector technical SEO

The GDS Measuring success guidance provides a framework for setting performance metrics. It emphasises outcomes over outputs, and it asks teams to define what success looks like before they build. For technical SEO, that means agreeing KPIs that link to service goals.

Typical KPIs include organic search sessions to key journeys, index coverage rate, crawl error rate, core web vitals pass rate and accessibility defect count. Each KPI should have a baseline, a target and a review cadence. Report them alongside service metrics such as completion rate and user satisfaction, so technical work is seen in context.

Use a dashboard that non-specialists can read. Show trends, not snapshots. Annotate releases and algorithm updates. If you need to measure technical SEO performance across multiple domains, standardise your data sources and definitions first.

Report monthly to your service owner and quarterly to your digital board. Include a short narrative: what changed, what it means, what you will do next. Avoid jargon. Public sector leaders need to make decisions, not interpret metrics.

Tools and evidence for public sector technical SEO checks

Use Screaming Frog SEO Spider to crawl a site and identify response codes, indexability directives, canonical tags, metadata and orphan pages. Check the results against your intended robots.txt, sitemap and indexation rules; a crawler reports technical signals, not whether a page should be indexed. If a supplier performs the work, record data ownership and reporting duties in contracts.

For accessibility checks, axe DevTools and the WAVE Web Accessibility Evaluation Tool can flag common issues. Treat their results as prompts for further testing, not proof of conformance: review the relevant WCAG criteria and test key journeys manually.

Use the Chrome User Experience Report for field performance data and Lighthouse for lab diagnostics. Compare results with real-user monitoring where available, and investigate issues on the devices and connections your users rely on.

Data protection law is enforced by the Information Commissioner's Office (ICO). Your analytics setup must comply with UK GDPR. That means consent for non-essential cookies, data minimisation and clear privacy notices. A privacy-compliant analytics setup can still provide the data you need for technical SEO if you design it correctly.

For accessibility, test key journeys with a keyboard and screen reader as well as automated tools. Record each failure with its page URL and relevant WCAG success criterion so teams can prioritise and retest fixes.

The British Standards Institution's BS 8878 is withdrawn, while ISO 30071-1 provides a framework for accessible ICT. Treat these as supplementary guidance, not substitutes for checking conformance against the applicable WCAG criteria.

Applying technical SEO checks across service delivery

The GDS Service Manual describes discovery, alpha, beta, live and retirement. The checks below focus on discovery, alpha, beta, launch and post-launch monitoring.

During discovery, audit the existing estate. Identify top journeys, crawl the site, and record accessibility and performance baselines. Use the Understanding accessibility requirements for public sector bodies - GOV.UK guidance to scope your legal duties. Also review the Equality Act 2010 for the underlying duty.

During alpha, prototype with accessibility in mind. Test keyboard navigation, heading order and form labels against WCAG 2.1 AA. You can also assess WCAG 2.2 criteria as an additional benchmark.

During beta, run a full technical audit. Check robots.txt, sitemaps, canonicals, metadata and structured data. Set up core web vitals monitoring. Prepare an accessibility statement.

Before live, complete a pre-launch review. Use the Service Manual - GOV.UK to confirm you have met all points. Verify redirects, error pages and analytics. Run a final crawl.

After live, monitor using the Measuring success - Service Manual - GOV.UK framework. Report KPIs monthly. Re-audit quarterly.

Use this checklist to track progress:

For a worked example, take a fictional council website with 5,000 pages. A crawl finds 200 pages blocked by robots.txt, 50 duplicate titles and an LCP of 4.2 seconds on mobile. The team fixes robots.txt, rewrites titles and compresses images.

After three months, index coverage rises from 70 per cent to 92 per cent and LCP falls to 2.1 seconds. Organic sessions to key journeys increase by 18 per cent. That is the kind of outcome the service standard expects.

Common questions