Skip to content
SteadyPress
Home SiteReview documentation Running a scan

Running a scan

A SiteReview scan audits the WordPress site the plugin is installed on. The site URL is derived from home_url() and cannot be edited — SiteReview audits the current install, not arbitrary URLs.

Selecting pages

The New Scan view shows a multi-select dropdown populated from your published Pages.

  • The homepage is shown at the top, always selected, not unselectable, tagged (Homepage).
  • If your site has a static Posts page configured, it appears immediately after the homepage, tagged (Blog Posts).
  • You can add up to five additional Pages on top of the homepage.
  • The dropdown supports type-ahead filtering on Page titles.
  • Each selected Page displays its slug as a small caption beneath the title.
  • An estimated scan time indicator updates as pages are added — approximately 30 seconds of base time plus 30 seconds per page.

If your site has zero published Pages, the dropdown is hidden and only the homepage is scanned.

Section toggles

Section toggles appear in two places and mean two different things.

On the New Scan view (pre-scan exclusion): turning off a section before the scan means that section is not measured at all. It will not appear in the report, the public URL, or the download.

On the View Report view (post-scan exclusion): turning off a section after the scan hides it from the rendered report, the public URL, and the download. The underlying data remains stored. Re-enabling the section regenerates the static HTML to include it again.

Executive Summary and Recommendations cannot be toggled off — they are foundational to the report.

A common pattern: pre-exclude Accessibility on the New Scan view when your agency runs a separate accessibility process, or post-exclude SEO after a scan when a particular client's deliverable does not need it.

What each section covers

WordPress Status. Core version against the latest stable, PHP version, active theme with parent theme indicator, plugin counts (active, inactive, updates available), a stacked bar visualization of plugin status, and a table of the top seven plugins with updates available.

Performance. Mobile and desktop Performance scores from PageSpeed Insights, Core Web Vitals (LCP, INP, CLS, TTFB) rendered as threshold meters, supporting metrics like Speed Index and Total Blocking Time, the full list of Lighthouse opportunities with savings estimates, detected caching plugin, and detected CDN. When PSI returns Chrome User Experience Report field data, a Real-user data (last 28 days) subsection appears with LCP, INP, and CLS values from real visitors.

Site Security. SSL certificate issuer and expiry with TLS version, Mozilla HTTP Observatory grade and per-test grid for ten security headers, malware and blacklist results from Sucuri SiteCheck, WordPress hardening checks (version exposure, readme.html, WP_DEBUG, default admin username, file editing, XML-RPC, username enumeration, default login URL), and deep state from installed security plugins (Wordfence, Solid Security, Defender, Sucuri Plugin) rendered against a common six-field schema.

Mobile Friendliness. Mobile, tablet, and desktop device cards with status, viewport meta presence, tap-target spacing, font-size legibility, and content-width audits.

Accessibility. axe-core 4.x runs WCAG 2.2 AA testing on every scanned page. Severity counters (Critical, Serious, Moderate, Minor), a top-six most-violated rules bar chart, a critical-violation findings list with WCAG and Section 508 mappings, and pages-tested summary. Accessibility is the only section that runs in your browser tab (axe-core needs a real DOM) — the scan-progress UI tells you to leave the tab open until Accessibility completes.

Hosting. A vertical infrastructure stack diagram showing CDN, web server, PHP, database, and origin location. Data list with server software and version, PHP version with EOL pill, database engine and version, PHP memory limit, HTTP/2 status, origin IP (or behind CDN — not directly probeable), origin country, and hosting provider inferred from IP block. SiteReview reports country-level location only; city and region are not surfaced.

Domain and DNS. Registrar, registered date, expiry with days-remaining caption, registrar lock status, DNSSEC status, A and AAAA records, MX records, NS records, CAA records, and three side-by-side cards for SPF, DKIM, and DMARC.

SEO. robots.txt presence and directives, XML sitemaps with duplicate detection, SEO plugin detection, per-page coverage bars for meta titles, meta descriptions, H1 tags, and image alt text (with totals like 142 of 195 images — 73%), schema markup @type values found across pages, Open Graph and Twitter Card completeness, and a sitemap duplication note when two distinct generators are emitting sitemaps.

Each section ends with a status pill drawn from a canonical six-value enum: Healthy, Moderate, Poor, Skipped, Failed, Partial.

