How to Fix Every Combined Audit Finding

The Combined Audit runs up to 21 checks on your site at once and returns one PDF report, with problems listed worst first inside each audit. That breadth is useful, but it also means a long report where one root cause can appear in three or four sections. This page does not repeat what each individual check means; every check already has its own fixes hub, linked below. Instead it groups the findings into eight areas, shows which fixes clear several findings at once, and sets out a sensible order for working through the whole report.

By John Carlsson · Updated 1 October 2026 · About 19 minutes to read

📋 Demo 📘 Tutorial 📖 Guide 🔧 Fix

On this page

Reading the report as one piece of work
Technical SEO and markup
Structured data
Speed and stability
Accessibility and images
Crawling, redirects and errors
International and local
Security and trust
Privacy and GDPR
Which findings to fix first across the whole report
A sensible order of work
Questions and answers

Reading the report as one piece of work

Each audit in the report is written to stand on its own, so it names every problem it finds even when another audit has already named the same one in different words. A single oversized hero photo, for example, can show up as a heavy image in Image Optimisation, as an unsized element in the CLS Debugger, as a slow Largest Contentful Paint in Core Web Vitals and as a saving opportunity in the Page Speed Analyzer. Four findings, one file to change.

The quickest way through is to stop thinking audit by audit and think in areas instead. Jump to the area you want:

Technical SEO and markup: Meta Tag Analyzer, HTML Checker, CSS Checker, JavaScript Checker.
Structured data: JSON Checker, Schema Debugger, Rich Snippets Suite.
Speed and stability: Page Speed Analyzer, Core Web Vitals, CLS Debugger.
Accessibility and images: Accessibility Audit, Image Optimisation.
Crawling, redirects and errors: Redirect Chain Checker, Robots & Sitemap Tester, Site Crawler, HTTP Error Audit.
International and local: Hreflang Checker, Local SEO Checker.
Security and trust: Security Audit, Trust Audit.
Privacy and GDPR: GDPR Audit.

Two of the checks, the Site Crawler and the Trust Audit, only run when you are signed in with a free account, so a signed-out Quick Audit report will have 19 sections rather than 21. If those two are missing, nothing has gone wrong.

Where the same root cause shows up more than once

Root cause	Sections that can report it	One fix
Images with no width and height	Image Optimisation, CLS Debugger, Core Web Vitals, Page Speed Analyzer	Add the attributes in the template that outputs images
Oversized or old-format images	Image Optimisation, Page Speed Analyzer, Core Web Vitals (LCP)	Resize and serve WebP or AVIF
Scripts loaded without defer or async	HTML Checker, JavaScript Checker, Page Speed Analyzer	Add `defer` to non-critical scripts
Broken JSON-LD	HTML Checker, JSON Checker, Schema Debugger, Rich Snippets Suite	Repair the one block at its source
Missing heading order, labels or landmarks	HTML Checker, Accessibility Audit	Fix the page template once
Missing HSTS, CSP or frame protection	Security Audit, GDPR Audit	Set the headers at one server layer
robots.txt problems	Robots & Sitemap Tester, Trust Audit, Security Audit	Edit one file
Dead links	HTTP Error Audit, Site Crawler	Update or redirect the link target

Technical SEO and markup

This area is the code in and around the page head and the files the page loads. The detailed explanations are in the Meta Tag Analyzer fixes, HTML Checker fixes, CSS Checker fixes and JavaScript Checker fixes hubs.

What matters across the whole report is that almost everything here lives in a template. On WordPress it is the theme header and the SEO plugin; on Shopify it is theme.liquid and the section files; on a static or framework site it is the shared layout component. Fix it there and every page inherits the fix, which is why a missing viewport tag or a duplicate H1 in a header include should go near the top of your list even though each looks minor in isolation.

The Meta Tag Analyzer and the HTML Checker overlap on titles, descriptions and Open Graph and X card tags. Treat them as one job: set the title, description and share image pattern in the SEO plugin or layout, then read both sections again on the re-run. The HTML Checker is also the first place an absolute canonical URL is checked, and a wrong canonical in a template is worth more urgency than a long title, because it tells search engines to index a different address.

