Understanding Your First Report: Structure and Sections

What does an InspectWP report actually show? This guide walks you through all 13 sections of a report and explains what data lives where and how to read it.

An InspectWP report is the result of a single crawl: we open your site in a real headless Chrome browser, look at HTML, scripts, response headers, DNS, certificates and a few more sources, and condense everything into one structured page. This guide explains how that page is laid out, what each section contains and how to work with it.

Tip: Before you read this article, run a report for any of your own sites and keep it open in a second tab. Everything below will then be much more concrete.

1. The report at a glance

Every report opens with a header showing the crawled URL, the timestamp, a screenshot of what the crawler actually saw and a few quick indicators. Below the header you'll find 13 thematic sections, each rendered as a collapsible accordion. You can open and close them individually. Premium users can also export the report as a PDF or trigger a fresh crawl directly from the page.

2. The 13 sections

The order is the same in every report so you can find your way around quickly:

WordPress

Detected WordPress version and whether it's still supported, the active theme and possible child theme, all detected plugins, cache plugins, multisite status and signs of the Gutenberg editor.

Security

SSL/TLS certificate status, HTTP security headers (CSP, HSTS, X-Frame-Options, Referrer-Policy and more), reachable debug.log, REST-API exposure and detected security plugins.

GDPR

Privacy-relevant findings: Gravatar, Google Fonts, Google Analytics, Google Maps, Facebook Pixel and other external resources loaded by the page.

SEO

Title tag, meta description, canonical URL, robots meta, sitemap, JSON-LD structured data and Open Graph tags.

Tools

Third-party tools detected on the page, for example tag managers, tracking tools, analytics scripts, page builders and chat widgets.

HTML

Doctype, viewport, favicons, the number of CSS/JS files, console errors and warnings observed during the crawl, and any insecure HTTP URLs found on an HTTPS page (mixed content).

Content

Image count and stats, word count, heading hierarchy (H1–H6), used fonts and email addresses found on the page.

Headers

The complete HTTP response headers as the server returned them. Useful when debugging caching, CDN behaviour or compression.

DNS

DNS records for the domain (A, AAAA, MX, NS, TXT and friends).

Email

Email-related DNS entries: SPF, DKIM, DMARC. Important for deliverability when the site also sends mail.

Performance

HTTP version (HTTP/1.1, HTTP/2, HTTP/3), content encoding (gzip, brotli) and HTML payload size.

Hosting

Detected hoster, server software, PHP version and IP address. Note: a CDN or reverse proxy in front of your origin can affect this.

Misc

Everything that didn't fit elsewhere: the exact crawled URL, cookies set during the page load, plus localStorage and sessionStorage entries.

3. How to read a report

Reports can look overwhelming on first contact. The recommended workflow:

  • Start with the colour: every field has a status: green, yellow, red or grey. Red issues should be fixed first, then yellow, then a quick scan of the grey fields. There's a separate article that explains the colours in detail: Understanding the status system.
  • Work by topic: if your goal today is SEO, fix everything in the SEO section first instead of jumping back and forth.
  • Use the screenshot: if a section looks suspiciously empty, the screenshot tells you whether the crawler actually saw your real site or a block page. If it shows a block page, see What to do when the crawl fails.

4. Frequently asked questions

The crawled site isn't running WordPress. InspectWP works on non-WP sites too, but the WordPress-specific block then carries no data and is disabled.

5. Related articles