{
  "doc": {
    "id": "ui-coverage/guides/ignore-elements",
    "title": "Ignore elements in UI Coverage reports",
    "description": "Exclude third-party widgets, chat launchers, cookie banners, and other out-of-scope elements from Cypress UI Coverage with elementFilters, so your coverage score and untested-elements list stay focused on real gaps.",
    "section": "ui-coverage",
    "source_path": "/llm/markdown/ui-coverage/guides/ignore-elements.md",
    "version": "e6c8d867c21227247f14714fb5690c7c018983c5",
    "updated_at": "2026-08-08T12:39:37.868Z",
    "headings": [
      {
        "id": "ui-coverage/guides/ignore-elements#ignore-elements",
        "text": "Ignore elements",
        "level": 1
      },
      {
        "id": "ui-coverage/guides/ignore-elements#when-to-ignore-an-element",
        "text": "When to ignore an element",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/ignore-elements#step-1-find-the-elements-to-ignore",
        "text": "Step 1: Find the elements to ignore",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/ignore-elements#from-the-cloud-ui",
        "text": "From the Cloud UI",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#with-an-ai-agent",
        "text": "With an AI agent",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#step-2-add-an-elementfilters-rule",
        "text": "Step 2: Add an elementFilters rule",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/ignore-elements#exclude-everything-inside-an-iframe-or-shadow-dom",
        "text": "Exclude everything inside an iframe or shadow DOM",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#keep-specific-elements-out-of-a-broad-exclusion",
        "text": "Keep specific elements out of a broad exclusion",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#exclude-an-area-for-your-teams-runs-only",
        "text": "Exclude an area for your team's runs only",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#exclude-elements-from-your-markup-instead",
        "text": "Exclude elements from your markup instead",
        "level": 3
      },
      {
        "id": "ui-coverage/guides/ignore-elements#step-3-validate-the-result",
        "text": "Step 3: Validate the result",
        "level": 2
      },
      {
        "id": "ui-coverage/guides/ignore-elements#see-also",
        "text": "See also",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "ui-coverage/guides/ignore-elements#when-to-ignore-an-element",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "When to ignore an element",
      "heading_level": 2,
      "content_markdown": "## When to ignore an element\n\nReach for an exclusion when an untested element isn't a gap you'd ever close:\n\n*   **Third-party widgets** you don't control, such as chat launchers, cookie consent banners, analytics or session-replay overlays, feedback and survey popups, social share buttons, and A/B-testing toolbars. Your team isn't responsible for testing them, so they shouldn't count as gaps.\n*   **Out-of-scope controls** you've deliberately decided not to test, such as a test-only debug panel, an internal admin toggle, or a decorative control that triggers no behavior.\n*   **Elements inside an embed** you don't own, such as a payment iframe, an embedded media player, a maps widget, or a third-party sign-in form rendered in an iframe or shadow DOM.\n\nIf an element is a real part of your product that you haven't tested _yet_, don't exclude it. That's a gap worth keeping. See [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md) for how to close it instead.\n",
      "section": "ui-coverage",
      "anchors": [
        "when-to-ignore-an-element"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 203
    },
    {
      "id": "ui-coverage/guides/ignore-elements#step-1-find-the-elements-to-ignore",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Step 1: Find the elements to ignore",
      "heading_level": 2,
      "content_markdown": "## Step 1: Find the elements to ignore\n\nStart from a recorded run and collect the elements that don't represent real gaps, along with a stable way to match each one. Do this in the Cypress Cloud UI, or have an AI agent shortlist candidates for you through Cypress Cloud MCP.\n\n### From the Cloud UI\n\nOpen the run's **UI Coverage** tab and scan the **Untested elements** section for entries that don't represent real gaps:\n\n1.  Look for untested elements your tests will never interact with, like the examples above.\n2.  Expand an element to see its selector, and note a stable way to match it: an `id`, a `data-*` attribute, a class, or a container it lives in.\n3.  Prefer a selector that matches a whole family at once (a third-party widget and everything inside it) over listing each element individually.\n\n### With an AI agent\n\nIf you use an AI coding assistant, [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) lets it pull the same report into your editor and shortlist exclusion candidates, so you can skip the manual scan. See [Work with AI agents](/llm/markdown/ui-coverage/work-with-ai-agents.md) for setup and more prompts.\n\nFind elements to ignore with your AI assistant\n\nShortlists untested elements worth excluding, with a suggested selector for each.\n\nUsing Cypress Cloud MCP, pull the UI Coverage report for the latest run on this branch. First, list all of the untested interactive elements. Then, from that list, give me a second list of the ones that look like third-party widgets or out-of-scope controls worth excluding, such as chat launchers, cookie banners, analytics overlays, and embeds. For each element you suggest excluding, include a stable CSS selector I can drop into an elementFilters rule to exclude it and everything inside it.\n\nTreat the agent's list as a shortlist, not a decision: you still confirm which entries are genuinely out of scope versus a real gap before excluding them.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-1-find-the-elements-to-ignore"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 419
    },
    {
      "id": "ui-coverage/guides/ignore-elements#from-the-cloud-ui",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "From the Cloud UI",
      "heading_level": 3,
      "content_markdown": "### From the Cloud UI\n\nOpen the run's **UI Coverage** tab and scan the **Untested elements** section for entries that don't represent real gaps:\n\n1.  Look for untested elements your tests will never interact with, like the examples above.\n2.  Expand an element to see its selector, and note a stable way to match it: an `id`, a `data-*` attribute, a class, or a container it lives in.\n3.  Prefer a selector that matches a whole family at once (a third-party widget and everything inside it) over listing each element individually.\n",
      "section": "ui-coverage",
      "anchors": [
        "from-the-cloud-ui"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 121
    },
    {
      "id": "ui-coverage/guides/ignore-elements#with-an-ai-agent",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "With an AI agent",
      "heading_level": 3,
      "content_markdown": "### With an AI agent\n\nIf you use an AI coding assistant, [Cypress Cloud MCP](/llm/markdown/cloud/integrations/cloud-mcp.md) lets it pull the same report into your editor and shortlist exclusion candidates, so you can skip the manual scan. See [Work with AI agents](/llm/markdown/ui-coverage/work-with-ai-agents.md) for setup and more prompts.\n\nFind elements to ignore with your AI assistant\n\nShortlists untested elements worth excluding, with a suggested selector for each.\n\nUsing Cypress Cloud MCP, pull the UI Coverage report for the latest run on this branch. First, list all of the untested interactive elements. Then, from that list, give me a second list of the ones that look like third-party widgets or out-of-scope controls worth excluding, such as chat launchers, cookie banners, analytics overlays, and embeds. For each element you suggest excluding, include a stable CSS selector I can drop into an elementFilters rule to exclude it and everything inside it.\n\nTreat the agent's list as a shortlist, not a decision: you still confirm which entries are genuinely out of scope versus a real gap before excluding them.\n",
      "section": "ui-coverage",
      "anchors": [
        "with-an-ai-agent"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 229
    },
    {
      "id": "ui-coverage/guides/ignore-elements#step-2-add-an-elementfilters-rule",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Step 2: Add an elementFilters rule",
      "heading_level": 2,
      "content_markdown": "## Step 2: Add an elementFilters rule\n\nOpen the **App Quality** tab in your project settings in Cypress Cloud and add an [`elementFilters`](/llm/markdown/ui-coverage/configuration/elementfilters.md) rule. Each rule pairs a CSS selector with `include: false` to exclude the elements it matches. Here, a support chat widget rendered by a third party is removed so it stops counting as an untested element:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"#intercom-container, #intercom-container *\",      \"include\": false,      \"comment\": \"Third-party support chat, not part of our app\"    }  ]}\n```\n\nTwo things decide whether a rule matches:\n\n*   **The selector must match the interactive elements themselves, not just a container around them.** A rule with the selector `#intercom-container` matches only that one `<div>`, not the buttons inside it. To exclude everything within a container, include its descendants with a descendant selector such as `#intercom-container *`, as above.\n*   **The first matching rule wins.** Rules are evaluated top to bottom, and each element is decided by the first rule whose selector matches it. List specific rules before general ones.\n\n### Exclude everything inside an iframe or shadow DOM\n\nThird-party embeds often render inside an iframe or shadow DOM. Pair a wildcard selector with `documentScope` to remove the entire embed at once. The `documentScope` selector matches the iframe or shadow-DOM host in its parent document:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"*\",      \"include\": false,      \"documentScope\": [\"iframe[title='Secure payment']\"],      \"comment\": \"Embedded third-party payment form\"    }  ]}\n```\n\nFor content nested more than one level deep, list one selector per host from outermost to innermost. See the [`documentScope` reference](/llm/markdown/ui-coverage/configuration/elementfilters.md#Options) for details.\n\n### Keep specific elements out of a broad exclusion\n\nBecause the first matching rule wins, an `include: true` rule placed _before_ a broader exclude rule protects the elements it matches. This is useful when a third-party container also holds elements you _do_ want to test, such as your own navigation links inside a vendor toolbar:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"nav a\",      \"include\": true,      \"comment\": \"Keep our nav links despite the vendor exclusion below\"    },    {      \"selector\": \"[data-vendor] a\",      \"include\": false,      \"comment\": \"Ignore links rendered by the vendor toolbar\"    }  ]}\n```\n\nOn its own, an `include: true` rule changes nothing, since everything is included by default. It only matters as an exception ordered ahead of an exclude rule. For the full evaluation model, see [How are elementFilters rules applied?](/llm/markdown/ui-coverage/configuration/elementfilters.md#How-are-elementFilters-rules-applied).\n\nSetting `elementFilters` at the root of your configuration affects both UI Coverage and Cypress Accessibility. To exclude elements for UI Coverage only, nest the property under a `uiCoverage` key. Note that `include: true` exceptions have no effect in Cypress Accessibility. See [Scope](/llm/markdown/ui-coverage/configuration/elementfilters.md#Scope).\n\n### Exclude an area for your team's runs only\n\nA root-level rule changes the report for _everyone_. When several teams share one Cypress Cloud project, that's often too broad: an area that's noise for your team may be exactly what another team is responsible for testing. Excluding it at the root would erase it from the other team's report too.\n\nUse a [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md) override to scope the exclusion to your own runs. A profile applies its `config` only to runs recorded with a matching [`--tag`](/llm/markdown/app/references/command-line.md#cypress-run-tag-lt-tag-gt), so your team tags its runs and gets a report that drops what it doesn't own, while every other team's runs keep the base configuration.\n\nFor example, the Account team doesn't own the support-chat widget, so its runs exclude it, but the Support team's runs (and the default report) still count it:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"#analytics-overlay, #analytics-overlay *\",      \"include\": false,      \"comment\": \"Analytics overlay, noise for every team\"    }  ],  \"profiles\": [    {      \"name\": \"aq-config-team-account\",      \"config\": {        \"elementFilters\": [          {            \"selector\": \"#analytics-overlay, #analytics-overlay *\",            \"include\": false,            \"comment\": \"Repeat base rules — a profile replaces the base list, it doesn't merge\"          },          {            \"selector\": \"#support-chat-widget, #support-chat-widget *\",            \"include\": false,            \"comment\": \"Account team doesn't own support chat, so it isn't a gap for us\"          }        ]      }    }  ]}\n```\n\nThe Account team records with the matching tag, and only those runs pick up the extra exclusion:\n\n```\ncypress run --record --tag \"aq-config-team-account\"\n```\n\nA profile's `elementFilters` **replaces** the base list rather than merging with it, so repeat every base rule the tagged run still needs, as the example does for the analytics overlay. See [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md) for merge behavior and how a tag selects a profile.\n\n### Exclude elements from your markup instead\n\nWhen the team that owns the markup also owns the decision to exclude an element, you can do it in application code instead of Cloud configuration. Add [`data-cy-ui-interactive=\"exclude\"`](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Overriding-interactive-elements-with-data-cy-ui-interactive) to a single element, or `data-cy-ui-interactive=\"exclude-all\"` to a container to also exclude everything inside it:\n\n```\n<!-- Excludes just this button --><button data-cy-ui-interactive=\"exclude\">Debug</button><!-- Excludes the toolbar and every control inside it --><div data-cy-ui-interactive=\"exclude-all\">  <button>Reset state</button>  <button>Seed data</button></div>\n```\n\nPrefer `elementFilters` when you want to manage exclusions centrally in Cypress Cloud without changing application code, or when the team that manages configuration isn't the team that owns the markup.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-2-add-an-elementfilters-rule"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 1103
    },
    {
      "id": "ui-coverage/guides/ignore-elements#exclude-everything-inside-an-iframe-or-shadow-dom",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Exclude everything inside an iframe or shadow DOM",
      "heading_level": 3,
      "content_markdown": "### Exclude everything inside an iframe or shadow DOM\n\nThird-party embeds often render inside an iframe or shadow DOM. Pair a wildcard selector with `documentScope` to remove the entire embed at once. The `documentScope` selector matches the iframe or shadow-DOM host in its parent document:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"*\",      \"include\": false,      \"documentScope\": [\"iframe[title='Secure payment']\"],      \"comment\": \"Embedded third-party payment form\"    }  ]}\n```\n\nFor content nested more than one level deep, list one selector per host from outermost to innermost. See the [`documentScope` reference](/llm/markdown/ui-coverage/configuration/elementfilters.md#Options) for details.\n",
      "section": "ui-coverage",
      "anchors": [
        "exclude-everything-inside-an-iframe-or-shadow-dom"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 121
    },
    {
      "id": "ui-coverage/guides/ignore-elements#keep-specific-elements-out-of-a-broad-exclusion",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Keep specific elements out of a broad exclusion",
      "heading_level": 3,
      "content_markdown": "### Keep specific elements out of a broad exclusion\n\nBecause the first matching rule wins, an `include: true` rule placed _before_ a broader exclude rule protects the elements it matches. This is useful when a third-party container also holds elements you _do_ want to test, such as your own navigation links inside a vendor toolbar:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"nav a\",      \"include\": true,      \"comment\": \"Keep our nav links despite the vendor exclusion below\"    },    {      \"selector\": \"[data-vendor] a\",      \"include\": false,      \"comment\": \"Ignore links rendered by the vendor toolbar\"    }  ]}\n```\n\nOn its own, an `include: true` rule changes nothing, since everything is included by default. It only matters as an exception ordered ahead of an exclude rule. For the full evaluation model, see [How are elementFilters rules applied?](/llm/markdown/ui-coverage/configuration/elementfilters.md#How-are-elementFilters-rules-applied).\n\nSetting `elementFilters` at the root of your configuration affects both UI Coverage and Cypress Accessibility. To exclude elements for UI Coverage only, nest the property under a `uiCoverage` key. Note that `include: true` exceptions have no effect in Cypress Accessibility. See [Scope](/llm/markdown/ui-coverage/configuration/elementfilters.md#Scope).\n",
      "section": "ui-coverage",
      "anchors": [
        "keep-specific-elements-out-of-a-broad-exclusion"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 235
    },
    {
      "id": "ui-coverage/guides/ignore-elements#exclude-an-area-for-your-teams-runs-only",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Exclude an area for your team's runs only",
      "heading_level": 3,
      "content_markdown": "### Exclude an area for your team's runs only\n\nA root-level rule changes the report for _everyone_. When several teams share one Cypress Cloud project, that's often too broad: an area that's noise for your team may be exactly what another team is responsible for testing. Excluding it at the root would erase it from the other team's report too.\n\nUse a [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md) override to scope the exclusion to your own runs. A profile applies its `config` only to runs recorded with a matching [`--tag`](/llm/markdown/app/references/command-line.md#cypress-run-tag-lt-tag-gt), so your team tags its runs and gets a report that drops what it doesn't own, while every other team's runs keep the base configuration.\n\nFor example, the Account team doesn't own the support-chat widget, so its runs exclude it, but the Support team's runs (and the default report) still count it:\n\nApp Quality Config\n\n```\n{  \"elementFilters\": [    {      \"selector\": \"#analytics-overlay, #analytics-overlay *\",      \"include\": false,      \"comment\": \"Analytics overlay, noise for every team\"    }  ],  \"profiles\": [    {      \"name\": \"aq-config-team-account\",      \"config\": {        \"elementFilters\": [          {            \"selector\": \"#analytics-overlay, #analytics-overlay *\",            \"include\": false,            \"comment\": \"Repeat base rules — a profile replaces the base list, it doesn't merge\"          },          {            \"selector\": \"#support-chat-widget, #support-chat-widget *\",            \"include\": false,            \"comment\": \"Account team doesn't own support chat, so it isn't a gap for us\"          }        ]      }    }  ]}\n```\n\nThe Account team records with the matching tag, and only those runs pick up the extra exclusion:\n\n```\ncypress run --record --tag \"aq-config-team-account\"\n```\n\nA profile's `elementFilters` **replaces** the base list rather than merging with it, so repeat every base rule the tagged run still needs, as the example does for the analytics overlay. See [`profiles`](/llm/markdown/ui-coverage/configuration/profiles.md) for merge behavior and how a tag selects a profile.\n",
      "section": "ui-coverage",
      "anchors": [
        "exclude-an-area-for-your-teams-runs-only"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 379
    },
    {
      "id": "ui-coverage/guides/ignore-elements#exclude-elements-from-your-markup-instead",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Exclude elements from your markup instead",
      "heading_level": 3,
      "content_markdown": "### Exclude elements from your markup instead\n\nWhen the team that owns the markup also owns the decision to exclude an element, you can do it in application code instead of Cloud configuration. Add [`data-cy-ui-interactive=\"exclude\"`](/llm/markdown/ui-coverage/core-concepts/interactivity.md#Overriding-interactive-elements-with-data-cy-ui-interactive) to a single element, or `data-cy-ui-interactive=\"exclude-all\"` to a container to also exclude everything inside it:\n\n```\n<!-- Excludes just this button --><button data-cy-ui-interactive=\"exclude\">Debug</button><!-- Excludes the toolbar and every control inside it --><div data-cy-ui-interactive=\"exclude-all\">  <button>Reset state</button>  <button>Seed data</button></div>\n```\n\nPrefer `elementFilters` when you want to manage exclusions centrally in Cypress Cloud without changing application code, or when the team that manages configuration isn't the team that owns the markup.\n",
      "section": "ui-coverage",
      "anchors": [
        "exclude-elements-from-your-markup-instead"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 137
    },
    {
      "id": "ui-coverage/guides/ignore-elements#step-3-validate-the-result",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "Step 3: Validate the result",
      "heading_level": 2,
      "content_markdown": "## Step 3: Validate the result\n\nAfter saving, you don't need to rerun your tests. Open a recent run, go to its **Properties** tab, and use the **regenerate** button to reprocess it with your new configuration. In the regenerated report, confirm that:\n\n*   The excluded elements no longer appear in the **Untested elements** list.\n*   Your coverage score reflects only the elements you intend to test.\n\nIf an element you excluded still appears, see [Why isn't my elementFilters rule excluding an element?](/llm/markdown/ui-coverage/faq.md#Why-isnt-my-UI-Coverage-elementFilters-rule-excluding-an-element). As your application grows, new third-party or out-of-scope elements may show up; update your filters when they do to keep reports actionable.\n",
      "section": "ui-coverage",
      "anchors": [
        "step-3-validate-the-result"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 139
    },
    {
      "id": "ui-coverage/guides/ignore-elements#see-also",
      "doc_id": "ui-coverage/guides/ignore-elements",
      "heading": "See also",
      "heading_level": 2,
      "content_markdown": "## See also\n\n*   [`elementFilters` configuration](/llm/markdown/ui-coverage/configuration/elementfilters.md): the full reference for options, rule ordering, and validation.\n*   [Ignore views and links](/llm/markdown/ui-coverage/guides/ignore-views-and-links.md): exclude entire pages, and the links pointing to them, with [`viewFilters`](/llm/markdown/ui-coverage/configuration/viewfilters.md).\n*   [Reduce noise](/llm/markdown/ui-coverage/guides/reduce-noise.md): consolidate repeated elements and stabilize dynamic identities instead of removing them.\n*   [`profiles` configuration](/llm/markdown/ui-coverage/configuration/profiles.md): apply a different set of exclusions per run tag, so shared projects can report per team.\n*   [Identify coverage gaps](/llm/markdown/ui-coverage/guides/identify-coverage-gaps.md): find the real gaps that remain once the noise is gone.\n*   [Interactivity](/llm/markdown/ui-coverage/core-concepts/interactivity.md): which elements UI Coverage tracks, and the `data-cy-ui-interactive` markup attribute.\n*   [Configuration overview](/llm/markdown/ui-coverage/configuration/overview.md): where to set configuration and how to regenerate reports.\n*   [UI Coverage FAQ](/llm/markdown/ui-coverage/faq.md): common questions about excluding elements and scores.\n",
      "section": "ui-coverage",
      "anchors": [
        "see-also"
      ],
      "path": "/llm/json/chunked/ui-coverage/guides/ignore-elements.json",
      "token_estimate": 152
    }
  ]
}