Setting Up Your Scans | Sitepager

A few minutes of setup helps you catch the right issues before every update. This page shows how to structure your scans so you catch the right issues consistently.

Start with Scan 1 and Scan 2. Add the others as they apply to your setup.

Recommended scan setup

Scan 1: Key pages Cover your highest-traffic, highest-stakes pages. Homepage, pricing, product pages, landing pages. Keep this scan focused on the pages where a broken layout, missing content, or SEO issue would have the most impact.

Run this before every update. It is fast to review and catches the changes that matter most.

To scope this scan to specific pages, use Include URLs in your scan settings to list only the pages you want covered. Include & Exclude Pages

Scan 2: Full site Cover your entire site. Every page Sitepager can discover from your root URL.

Run this every two weeks or before major updates. It catches anything that slipped through on lower-traffic pages. Missing pages, broken links that appeared in a CMS update, SEO gaps across the whole site.

Desktop and mobile

Create separate scans for desktop and mobile. Each device tracks independently.

A layout that looks right on desktop can break on mobile after a CMS update or global style change. Running both before every update catches this before your visitors do.

Start with desktop. When you are ready to add mobile, create a new scan for each of your existing scans. Key pages and full site both benefit from mobile coverage.

To create a mobile scan, set the Device to Mobile in your scan settings when creating a new scan.

If you have a staging environment

Create a separate scan for your staging URL the same way you created your production scan. This gives staging its own baseline and run history. You can keep iterating, re-running, and comparing against a known-good state without touching your production baseline.

Once staging looks right, use a Compare Environments scan before pushing to production. It crawls both environments fresh and shows you a live diff of exactly what is different between staging and production at that moment.

This answers the question: “Is what I built on staging exactly what is going to go live?”

Here is the full release loop from start to finish:

1. Make your changes on staging
2. Run your staging scan against its baseline. Confirm staging looks right.
3. Run the Compare Environments scan. Confirm staging and production only differ where you expect.
4. Push to production
5. Run your production scan. Confirm production matches what you approved on staging.

Staging and production workflow

This workflow shows how to validate changes on staging before pushing them to production.

flowchart TD

A["1. Make your changes on staging"]
B["2. Run a staging scan to validate the changes"]
C["3. Compare staging and production to confirm what changed"]
D["4. Push the changes to production"]
E["5. Run a production scan to confirm everything looks correct"]
F["6. Update the production baseline"]

A --> B
B --> C
C --> D
D --> E
E --> F
F -.->|repeat| A

This is the full release validation loop. Each step catches a different type of issue.

If your site serves multiple regions or languages

Create a separate scan for each region or language variant. Each scan is independent because it has its own URL, its own baseline, and its own run history. A change to your US pages does not affect your France baseline.

Common setups:

• One scan per language (English, French, German)
• Or one scan per region if content varies by location

For region-specific rendering, testing what visitors in a specific country actually see, use geolocation settings on each scan. Geolocation Testing

Use Exclude URLs in your scan settings to limit each scan to only the pages for that region or language. This keeps results clean and focused. Include & Exclude Pages

Run regional scans together before every update that touches global styles, templates, or shared components.

When to enable Lighthouse checks

Lighthouse checks are optional. You can enable them on any scan, but they are most useful on your full site scan. Enable them under Additional Checks in your scan settings.

Run Lighthouse:

• Before major updates
• After performance-related changes. Image updates, new animations, plugins, scripts, or any new third-party tools added to your site.
• Monthly as a baseline performance health check. If you regularly add new content, scripts, or integrations, run it more frequently. Performance can drop from a single plugin or unoptimised image.

When to enable broken external links

External link checking is optional. You can enable it on any scan, but it is most useful on your full site scan. Enable it under Additional Checks in your scan settings.

Run broken external links:

• Every two weeks alongside your full site scan
• Before a major launch or campaign
• When you have added new pages, blog posts, or resources with external references

Optional: Interactions scan

If your site has key interactions worth validating, like sign-up modals, contact form modals, or hover states, set up a dedicated interactions scan.

How to scope it:

If the same interaction appears across many pages, like a nav hover or a footer modal, you do not need to include every page. Include one representative page. Sitepager will capture the interaction there.

If different pages have different interactions, include each of those pages so every interaction gets captured.

If the same interaction appears across many pages, consider adding a generic class to those elements on your website first. This makes it easier to target them all in Sitepager with a single selector. Testing with Generic Classes

Once your site is ready, configure which elements Sitepager should interact with in your scan settings. Hover & Click Selectors

Run this scan before any update that affects interactions.

How to name your scans

You will end up with multiple scans. Name them so anyone on your team knows exactly what each one covers without opening it.

Use this pattern: [Scope or environment] - [Device] - [Region]

Examples:

• Key Pages - Desktop
• Full Site - Desktop
• Full Site - Mobile
• Staging - Desktop
• Full Site - Desktop - FR

Consistent naming means you find the right scan instantly and re-run it with confidence.

Recommended cadence

Scan	When to run
Key pages	Before every update
Full site	Every two weeks or before major updates
Staging scan	While iterating on staging. Run after every change.
Compare Environments scan	Before every push to production. Run after staging scan.
Regional scans	Before updates touching global styles or shared components
Lighthouse	Monthly or after any performance-related change
Broken external links	Every two weeks on full site scan
Interactions (optional)	Before any update that affects interactions

What to do next

Your scans are set up. Run them as part of every update. Go to Sitepager