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. DXM Block Toolkit Lite covers that complete discovery workflow.

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.

When simple block finders stop being enough#

A simple block finder can help when one block name and one quick scan are enough. The harder cases begin when the team needs a reusable inventory, filtered source evidence, and a clean path from discovery into review or follow-up work.

• A lightweight finder is fine when you only need a temporary list of sources for one obvious block name.
• It becomes limiting when the same question keeps coming back and the team needs a current inventory instead of rerunning one-off scans.
• It becomes limiting when patterns, template parts, navigation, and filtered block variants all need to be reviewed in the same evidence trail.
• It becomes limiting when discovery needs to hand off cleanly into exports, QA, or a later Refactor batch.

If the real question is when a lightweight finder is still enough and when you should move into indexed evidence with a reviewable scope, continue with the guide on search-replace limits.

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 Lite source filters when you need to isolate one class, anchor, ID, or attribute-backed variant.
6. Use the exact source list as the review evidence; add Pro later only if the workflow needs content matching, export, or Refactor.

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

When Lite source-level filters matter#

Once a block name alone is not specific enough, Lite source-level metadata and attribute filters turn the broad inventory into an actionable review list.

• 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 compact attribute queries when a known path and value are faster to express directly.
• Add Pro only when the work specifically needs normalized content matching or an exported worklist.

Where to go next#