Pages

The Pages report inside Screpy Website Audit turns a completed crawl into a URL-level inventory. It shows what Screpy received for each page, which checks need review, and whether a finding affects one URL, a shared template, or the wider site.

Select the right crawl snapshot

Choose a completed crawl and note its date, crawl settings, URL allowance, depth, and JavaScript rendering mode. The report describes that snapshot; it does not continuously update when the live site changes. If an expected URL is absent, first check crawl scope, robots rules, internal discovery, authentication, and the selected crawl rather than treating the absence as an on-page error.

Use All Pages to inspect the full inventory. Use All Issues to create an investigation queue across the checks below. The issue count is not a count of pages that must rank in search: utility URLs, redirects, archives, and intentionally non-indexable pages can be valid parts of a website.

The Missing Alt Images page filter is covered by the dedicated Image Alt Text guide because the correct diagnosis requires both the image and every page that uses it.

Read one row in context

Start with the URL, status code, and final destination. Then compare response time, word count, content ratio, crawl depth, title, description, headings, canonical, structured data, social tags, image findings, and security headers. Open a representative page and inspect its rendered output before deciding on a fix.

The scale of the pattern usually identifies ownership:

• One URL: likely an editorial, publishing, or isolated routing issue.
• One URL pattern: likely a template, CMS content type, or routing rule.
• Most pages: likely a site-wide layout, middleware, server, or crawl-configuration issue.

If the report includes search queries, use them to distinguish technically valid pages that deserve priority from low-value URLs with no meaningful visibility. Export a filtered CSV or Excel file when the result needs to become an implementation queue.

Choose an investigation path

Access and crawl behavior

Performance and content

Search appearance and page structure

Enhancements and protection

Prioritize findings

Fix access failures on valuable URLs first, followed by unintended redirects and canonical conflicts. Then prioritize search-appearance and content findings using organic visibility, conversions, internal importance, affected-template size, confidence, and effort. Security and social-preview work should be prioritized by risk and communication needs, not presented as guaranteed ranking improvements.

Do not optimize a site by making every count zero. A concise contact page can be useful, a deliberate redirect can be correct, a page can have no applicable structured data type, and a security policy can require careful testing before rollout.

Verify the result

Publish the change, inspect the public response and rendered HTML, then run a new crawl with comparable settings. Confirm that the intended status, destination, metadata, headings, canonical, or headers are present in the new snapshot. For search-facing changes, also use the appropriate external validator or Search Console report and allow time for recrawling.

Build a reliable page-audit baseline

The Pages report is a snapshot of URLs reached during one crawl. Before comparing issue counts, confirm that the crawl used the same starting URL, limits, robots rules, authentication state, and site version. A smaller crawl can produce fewer issues without any page being fixed.

Create a baseline by recording the crawl date, total pages, important templates, and known releases. Then move through the report in this order:

1. Access and response: 4xx, 5xx, redirects, and blocked resources.
2. Indexing signals: canonical tags, language, and content availability.
3. Page meaning: titles, descriptions, headings, and structured data.
4. Experience and architecture: response time, crawl depth, and security headers.

This sequence prevents time being spent polishing metadata on a page that cannot be reached reliably.

Compare distributions, not only totals

A healthy release can increase the total number of issues temporarily because Screpy discovers more pages. Compare the affected percentage and template distribution. Ten missing titles across ten pages is a sitewide failure; ten missing titles across 100,000 pages may be an isolated editorial queue.

When a count changes, ask:

• Did the total crawled-page count also change?
• Are the same URL types affected?
• Was a template, route, CMS rule, or rendering method released?
• Did pages move to another filter rather than become healthy?
• Can you reproduce the result on representative URLs?

Turn findings into an action queue

Prioritize by business importance, scale, user impact, and fix leverage. A template defect affecting every product page usually outranks dozens of unrelated low-value URLs. Assign each action an owner and expected data movement, then run a fresh crawl after deployment.

The result should be an explainable page inventory, not a perfect score. Use Screpy signals to decide where to investigate, and use Search Console, browser tools, server logs, and rendered HTML to confirm what is happening.

Frequently asked questions

Is every item in All Issues an SEO error?

No. Filters are investigation signals. Some rows describe intentional implementation choices or thresholds that need context. Confirm the page's purpose and rendered behavior before changing it.

Why did the issue total increase after fixing the site?

The latest crawl may have discovered more URLs or reached templates that previously failed. Compare the affected percentage, page types, and crawl settings rather than totals alone.

For broader editorial decisions, Google's people-first content guidance is a useful quality standard.

Google's Page indexing report guide is a useful companion when you need to compare Screpy's crawl snapshot with the URLs Google reports as discovered, crawled, or excluded.