End-to-End SEO Testing with Playwright and Lighthouse
Reading time: ~ 6 minutes
Automated testing is second nature for developers working on mature applications. It protects years of investment and helps teams move forward without breaking what already works. But visibility often lags behind code quality, especially in long-lived apps where SEO concerns quietly pile up over time.
Search engine optimization plays a critical role in whether those applications continue to earn traffic, trust, and users. The challenge is that SEO checks are often manual, inconsistent, or deferred until something breaks. This is where end-to-end testing can help teams build momentum instead of reacting to surprises.
In this article, we’ll explore how to use Playwright, Puppeteer, and Vitest to integrate SEO auditing into your test suite, making search engine optimization a seamless part of your development workflow.
What is SEO?
SEO, short for search engine optimization, is the practice of improving your website’s visibility in search engines. It helps search engines understand your content and ensures users can find your site, decide whether to visit and have a smooth experience once they do.
Headless Browsers
Headless browsers, browsers without a graphical user interface, are widely used in automation. Many, like Chrome’s headless mode, include built-in tools to assess SEO, accessibility, and performance.
Tools like Lighthouse help teams measure how real users and search engines experience a page today, not how it was intended to work when it was first built. That feedback is especially valuable for applications that have grown and changed over time, while providing automated reports on SEO issues and web performance metrics..
Choosing a Test Framework for SEO Audits
When adding SEO checks to an existing test suite, the goal is not experimentation. It's reliability. The right framework should reflect how users actually experience the application, integrate cleanly into CI workflows, and support the browsers your audience depends on.
In the software development world, we have a lot of test framework tools. In this article, we will discuss 2 of them: Vitest and Microsoft Playwright
Vitest
Vitest is a next-generation JavaScript testing framework powered by Vite. It’s an excellent alternative to Jest, offering native TypeScript support, a fast setup, and solid performance. However, while it has an experimental headless browser, it’s not ideal for advanced scenarios like running SEO audits in CI/CD pipelines. Instead, we can pair Vitest with Pupetter, a more mature tool for headless browser automation.
For teams working on established systems, this distinction matters because SEO regressions often surface only under real browser conditions, not simulated ones.
Playwright
Playwright is a robust framework built specifically for end-to-end testing. Unlike Vitest, It was designed to handle real browser interactions, making it ideal for SEO audits. It supports Chromium, WebKit, and Firefox, runs on Windows, macOS, and Linux, and can execute tests in both headless and headless modes. Playwright even includes native mobile emulation to test how pages render on mobile devices.
For long-lived applications, this level of realism helps teams test changes without fear. Playwright makes it possible to evolve SEO practices alongside the application itself, rather than bolting them on after issues appear.
Lighthouse: The SEO Testing Powerhouse
Lighthouse is an open-source, automated tool for improving the quality of web pages. It can be run on any public or authentication-requiring web page. It offers audits for performance, accessibility, progressive web apps, SEO, and more.
Using Lighthouse in your test suite means you can automate the process of checking for SEO issues as part of your development workflow.
This shift toward automated, behavior-driven checks echoes what Alan Ridlehoover emphasized on the Maintainable Podcast: building resilient systems means testing how software behaves in real conditions over time, not just validating assumptions at a single point.
When Lighthouse runs as part of your test suite, SEO becomes a routine signal instead of a last-minute audit. That consistency helps teams protect hard-won visibility as their application moves into its next phase.
Practical Example: Running an SEO Audit with Playwright
To put theory into practice, we’ll learn how to configure Playwright to perform automated SEO audits on a website. By the end, you'll see how easy it is to integrate SEO testing into your development workflow, catching issues before they impact your search rankings.
This example is especially useful for teams maintaining mature applications who want guardrails that catch regressions early without introducing large process overhead.
Requirements:
The Playwright config file
Playwright provides extensive options for customizing test execution. The configuration file allows us to set up test parallelization, specify the test directory, define a base URL for the page, use the page.goto(...) method, and configure multiple projects.
Playwright provides extensive configuration, allowing developers to customize test execution. The configuration file lets us:
✅ Set up test parallelization.
✅ Specify the test directory.
✅ Define a base URL for `page.goto(...).
✅ Configure multiple projects.
In the projects section, we can define which browsers to use, such as Chromium, Firefox, and Safari, and device-specific settings. This ensures that tests run with the correct configurations, whether we're testing desktop or mobile experiences.
📌 Example: Playwright Config File Setup
Writing SEO-Focused Tests with Playwright
Getting Started with Playwright
Creating tests in Playwright is straightforward—it’s similar to Jest. Simply create a .ts file in the tests folder, import test, and expect from @playwright/test. Playwright provides a page object that allows interaction with a webpage just like a real user.
📌 Example: Using the Page Object in Playwright
One of Playwright’s most powerful features is locators, which help us find elements, interact with them (click, type, etc.), and make assertions.
Common locator methods include:
page.getByRole(): Find elements by accessibility attributespage.getByText(): Locate elements by text contentpage.getByLabel(): Identify form inputs based on associated labelspage.getByPlaceholder(): Locate inputs using placeholder textpage.getByAltText(): Find images by alternative textpage.getByTestId(): Locate elements using a custom test attribute
Need finer control over which browser or rendering engine to use for specific tests? Playwright makes it easy. Simply import the required configurations from @playwright/test.
📌 Example: Running Tests on Specific Browsers
Writing SEO Tests in Playwright
Configuring a Base URL
To streamline navigation, we can define a Base URL in playwright.config.ts. This allows us to use relative paths instead of specifying complete URLs in every test.
📌 Example: Setting a Base URL in playwright.config.ts
SEO-Specific Tests
Let’s look at some essential SEO checks that can be automated with Playwright.
1️⃣ Page should have a favicon.
2️⃣ Robots.txt should be valid.
3️⃣ Sitemap should be valid.
Note: Some web servers might return a compressed gz file with `XML' (as the Planet Argon Website does), so we test both possibilities.
4️⃣ Page should have a valid meta description.
5️⃣ Page should have a valid title.
6️⃣ Page should have a valid viewport meta tag.
7️⃣ HTML tag should include a lang attribute.
Running Lighthouse Tests with Playwright
To integrate Lighthouse audits with Playwright, install playright-lighthouse.
Threshold tests
Lighthouse allows us to define thresholds for key performance categories:
✅ Performance
✅ Accessibility
✅ SEO
✅ PWA
✅ Best Practices
If we pass nothing in the config, all categories will be tested and all scores will be 100 (default value).
Before writing Lighthouse tests, we must adjust some configurations in the playwright.config.ts file and create a new Lighthouse-specific project.
This is necessary to ensure that Lighthouse tests run with a single worker (by setting the worker count to 1), which helps avoid potential concurrency issues. Additionally, we need to configure Playwright’s Chromium browser to launch with port 9222 open, allowing Lighthouse to communicate with it during audits.
Lighthouse Test: Accessibility & Performance
Accessibility score should be above 90 and Performance above 70.
Very good! All your tests passed!!
Final Thoughts
End-to-end SEO testing with Playwright and Lighthouse gives teams a way to care for the visibility of long-lived applications without starting over. By embedding SEO checks into everyday testing, teams can move forward with confidence, knowing that performance, accessibility, and discoverability evolve alongside the codebase.
This approach supports a healthier second act for mature software, where progress comes from steady improvements rather than reactive fixes.
References
1 - SEO Starter Guide
2 - Lighthouse Overview
3 - Vitest Guide
4 - Playwright Intro
5 - Abhinaba Ghosh/Playwright/Lighthouse
We Think You'll Also Enjoy Reading...
- "What is an Accessibility Audit, and Why Do You Need One?"
- "Deploying a Ruby on Rails app to DigitalOcean Using Kamal"
- "End-to-End Testing with Cypress: A Case Study"
FAQ's
Q: "Can Lighthouse detect all SEO issues?"
A: Lighthouse is a powerful tool, but it primarily focuses on technical SEO metrics. It may not catch content-related issues, keyword strategy gaps, or other aspects of on-page SEO, so it's best used alongside manual reviews and keyword tools.
Q: "How often should I run automated SEO tests?"
A: It depends on how often your website is updated. For active sites, weekly or bi-weekly automated SEO audits can help you catch issues early. For more static sites, a monthly check may suffice.
Q: "Will these tools improve my Google rankings directly?
A: Not directly. These tools help you identify and fix issues that might harm your rankings, but search engines consider many factors. Think of them as giving you a strong technical foundation for your broader SEO strategy.
Q: Is automated SEO testing useful for older applications?
A: Yes. In fact, it is often more valuable for long-lived systems, where small changes can have unexpected downstream effects. Automated checks help teams protect visibility while continuing to evolve the application.