The CSS and JavaScript Checkers mix two kinds of finding. Some affect visitors directly: render-blocking @import rules, fonts without font-display, animations of layout properties, and innerHTML set from variable content, which is a security concern as well as a code smell. Others are maintainability notes, such as ID selectors, !important or old var declarations. Do the first kind now and schedule the second for the next time a developer is in those files.

💡 If the CSS Checker flags animations on layout properties, expect the Interaction to Next Paint result in Core Web Vitals to improve once they move to transform and opacity. Fix them together and judge the result on the re-run.

Structured data

Three checks read the same JSON-LD blocks from different angles. The JSON Checker asks whether each block parses and has what its type needs; the Schema Debugger scores each block from 0 to 100 and separates rich result warnings from gaps that matter to AI answer engines; the Rich Snippets Suite shows which blocks are ready for rich results and which only support other markup. The per-tool explanations are in the JSON Checker fixes and Rich Snippets fixes hubs.

Work in this order. A block that does not parse is ignored entirely, so a parsing error outranks every missing property, and it will usually be reported by the HTML Checker too. Next come required properties, then recommended ones, then the AEO gaps. Duplicate blocks, commonly a theme and an SEO plugin both writing Organization or LocalBusiness markup, should be resolved before you add anything, otherwise you end up editing the copy that is not the one search engines trust.

Structured data also connects to two other areas. The Local SEO Checker reads your LocalBusiness block and compares its phone number and name with the visible page, so a fix made here can clear a mismatch there. And if the Meta Tag Analyzer shows a different business name in Open Graph tags, align that at the same time so every machine-readable source says the same thing.

⚠️ Valid markup makes a page eligible for rich results; it does not guarantee them. Google decides what to show, and some types, such as FAQ results, were limited in 2023 to well-known government and health sites. Judge your work by a clean report, not by what appears in search the next day.

Speed and stability

The Page Speed Analyzer and Core Web Vitals checks both draw on Google PageSpeed Insights, and the CLS Debugger looks at the page markup for elements likely to move. Read the Page Speed fixes, Core Web Vitals fixes and CLS Debugger fixes hubs for the detail on each metric.

The important thing about this area is that it is mostly an outcome rather than a cause. Slow Largest Contentful Paint is usually a large image, a slow server response or render-blocking files. High layout shift is usually unsized images, embeds or late fonts. Poor Interaction to Next Paint is usually long JavaScript tasks. Those causes are reported elsewhere in the same PDF, in Image Optimisation, the CSS and JavaScript Checkers and the HTML Checker. Fix the causes first and treat the speed sections as the scoreboard.

Google's thresholds for a good experience, measured at the 75th percentile of visits, are LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less. A result that moves from poor to needs improvement is real progress even if it is not yet good.

What to do directly in this area

Time to First Byte problems belong to hosting, caching or the CMS, not the page files, so they are work for your host rather than for the AI fix prompt, which only covers your own HTML, CSS and JavaScript.
Do not lazy-load the main image at the top of the page. Image Optimisation may flag images that do not lazy-load, but the one that is your LCP element should load straight away.
Re-run after each batch of changes. Lab measurements vary from run to run, so compare trends across two or three runs rather than reacting to one number.

Accessibility and images

The Accessibility Audit measures the parts of WCAG 2.1 that can be tested reliably, and Image Optimisation audits every image on the page. Their own hubs are the Accessibility fixes and Image Optimisation fixes. WCAG 2.2 is now the current version, and meeting the 2.1 criteria the checker tests is a sound base for it.

These two belong together because images are where accessibility and performance meet. Alt text is an accessibility requirement and is also checked by the HTML Checker. Width and height attributes stop layout shift. File size and format drive load time. One pass through your image library, or one change to the image component in your theme, can satisfy all of those at once: resize, convert, add dimensions and write alt text in a single sitting.

For the rest of the accessibility findings, separate template problems from content problems. A missing skip link, missing landmarks or an unlabelled search field in the header is a template fix that clears every page. Low contrast is usually a colour in the stylesheet, so it is also one fix. Vague link text such as read more, and missing alt text, are content problems that someone has to fix page by page, so start with the pages that get the most visits.

💡 The checker tells you how many elements sit over images or gradients and need checking by eye, and it measures contrast in the default colour scheme only. Put a short manual check of those, and of any dark mode, on the list as well, rather than treating a clean automated result as the end of the job.

Crawling, redirects and errors

