---
title: "A Smoke-Test Checklist for Block-Based Pages"
date: 2026-04-23
author: "Imtiaz Rayhan"
featured_image: "https://wpblocksuite.com/wp-content/uploads/2026/08/featured-smoke-test-checklist-block-based-pages.png"
categories:
  - name: "Block Editor"
    url: "/blog/category/block-editor.md"
---

# A Smoke-Test Checklist for Block-Based Pages

A WordPress smoke test checks whether critical block-page journeys remain obviously usable.

Test editing, saving, rendering, navigation, forms, media, roles, and logs.

Stop the release when a critical result fails.

## What should a block-page smoke test include?

Open representative pages, edit one fixture, save, preview, and reopen it.

Exercise navigation, media, forms, [dynamic blocks](https://wpblocksuite.com/blog/static-vs-dynamic-wordpress-blocks/), and essential business actions.

Inspect browser, WordPress, and server evidence during each journey.

## Define a smoke test correctly

A smoke test is a fast release gate for major breakage.

It samples critical breadth without proving every detailed requirement.

Passing permits deeper testing or controlled release.

## Separate smoke testing from regression testing

Regression testing checks many known behaviours after change.

Smoke testing asks whether essential systems are broadly alive.

Do not claim complete coverage from a short gate.

## Define release-specific risk

List changed code, configuration, content, data, and infrastructure.

Identify critical workflows depending on those areas.

Add targeted checks without abandoning the stable core checklist.

## Write pass and fail criteria

Every check needs an observable expected result.

Name failures that stop release immediately.

Record who can accept lower-risk deviations.

## Assign one test owner

One owner coordinates execution, evidence, and final result.

Specialists can still run individual checks.

Shared responsibility without ownership creates skipped checks.

## Timebox the smoke test

A smoke test should remain fast enough for every release.

Move deep investigation outside the gate after recording failure.

Expand the permanent checklist only for recurring critical risks.

## Use a representative environment

Match important production software, configuration, data, and cache behaviour.

Document staging differences that weaken conclusions.

Run a smaller production verification after deployment.

## Test the exact release candidate

Record build identifiers, versions, migrations, and configuration.

Do not test one package and deploy another.

Verify deployed hashes when the process supports them.

## Prepare rollback before testing

Preserve current code, configuration, database, and required media.

Confirm the rollback owner and decision threshold.

A failed smoke test should trigger a known response.

## Capture the pre-change baseline

Run the checklist before deploying the release candidate.

Existing failures must not become release regressions accidentally.

Record baseline screenshots, timings, and logs where useful.

## Check the public home route

Load the homepage anonymously from a clean session.

Confirm expected status, content, navigation, media, and primary action.

Inspect console and network failures during loading.

## Check representative templates

Open one page for each critical template family.

Include singular, archive, search, and error routes where relevant.

Confirm headers, footers, sidebars, and content placement.

## Check response status and redirects

Pages can look correct after an unintended redirect.

Record final URL, status, and redirect chain.

Confirm canonical public routes remain stable.

## Check secure transport

Confirm valid certificates and expected secure redirects.

Inspect mixed-content and policy warnings.

Do not ignore failures hidden by a previously trusted session.

## Check WordPress administration login

Sign in using a dedicated test administrator.

Confirm redirects, security controls, dashboard loading, and logout.

Never use shared production credentials within automation.

## Open a representative block page

Choose a protected fixture with common and complex blocks.

Confirm the editor loads without blank or crashed states.

Inspect initial browser and server errors.

## Check block selection and List View

Select top-level and nested blocks using canvas and List View.

Confirm toolbars, settings, labels, and hierarchy remain available.

A rendered canvas alone does not prove editing works.

## Check the block inserter

Open the inserter and find representative core and plugin blocks.

Insert one disposable block into the fixture.

Confirm patterns and media tabs load where expected.

## Edit representative block settings

Change text, spacing, colour, alignment, and one structured setting.

Use settings actually supported by the fixture.

Confirm controls update the intended block only.

## Save and confirm the response

Save the controlled fixture and wait for completion.

Inspect failed REST, Ajax, or server requests.

Do not trust a visual button state alone.

## Close and reopen the editor

Reopening proves the change persisted beyond local editor state.

Confirm inserted content, settings, hierarchy, and validation.

Restore the fixture after recording results.

## Preview the saved change

Use the [WordPress preview workflow](https://wordpress.org/documentation/article/how-to-use-the-preview-function/) in a new tab.

Confirm the frontend template and public assets render.

Compare the exact saved revision.

## Check for block validation warnings

No new invalid-content warning should appear after reopening.

Preserve original source before attempting recovery.

A smoke test records the failure without destructive repair.

## Check shared patterns

Open one page using each critical synced pattern.

Confirm source changes propagate only where intended.

Restore the pattern through a controlled fixture.

## Check templates and template parts

Verify headers, footers, navigation, and critical page templates.

Check both editor access and public rendering.

Shared structure can affect many routes simultaneously.

## Check primary navigation

Open desktop and mobile navigation using keyboard and pointer.

Follow primary links and confirm current-page state.

Close menus and restore focus correctly.

## Check critical internal links

Follow calls to action, breadcrumbs, anchors, and related content.

Confirm intended destinations and fragment positions.

A link can look correct while targeting staging.

## Check images

Confirm representative images load without distortion or layout shifts.

Inspect alternatives, captions, links, and responsive sources.

Upload one disposable image when media changed.

## Check video and embeds

Start playback, use controls, enable captions, and enter fullscreen.

Test consent refusal and blocked provider states.

Essential content should remain understandable when providers fail.

## Check responsive layout

Inspect narrow, medium, and wide frontend widths.

Check order, wrapping, overlap, clipping, and horizontal scrolling.

Use real devices when the release affects mobile interaction.

## Check one secondary browser engine

Run critical public journeys outside the primary browser engine.

Choose coverage from the site’s support matrix.

Expand testing when browser-facing assets changed.

## Check keyboard operation

Navigate menus, links, forms, dialogs, and disclosures without a pointer.

Focus must remain visible and logically ordered.

Escape and close actions should return focus appropriately.

## Check heading and landmark structure

Inspect the [document outline](https://wpblocksuite.com/blog/wordpress-document-outline-fix-headings/) on representative templates.

Confirm main content and navigation landmarks remain meaningful.

Smoke testing does not replace a complete accessibility audit.

## Check site search

Search for a known result and an absent result.

Confirm forms, results, pagination, and empty messaging.

Check query parameters and canonical output.

## Check forms end to end

Submit invalid and valid controlled data.

Confirm labels, errors, consent, delivery, storage, and success.

Delete test submissions after preserving required evidence.

## Check comments when enabled

Submit a controlled comment through the public form.

Confirm moderation, notification capture, display, and deletion.

Skip this check when comments are intentionally unavailable.

## Check authentication journeys

Test login, logout, password reset, and protected content where relevant.

Use controlled accounts and captured mail.

Confirm role-specific navigation and permissions.

## Check commerce journeys when present

Add a known product, update quantity, and reach test checkout.

Use official sandbox payments and artificial customer data.

Confirm totals, inventory rules, notices, and order creation.

## Check dynamic and query blocks

Verify expected records, filters, pagination, and empty states.

Test logged-in and anonymous output when data differs.

Confirm server rendering completes without hidden warnings.

## Check REST and Ajax requests

Watch requests generated by editing and public interactions.

Record unexpected status, redirects, timeouts, and malformed responses.

One failed shared request can affect several blocks.

## Check scheduled work

Run one representative safe scheduled task when relevant.

Confirm queue processing, logs, and expected state change.

Use staging sinks for external side effects.

## Check outgoing messages safely

Trigger one representative email or webhook into test capture.

Confirm destination, payload, formatting, and retry behaviour.

Never send smoke-test messages to real customers.

## Check caches after change

Verify fresh and returning anonymous page responses.

Inspect page, object, browser, proxy, and CDN layers.

Confirm invalidation reaches changed routes.

## Check the browser console

Record new errors, failed promises, and security policy violations.

Fix the first relevant failure before chasing later symptoms.

Known baseline noise should remain documented and owned.

## Check server and WordPress logs

The [WordPress debugging guide](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/) covers staging error logging.

Inspect relevant timestamps during each smoke journey.

Hide sensitive diagnostics from public visitors.

## Check Site Health changes

[Site Health](https://wordpress.org/documentation/article/site-health-screen/) reports critical issues and detailed environment information.

Compare relevant status and configuration against baseline.

Do not treat a green screen as application proof.

## Check performance sanity

Notice catastrophic loading, interaction, or server response regressions.

Compare a small stable set against the baseline.

Use dedicated measurement before claiming precise performance changes.

## Check essential search metadata

Inspect title, description, canonical, robots, and structured output.

Confirm production URLs replace staging references.

Smoke testing does not replace a complete search audit.

## Check intended user roles

Repeat editing and public checks with representative roles.

Confirm permissions, controls, sanitisation, and private content boundaries.

Administrator success cannot prove author success.

## Check multilingual routes

Open one representative page within each critical language.

Confirm navigation, direction, translations, and alternate links.

Use long content to expose layout failures.

## Check multisite scope

Network changes can affect subsites differently.

Test representative themes, configurations, roles, and domains.

Record whether failures are network-wide or local.

## Automate stable smoke checks

Automation makes critical checks repeatable on every release.

The [WordPress end-to-end guidance](https://developer.wordpress.org/block-editor/contributors/code/testing-overview/e2e/) uses explicit assertions and browser projects.

Automate login, editing, rendering, navigation, and form outcomes.

## Keep manual smoke checks

Humans notice novel visual and interaction failures.

Manual checks cover areas too unstable for useful automation.

Record evidence with the same pass criteria.

## Stop when a critical check fails

Do not continue deployment while accumulating unrelated failures.

Preserve logs, screenshots, state, and the failing build.

Rollback or hold according to the release plan.

## Classify noncritical failures

Record severity, reach, workaround, owner, and deadline.

Only authorised owners should accept release risk.

Do not silently mark failing checks as passed.

## Attach evidence to the release

Record environment, build, tester, time, results, and deviations.

Link screenshots, logs, automated runs, and approved waivers.

Evidence makes later incident diagnosis faster.

## Run a production verification

Repeat safe critical checks after production deployment.

Avoid test actions that contact customers or mutate real orders.

Watch errors, monitoring, queues, and response status.

## Review the checklist after incidents

Add checks only when they catch important repeatable failures.

Remove redundant checks that no longer reduce risk.

Keep the gate fast enough to run consistently.

## Check the not-found route

Request a controlled nonexistent URL through the public site.

Confirm correct status, navigation, messaging, and search.

A styled error page must still return failure status.

## Check one public API response

Choose an endpoint required by a critical block journey.

Confirm status, shape, permissions, and cache behaviour.

Do not expose private fields while testing.

## Check asset version changes

Verify changed scripts and styles use current versions.

Old cached files can break new markup.

Compare fresh and returning browser sessions.

## Know the honest weak case

A tiny text correction does not require every commerce test.

Use the stable core plus checks matching the change.

Never skip backup or rollback thinking for consequential releases.

## Use the block-page smoke-test checklist

1. Record the release candidate.
2. Confirm backup and rollback ownership.
3. Compare the pre-change baseline.
4. Open the anonymous homepage.
5. Check representative templates.
6. Verify status and redirects.
7. Log into WordPress administration.
8. Open a protected block fixture.
9. Select and insert blocks.
10. Edit representative settings.
11. Save, close, and reopen.
12. Preview the saved frontend.
13. Check navigation and critical links.
14. Check images, video, and embeds.
15. Inspect responsive layouts.
16. Complete forms and business journeys.
17. Check dynamic blocks and search.
18. Test intended user roles.
19. Inspect console and network failures.
20. Inspect WordPress and server logs.
21. Compare relevant Site Health results.
22. Record every pass and failure.
23. Stop on critical failure.
24. Verify safely after production deployment.

## Frequently asked questions

What is a WordPress smoke test?



 

It is a fast release gate checking essential site journeys.



 

Does a smoke test replace regression testing?



 

No. It checks critical breadth without proving every detailed behaviour.



 

Should smoke testing include the block editor?



 

Yes. Test loading, editing, saving, reopening, and frontend preview.



 

When should a release stop?



 

Stop when a predefined critical check fails or rollback triggers activate.



 

Can smoke tests be automated?



 

Yes. Automate stable assertions while retaining focused manual review.



 



## The verdict

Verdict

**Keep it fast:** check critical editing and public journeys every release. **Keep it honest:** stop on critical failure and never claim complete regression coverage.

Dependable blocks should pass release gates. [Compare the $299 lifetime suite](https://wpblocksuite.com/#pricing) after smoke-testing real workflows.