Skip to main content
UI CoveragePremium Solution

Ignore views and links

UI Coverage measures every URL your tests visit and every link they could follow. That's usually what you want, but it means pages you don't own get counted as untested and quietly drag your score down. A third-party login screen captured mid-sign-in, an error page a test hit by accident, a marketing site linked from your footer: none of these are yours to test. When that noise is mixed in, a low score no longer tells you where the real gaps are.

This guide walks you through removing that noise with viewFilters. Excluding a URL keeps its pages out of your report and stops the untested links that point to it from counting against your score, so what's left is coverage of the application you actually intend to test:

  1. Find the views and links worth ignoring in your report.
  2. Add a viewFilters rule in your App Quality configuration.
  3. Regenerate a run and confirm the noise is gone.
  4. Keep your filters current as your app grows.

Reach for viewFilters when a URL is counted against you but isn't something your team is responsible for testing:

  • Third-party pages: Sign-in flows on an external identity provider (Okta, Auth0), a payment processor's hosted checkout, or embedded content you don't control. Your tests pass through them, but their UI isn't yours to cover.
  • Links to destinations you'll never test: Your marketing site, a help center, a status page, or a social profile linked from your app. No test visits them, so no view exists. The link is the only thing UI Coverage sees, and it counts as an untested link. Excluding the destination URL is the way to remove it.
  • Redirects and intermediate URLs: A /redirect step or an OAuth callback that tests pass through on the way to somewhere else, rather than a page users land on and interact with.
  • Sections outside your goals: Admin-only tools or informational pages that aren't part of what you set out to test.

If your goal is instead to organize URLs into named views rather than remove them, use views; to remove individual elements rather than whole pages, use elementFilters. See Which option do I need? for the full comparison.

Start by finding the URLs that are counted against you but sit outside your testing goals. You can do this in the Cloud UI or from your editor with an AI agent.

In the Cloud UI​

Open the UI Coverage tab of a recorded run and work through two sections:

  • Views: Scan for pages that appear in your report but you don't own or intend to test, such as a third-party auth screen, an embedded checkout, or an error page tests hit by accident. Note their URLs.
  • Untested links: Review the destinations your tests never visited. Each one is a page with no view, so it can only ever surface here. Links to your own marketing site, a help center, a status page, or an external partner are the usual candidates to exclude.
Cypress Cloud screenshot of the untested links section listing links whose destinations were never visited during the run

Expanding an untested link shows a Referrers tab (the views that link to the destination) and a URLs tab (the concrete destinations, grouped for dynamic routes). Use these to confirm a destination is genuinely out of scope before you exclude it, and to capture the exact URL or path you'll match on.

With an AI agent​

If you use an AI coding assistant, Cypress Cloud MCP can pull the same report into your editor, so you can find exclusion candidates without opening a browser. The agent queries UI Coverage for a run and returns the views and untested links as structured data you can scan and act on.

Find views and links to exclude with your AI assistant

Pull the UI Coverage report from Cypress Cloud and list the untested links and third-party views you might exclude with viewFilters.

Using Cypress Cloud, pull the UI Coverage report for the latest run on this branch. List the untested links, and any views that look like third-party or external pages, so I can decide which to exclude with viewFilters.

Review what it returns the same way you would in the Cloud UI: confirm each destination is genuinely out of scope before excluding it. See Work with AI agents for more prompts.

Step 2: Add a viewFilters rule​

Open the App Quality tab in your project settings in Cypress Cloud and add a viewFilters array. Each rule pairs a URL pattern with include: false to exclude the URLs it matches, plus an optional comment explaining why the rule exists:

App Quality Config
{
  "viewFilters": [
    {
      "pattern": "https://acme.okta.com/*",
      "include": false,
      "comment": "External Okta sign-in flow, not our UI to test"
    }
  ]
}

One rule removes both the excluded pages and any links pointing to them. Every other URL stays included, because a few rules govern how filters are applied:

  • Each URL is matched against your rules in order, and the first rule whose pattern matches decides whether the URL is included or excluded. Place specific rules before broad ones.
  • URLs that match no rule are included by default.
  • Patterns use URL Pattern API syntax matched against the full URL. A path-only pattern like /admin/* matches that path on any environment, while a hostname must match exactly unless it contains a wildcard (https://*.acme.com/*).

For the complete pattern-matching and validation rules, see the viewFilters reference.

Include only your application's URLs​

When your tests pass through many external pages, an allowlist is simpler than excluding each one. Include your application, then add a catch-all * rule that excludes everything else. Because the first match wins, the catch-all must come last:

App Quality Config
{
  "viewFilters": [
    {
      "pattern": "https://app.acme.com/*",
      "include": true
    },
    {
      "pattern": "*",
      "include": false,
      "comment": "Exclude anything that isn't the app itself"
    }
  ]
}

Exclude error pages in every environment​

A pattern without a protocol and hostname matches any environment your tests run against, whether that's localhost, staging, or production, so one rule covers them all:

App Quality Config
{
  "viewFilters": [
    {
      "pattern": "/404",
      "include": false
    },
    {
      "pattern": "/error/*",
      "include": false
    }
  ]
}

Exclude from UI Coverage without affecting Accessibility​

A viewFilters array at the root of your configuration applies to both UI Coverage and Cypress Accessibility. To exclude a URL from UI Coverage alone, nest viewFilters under a uiCoverage key. A nested list completely replaces the root-level one for UI Coverage (the two are not merged), so include every rule UI Coverage needs in the nested list:

App Quality Config
{
  "uiCoverage": {
    "viewFilters": [
      {
        "pattern": "https://docs.acme.com/*",
        "include": false,
        "comment": "Embedded docs: keep out of coverage but keep scanning for a11y"
      }
    ]
  }
}

Step 3: Regenerate a run and confirm​

After saving, regenerate a recent run from its Properties tab to reprocess it with your new filters. There's no need to rerun your tests. See Setting configuration for the steps.

The Properties tab for a run, with an Application Quality section at the bottom and a regenerate button to reprocess the run with the current configuration

In the regenerated report, confirm the excluded pages no longer appear as views and that links to the excluded URLs no longer count as untested. If a URL you excluded still shows up, an earlier rule is usually matching it first, or the pattern isn't matching the full URL. See troubleshooting view filters.

Step 4: Keep your filters current​

viewFilters is a living part of your configuration. As you add integrations, new external links, or new environments, revisit your rules so reports stay clean and every remaining gap is one worth a decision. If different runs need different exclusions, such as a smoke run versus a full regression run, apply them per run with profiles instead of maintaining one list for everything.

See also​

  • viewFilters configuration is the full reference for options, pattern matching, and validation.
  • Identify coverage gaps is the workflow for finding untested elements, links, and pages once the noise is gone.
  • Reduce noise covers the other adjustments, such as grouping repeated elements and stabilizing dynamic attributes, that sharpen a report.
  • Ignore elements removes individual elements from reports rather than whole pages.
  • views configuration groups and names URLs instead of removing them.
  • Untested links explains how a link's destination determines whether it counts against your score.
  • UI Coverage FAQ answers common questions about excluding URLs and coverage scores.

Contents