Four checks cover whether search engines and visitors can reach your pages at all: the Redirect Chain Checker, the Robots & Sitemap Tester, the Site Crawler (signed in) and the HTTP Error Audit. Their hubs are Redirect Checker fixes, Robots and Sitemap fixes, Site Crawler fixes and HTTP Error Audit fixes.

This is the area to look at first, because nothing else in the report matters on a page that cannot be crawled. A disallow rule that blocks the whole site, server errors in the 500 range, and redirect loops are the most serious findings anywhere in the PDF. A dead link from your main navigation comes next, because it appears on every page.

The four checks also feed each other. The HTTP Error Audit shows the page each broken link was found on, and the Site Crawler shows whether the same broken link repeats across many pages, which points to a template. When you replace a removed page with a redirect, point it straight at the final address so you do not create a new chain for the Redirect Chain Checker to report. And when URLs change, update the sitemap so it lists final addresses only, not ones that redirect or return an error.

Orphaned pages found by the Site Crawler can often be fixed by linking them from a relevant category or hub page, rather than by adding them to the sitemap alone.
The redirect from http:// to https:// is also looked at by the Security Audit. Make it a single permanent hop to the preferred host.

International and local

The Hreflang Checker and the Local SEO Checker are the two checks whose results depend most on what kind of business you run, so read them with that in mind. Their hubs are Hreflang fixes and Local SEO fixes.

If your site is in one language for one country, no hreflang tags is the correct result and the report says so; there is nothing to fix. If you do have language or regional versions, hreflang errors deserve a higher place on the list than they look, because the effect is the wrong version ranking in the wrong country. Hreflang also interacts with the crawling area: every alternate address should return a normal page, not a redirect or an error, and should be the canonical version of that page.

For a business that serves customers in a place, the Local SEO Checker connects to three other areas. Its schema half reads the same LocalBusiness block as the structured data checks. Its on-page half looks for a visible name, address and phone number, which overlaps with the identity details the Trust Audit looks for. And the name, address and phone it recommends should be used identically on the site, in the schema and in every directory listing. Fix the website version first, then work through the directory list it gives you in its order of must-have, high priority and recommended.

💡 If you run an online-only business with no customer-facing address, the local checks are less relevant. Concentrate on the identity details the Trust Audit asks for instead.

Security and trust

The Security Audit checks what your site sends to every visitor, such as security headers, the TLS certificate, DNS and email authentication records, and it stays passive on any site. The Trust Audit, which needs a free sign-in, looks at domain age, WHOIS, reputation with Google Web Risk, backlink spam and authority signals, published contact details and robots.txt. Their hubs are Security Audit fixes and Trust Audit fixes.

Most security findings are server or DNS settings rather than page files, so they are listed separately from the file fixes in the AI fix prompt, and the prompt tells the AI tool not to touch them. Plan them as a job for whoever runs your hosting or DNS. Where the headers go depends on your stack; if you run your own nginx server, the nginx security headers guide shows the configuration.

Some items are urgent wherever they appear: an expired or invalid certificate, a reputation flag, or secrets left in page source. Others are high value and quick: HSTS, a Content-Security-Policy and frame protection also count towards the GDPR Audit, so setting them improves two sections. Introduce a CSP in report-only mode first, because a too-strict policy can block your own scripts and break features that other sections then report as errors.

Trust findings split into quick and slow. Published contact details, clear owner and identity details and sensible robots.txt rules are quick. Domain age and authority only change with time, so note them and move on rather than holding up the rest of the report.

Which findings to fix first across the whole report

Inside each section the report already lists problems worst first. Across sections, use these tiers. Anything in a higher tier comes before anything in a lower one, whichever audit reported it.

Reachability and safety. Whole-site crawl blocks, server errors, redirect loops, an invalid certificate, a Google Web Risk flag, and secrets or keys visible in page source.
Things happening to visitors without their consent. Tracking cookies on first load and trackers firing before consent.
Template faults. Anything the Site Crawler shows repeating across many pages, plus header, footer and layout problems such as a wrong canonical, missing viewport, duplicate H1 or missing landmarks.
Multi-section fixes. Image dimensions and sizes, deferred scripts, broken JSON-LD and security headers, because each clears findings in several sections.
Broken links and redirect chains on pages people actually visit.
Content-level items. Alt text, link text, meta descriptions, privacy policy wording and local listing details.
Maintainability notes in the CSS and JavaScript Checkers, and slow signals such as domain age.

