How to Find Where a Block Is Used in WordPress Gutenberg

If you need to find where a block is used in WordPress Gutenberg, start by deciding whether a quick one-off check is enough or whether you need indexed evidence across posts, pages, patterns, template parts, navigations, or one specific copy variant or similar content pattern inside a repeated block type.

Why this becomes hard at scale #

Native WordPress editing flows are built for changing one source at a time. They are not designed to answer site-wide impact questions quickly.

• Block usage is often spread across posts, pages, reusable content, template parts, and navigation structures.
• The same block name can appear in many contexts, making manual review noisy before cleanup or redesign work starts.
• Without a shared inventory, teams usually end up guessing scope or repeating the same verification work.

Manual options inside WordPress #

For a very small site or a one-off question, a manual check can be enough before you introduce a dedicated indexed workflow.

• Open a known page or post and inspect the block structure if you only need to confirm one source.
• Use targeted admin searches when you already know the likely post type or editorial surface.
• Ask a developer for a content-level query or export when the question is rare and the site surface is still small.

Recommended workflow in DXM Block Toolkit #

For recurring cleanup, redesign, migration, or QA work, the scalable path is to move from block-level inventory into exact source evidence.

1. Run a full scan so the index baseline is current enough to trust.
2. Open block inventory and find the target block name, such as core/button or a custom block slug.
3. Review instance counts and source counts to understand broad usage before you touch content.
4. Open View sources to inspect the exact indexed pages, posts, templates, or other source records behind that block.
5. Apply advanced source or block-content filters when you need to isolate one class, anchor, ID, attribute-backed variant, or text fragment.
6. Export the filtered result or move into Refactor when another team needs evidence for remediation, QA, or replacement work.

For the deeper inventory and source context, continue with Blocks & Sources .

When source-level filters and exports matter #

Once a block name alone is not specific enough, source-level filtering by attributes or block content and exports become the difference between a guess and an actionable worklist.

• Use class, ID, or anchor filters when the same block type powers multiple design variants.
• Use attribute path/value filters when a cleanup depends on a specific scalar attribute, not just the block name.
• Use block-content filters when the same block type contains multiple copy variants or similar content patterns and only one should stay in scope for review, updating, or replacement.
• Export filtered source rows when QA, delivery, or another team needs exact locations instead of a verbal estimate.

Where to go next #