Web Page Verification with Playwright: Structural Checks, Browser Tests, and Human Review
What you’ll learn
- How file structure and URL validation differ from browser verification with Playwright
- How Playwright checks rendering, interaction, and layouts at smartphone widths
- How to fit browser checks into an existing validation flow, and which decisions need human review
A web page updated by AI can have valid files yet show a broken layout or links that do not work as expected in a browser. Checking an update requires inspecting the file structure, then checking the actual screen and interactions.
Playwright automates browser actions to check how pages render and behave. However, it cannot decide whether an article is accurate or ready to publish. Separating file structure checks, browser verification, and human review makes each stage’s responsibilities clear.
This article uses this site’s validation flow to explain where Playwright fits, what it checks, and which items require human judgment.
Playwright’s role on this site
On this site, Markdown (a document format that uses symbols to mark headings and links) and configuration files are checked first to reduce problems that can be detected mechanically. Playwright then checks issues that only become apparent when a page is displayed in a browser.
Playwright Test is a framework for running E2E tests (tests that follow a sequence of user actions) for web applications. It can test Chromium, WebKit, and Firefox locally or in CI (a system that automatically runs tests and validation, for example through GitHub Actions).[1]
However, this site does not currently have Playwright installed as a permanent E2E testing foundation. For now, it serves as a way to verify pages in a browser between existing validation scripts and human visual review.
The sequence is to check file structure, links, and configuration; verify rendering and interaction in a browser; then have a person review the content and decide whether to publish. Each stage uses an appropriate method rather than assigning every check to browser tests.
Structure, link, and configuration checks before browser verification
Before opening a browser, checks cover items that can be assessed in the repository (the place where article and configuration files are managed). The main targets are:
- Markdown structure
- Correspondence between citation numbers in the text and references
- Reference URL and internal link formats
- Structural differences between Japanese and English articles
- Consistency between the harness (the rules, work procedures, and validation methods provided to AI) and agent configuration
This site uses the following commands. All are validation commands defined in this project.
| Command | Main checks |
|---|---|
npm run review:content | Citations and references in article text |
npm run review:references:live | Accesses external URLs to check for broken or unreachable links |
npm run harness:check | Checks shared rules, runtime adapters (configuration and processing that apply shared rules to each runtime), structural differences between Japanese and English articles, and related items |
Mismatched citation numbers, references that are not links, or an article mentioning an npm script (a command defined in the project) that does not exist can be detected without a browser. Resolving these issues first lets browser verification focus on rendering and interaction.
Rendering, interaction, and changes at different screen widths
Playwright checks the state of a page after it is displayed, which cannot be determined from source files alone. On this site, the targets include:
- Whether the home page, blog articles, and documentation articles can be displayed
- Whether internal links on Japanese and English pages navigate to the expected pages
- Whether navigation and body layouts remain intact at smartphone widths
- Whether references appear as clickable links on the page
- Whether Starlight sidebars, breadcrumbs, and heading links appear as intended
- Whether errors appear in the browser console (where processing messages and errors can be inspected)
This site uses Astro (a framework for building websites) and Starlight (a documentation site theme for Astro). The screen reflects their page generation, theme settings, and the results of generation scripts. How the hosting environment handles URLs can also affect link behavior.
As a result, rendering or interaction problems can occur even when no issues are found in the files. Responsive behavior, where the display changes with screen width, including smartphone widths, also needs browser verification.
Choosing between regular Playwright tests and Playwright MCP
Playwright can be used by writing and running test code, or by letting an AI agent operate a browser through Playwright MCP.
Playwright MCP provides Playwright’s browser automation capabilities as an MCP server (MCP is a common protocol for connecting AI to external tools). An LLM (large language model) can read accessibility snapshots (structured information about page elements and their names) and use element references to click, enter text, and check state.[2]
On this site, the methods have the following roles.
| Verification method | Suitable uses |
|---|---|
| Regular Playwright tests | Repeatable rendering and link checks, and regression tests that check whether changes have broken previous behavior |
| Playwright MCP | Having Codex or Claude open local pages and inspect their state |
| Human visual review | Checks requiring human judgment, such as awkward design or readability |
Playwright MCP is an option for looking for problems while interacting with the screen. Recurring issues can then be checked every time through regular Playwright tests or existing validation scripts.
Fitting browser checks into the existing validation flow
When using Playwright on this site, browser verification follows structure and URL validation and precedes a person’s publication decision.
First, validate items that can be assessed in the repository and check external URL reachability.
npm run harness:check
npm run review:references:liveNext, start the local preview.
npm run devWith the preview running, open representative pages through Playwright or Playwright MCP. It is more realistic to prioritize pages where problems would have a large impact than to cover every page from the start. Candidates on this site include:
- Japanese and English home pages:
/ja/,/en/ - Japanese and English blog listings:
/ja/blog/,/en/blog/ - New or updated blog articles
- Documentation articles whose structure has recently changed
Another option is to select one important screen and reproduce its rendering, interactions, and state at smartphone widths. Resolving issues found by lightweight checks first keeps browser verification focused on problems that only become apparent after rendering.
Content, sensitive information, and publication decisions requiring human review
Playwright is useful for checking whether elements appear, links can be clicked, and console errors occur. It cannot determine whether an article’s claims are correctly supported by its references.
For example, a reference link may be clickable and return a normal HTTP status (a code indicating the communication result), yet the page may not support the claim in the article. Link usability and citation appropriateness are separate checks.
Neither npm run review:content nor npm run review:references:live completes this verification on its own. A person ultimately needs to compare the text with its references. On this site, responsibilities are divided by target as follows.
| Check target | Main owner or method |
|---|---|
| Markdown structure, citation numbers, reference format | Validation scripts |
| External URL reachability | npm run review:references:live |
| Rendering, link clicks, state at smartphone widths, console errors | Playwright or Playwright MCP |
| Correspondence between claims and references, appropriateness of the prose | Human review |
Along with content accuracy, browser actions alone cannot decide how sensitive information should be handled or whether publication is appropriate. These remain items for human review.
Summary: Dividing Structural Checks, Browser Verification, and Human Review
On this site, structure, links, and configuration are validated first, then Playwright checks actual rendering and interaction. When AI updates articles or configuration, file correctness and the page’s rendering and behavior need to be verified separately.
Regular Playwright tests cover checks repeated under the same conditions; Playwright MCP supports investigation through screen interaction; and human review handles content validity and publication decisions. Combining these methods according to what each can check makes it possible to assess quality, including judgments that browser tests alone cannot provide.
References
- Microsoft, Installation | Playwright, Playwright Docs
- Microsoft, Playwright MCP