⚠️ Do not chase the overall score by fixing the easiest items first. A report can gain points from tidy-up work while a crawl block or consent problem stays in place, and those matter far more to the business.

A sensible order of work

Run the audit. Start a Quick Audit from the Combined Audit page, signed in if you can so the Site Crawler and Trust Audit are included. Keep the PDF as your starting point.
Sort the findings into two piles. Page files (HTML, CSS, JavaScript, templates and content) in one, and server, hosting and DNS settings in the other. The AI fix prompt already separates them this way.
Clear tier one. Crawl blocks, server errors, loops, certificate and reputation problems, and anything exposed in page source.
Fix the templates. Head tags, header and footer, consent setup and script loading, on a staging copy if you have one.
Do the images in one pass. Resize, convert, set dimensions and write alt text together.
Repair structured data so each type is output once and parses cleanly, and align it with the visible name, address and phone.
Hand over the server list. Security headers, TLS, redirects and email authentication records go to your host or developer, or use the quote link in the report.
Finish with content. Link text, descriptions, policy wording and directory listings.
Re-run and compare. Check that fixed items have gone and that nothing new has appeared, especially after a CSP or script change.

💡 The example report walk-through shows this order applied to a fictional business, and the Combined Audit Guide explains every part of the report.

Questions and answers

1. Why does the same problem appear in several sections of my report?

Each audit in the Combined Audit is written to stand alone, so it reports everything it can see on the page without knowing what the other audits found. An image with no width or height, for example, is relevant to image optimisation, to layout shift and to loading speed, so up to four sections can mention it. That is not a fault in the report. It is a hint that one change will clear several findings, which is why those fixes are worth doing early.

2. Should I fix the lowest-scoring audit first?

Not necessarily. A low score in a maintainability-heavy section such as the CSS Checker can matter less than a single serious finding in a section that otherwise scores well, such as a disallow rule blocking the whole site. Use the scores to see where the work is concentrated, but choose the order by impact: reachability and safety first, then consent, then template faults, then fixes that clear several sections, and leave maintainability notes until last.

3. Can I give the whole report to a developer or an AI tool?

Yes, and the report is built for that. The AI fix prompt at the end covers only your site's own HTML, CSS and JavaScript, lists file fixes first, then suggestions, then server settings, and tells the tool to work on a copy, back up files and make one change at a time. Server, hosting and DNS items are kept separate for you or your host. If you prefer someone else to do it, every section of the PDF has a quote link.

4. How often should I re-run the Combined Audit?

Re-run it after each batch of fixes so you can confirm they worked and that nothing else broke, which is common after script, consent or security header changes. Beyond that, a run after any theme update, plugin change, redesign or migration is sensible, because those are the moments when template faults and broken links appear. For a stable site with no changes, an occasional check is enough to catch new broken links and expired details.

5. Some findings need my web host. What do I ask for?

Copy the server, hosting and DNS items from the report rather than paraphrasing them, since they name the exact header, record or setting involved. Typical requests are adding security headers such as HSTS, making the http to https redirect a single permanent hop, renewing or reconfiguring the TLS certificate, and adding email authentication records such as SPF and DMARC. Ask the host to confirm each change, then re-run the audit to check that the findings have cleared.

6. Why did my overall score barely move after I fixed a lot?

The overall score summarises a large number of checks, so a dozen small fixes in one section can be a modest change overall, and some results are measurements rather than pass or fail checks. Speed metrics in particular vary from run to run, and image or script improvements can take a couple of runs to show clearly. Slow signals in the Trust Audit, such as domain age, do not change with any fix. Compare the individual findings between reports, not just the headline number, to see what really changed.

7. Do I need to fix every finding in the report?

No. Some results are informational, some are suggestions you can choose from, and some do not apply to every site, such as hreflang for a single-language business or local listings for an online-only one. The goal is that nothing serious remains and that the findings you leave are deliberate decisions. Note why you are leaving each one, so the next person reading the report does not spend time on it again.

Run the Combined Audit

The Combined Audit runs up to 21 checks in one Quick Audit, from meta tags and structured data to speed, accessibility, crawling, security, trust and GDPR, and sends one PDF report with problems worst first.

Run the Combined Audit →