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, and navigations.

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 audit 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 Audit #

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 filters when you need to isolate one class, anchor, ID, or attribute-backed variant.
6. Export the filtered result when another team needs evidence for remediation, QA, or handoff.

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 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 rather than only the block name.
• Export filtered source rows when QA, delivery, or another team needs exact locations instead of a verbal estimate.

Where to go next #