Use case

Audit Gutenberg block usage before a WordPress redesign

A redesign is easier to plan when the block inventory and exact source list come before the new implementation. This use case helps WordPress developers, agencies, and site maintainers understand whether a proposed change affects a contained set of pages or a much broader slice of content.

When this matters #

This workflow matters when a block, pattern, or shared layout is about to change and the team needs clearer impact evidence first.

• A component redesign could change classes, spacing, markup, or presentation across existing content.
• An agency needs to estimate whether the redesign affects a small set of pages or many editorial surfaces.
• QA, release notes, or stakeholder review need a real impact list instead of a verbal assumption.
• A theme or block-library update could affect patterns, template parts, or navigation structures as well as normal posts and pages.

Why manual work is risky #

Manual redesign review usually breaks down once block usage spans multiple WordPress surfaces and repeated block variants.

• A block name alone does not tell you which design variant or content context is in scope.
• Manual page sampling can miss template parts, shared content, or lower-traffic sources that still inherit the change.
• Teams often underestimate how far a redesign reaches until QA finds the outliers after implementation.

How DXM Block Toolkit helps #

DXM Block Toolkit makes redesign impact review easier by grounding decisions in indexed usage instead of guesswork.

• Block inventory shows which Gutenberg blocks and variants are active before the redesign moves forward.
• View sources turns a broad count into exact posts, pages, patterns, template parts, and navigation records.
• Advanced filters help isolate one class token, anchor, attribute-backed variant, or wording pattern when only part of a block family is changing.
• Exports and source-backed lists make it easier to align developers, designers, QA, and stakeholders on what the redesign really touches.

Concise workflow #

A practical redesign audit workflow looks like this.

1. Run a fresh scan so the current block inventory reflects the site you are about to change.
2. Find the block, pattern, or shared structure that the redesign targets.
3. Review source totals, then open the exact source list to see where the current implementation appears.
4. Apply filters when only one class, layout variant, or copy pattern should stay in scope for review.
5. Export or share the source-backed impact list so implementation and QA can plan against the same evidence.

If you need the operational steps, continue with Blocks and Sources .

Related use cases #

Continue with a related workflow when redesign review turns into source discovery, shared-structure planning, or controlled replacement work.