Pages

The Pages view is where you move from a site-wide count to a specific URL. Use it to understand what Screpy saw for each crawled page and to decide whether an issue is isolated, template-wide, or caused by a crawl constraint. Select a completed crawl first: its timestamp, URL allowance, and score define the snapshot you are reviewing.

Start with the page state

Filter for the signal you want to investigate: non-successful status codes, missing or duplicate metadata, canonical issues, indexability concerns, or a specific URL path. Search by URL, final URL, or title. Open a representative URL before changing anything. A single broken page can be content-specific; the same finding across a template usually needs a template-level fix.

Check the HTTP status and final URL together. Redirects can be expected, for example after a deliberate URL move, but redirect chains and unexpected destinations make a page harder to crawl and maintain. A page that is blocked, unavailable, or excluded should be evaluated in the context of its intended search visibility—not every URL needs to be indexed.

Use the filters as an audit checklist

The filter panel covers the most common technical and on-page checks:

• Response codes: successful pages, redirects, client errors, and server errors.
• Performance and content: slow pages, thin content, low content ratio, language mismatch, and deeply nested pages.
• Titles and descriptions: missing, short, long, and duplicate values.
• Headings: missing or multiple H1s, duplicate H1s, missing H2s, empty headings, and heading jumps.
• Canonicals, structured data, and social tags: canonical coverage and mismatches, schema, Open Graph, and Twitter Card signals.
• Images and security: pages with missing image alt text, and missing HSTS, CSP, X-Frame-Options, or X-Content-Type-Options headers.

The table summarizes each URL with its status, response time, word count, SEO state, internal and external links, image signals, and crawl depth. Export a filtered view as CSV or Excel when it needs to become an implementation list.

Use page details to confirm the fix

Review the title, description, headings, canonical signal, robots directives, and on-page findings for the exact page. Make the change in the CMS or application, publish it, then run another crawl. Do not mark an item as fixed only because the source code changed; the public page must return the expected result.

If the row has Queries, use it to connect the crawled URL to its search-query context. This is useful when a technical or content change must be prioritised by actual visibility rather than by an audit count alone.

Common questions

Why is a page missing from the list?

Screpy can only list pages it can reach within the selected crawl scope. Check crawl depth, URL limits, internal links, robots rules, redirects, and whether the page requires authentication.

Should every page have the same SEO metadata?

No. Consistent templates are useful, but titles and descriptions should describe the individual page. Repeating the same text across many indexable pages makes it harder for search engines and users to distinguish them.