During the scan

When you click Run Scan, the UI transitions to a scan-in-progress state showing per-section status (queued, running, complete, failed) and an overall indeterminate progress indicator. The scan typically completes in three to six minutes; six-page Pro scans can take up to fifteen minutes when PageSpeed Insights is slow.

For all sections except Accessibility, you can navigate away from the WordPress admin tab and the scan continues server-side. The Accessibility section requires the tab to stay open because axe-core runs inside a hidden iframe in your browser; the scan-progress UI tells you this explicitly. If you close the tab during Accessibility analysis, the section pauses and resumes when you return to the SiteReview admin page.

If any section fails — most commonly because of a PageSpeed Insights rate limit or a Mozilla Observatory timeout — the rest of the report is fully usable. Failed sections render with an error state and a Retry section affordance.

The report

The report is rendered as a single scrollable document on a gray background, styled to look like a finished deliverable. A sticky table of contents on the left lets you jump between sections.

From the report view, you can:

  • Toggle individual sections on or off (the post-scan visibility filter)
  • Copy the public report URL
  • Download the report as a single self-contained HTML file
  • Set an optional password gate on the public URL
  • Edit text inline (Pro only)
  • Rotate the public URL token (Pro only)
  • Delete the report
  • Re-run the scan (this replaces the report; any inline edits are lost and the UI warns you)

The public URL and download

When a scan completes, SiteReview writes a self-contained static HTML file to wp-content/uploads/sitereview/reports/{token}/index.html where {token} is a 32-character random string. The public URL /sitereview-reports/{token}/ rewrites to that file via a rewrite rule installed at activation. If your host disables rewrites (some nginx and IIS configurations), the plugin falls back to exposing the direct uploads URL. Both URLs serve the same file.

The public URL survives plugin deactivation. The file lives in wp-content/uploads/, so the web server serves it directly without WordPress in the request path.

The Download HTML button serves the same self-contained file with Content-Disposition: attachment. All CSS is inlined, all JavaScript is inlined (kept minimal — only smooth-scroll behavior for the TOC), images are embedded as base64 data URIs, fonts are bundled via @font-face data URIs. Typical download size is 1 to 3 MB, with a hard cap of 5 MB. The file works when opened from the local filesystem and requires no external requests once loaded.

The rendered report includes <meta name="robots" content="noindex, nofollow"> and an X-Robots-Tag header via per-directory .htaccess on Apache, so reports are not indexed by search engines. On nginx and IIS, where per-directory rewrite is not possible, SiteReview surfaces a settings notice explaining that the headers cannot be enforced and providing a snippet you can hand to your host.

Optional password gate

For reports that contain particularly sensitive findings, you can attach a password to the static file from the Set password affordance in the report viewer's action group. The password is hashed in the browser via PBKDF2-SHA256 with 200,000 iterations and a per-report 16-byte salt; only the hash is embedded in the static HTML. The plaintext password is never stored.

The password gate is a soft barrier, not strong cryptography — a determined attacker with the static HTML can brute-force a weak password offline. The URL token remains the primary access control. For an actual leak, rotate the URL on Pro or delete the report on Free.

Re-running a scan

Re-running a scan reuses the existing report token by default. The static HTML is overwritten in place at the same URL, so a link you have already shared stays valid. On Free, this is the only way to refresh a report; on Pro, the Rotate URL action is the only path to a new token.

Re-running a scan replaces all report data and discards any inline edits you have made. The viewer warns you about this before the scan starts if edits exist.

Synchronous fallback for hosts without working cron

If your host does not run WP-Cron and you have not configured an external cron ping, Action Scheduler jobs will never fire. SiteReview detects this on first scan attempt and offers a degraded synchronous fallback button. The fallback:

  • Runs against the homepage only — your page selection is ignored
  • Skips Performance, Mobile Friendly, and Accessibility (these cannot fit a synchronous HTTP request lifetime)
  • Runs WordPress Status, Domain & DNS, Hosting, Site Security, and SEO with a total budget of four minutes
  • Generates no AI narrative on Pro — narrative generation would push the budget past four minutes

The synchronous fallback is documented as degraded mode and surfaces a persistent notice while it is the only available path. The fix is to configure a real cron ping; see the troubleshooting doc.

Need more help? Contact support.