# Site QA console your web team runs before every launch

> Crawl the site, flag broken pages, missing titles and thin content, check speed and accessibility, then sign off page by page before the client sees it.

- Workflow type: app
- Services: Browserless, Google Drive, Slack Bot
- Categories: Engineering, Marketing
- Published: 2026-08-14

## What it does

- Crawls a site you point it at and builds one table of every page found, with its status code, title, description and word count
- Flags the problems worth catching before launch: broken pages, redirect chains, missing or duplicate titles, and pages that are too thin
- Checks your key template pages for speed, accessibility, best practices and SEO, and captures desktop and mobile screenshots into one gallery you can scan
- Gives every page a Pass, Needs work or Ignore mark that sticks between sessions, so two people can work the same launch checklist
- Exports the whole sweep as a report, files it into a client folder in Google Drive, and posts the summary and link to your team channel in Slack

## What you'll need

- A Browserless account for the crawling, page checks and screenshots. Full site crawling is a Cloud plan feature, and on other plans the app falls back to reading your sitemap or a list of addresses you paste in
- A Google Drive account where the client folder and finished reports get filed
- A Slack workspace and a channel for the team to get the summary
- The starting web address of the site you want to sweep

## Prompt

I want a site QA console my web team opens before we push a redesign or a batch of landing pages live. The point of it is to catch problems ourselves before the client does, so it has to work as a real launch checklist that two people can work through together, not a one shot report that gets read once and forgotten.

The app opens on a sweep setup screen. I enter a client name and a starting URL, then set the scope: keep the crawl to that one domain only, and set a maximum page count so a big site does not run away. On the same screen I set my own thresholds for what counts as a failing Lighthouse score in each category, and the word count below which a page counts as thin. Give these sensible defaults I can change. Starting a sweep calls Browserless Start Crawl with the domain restriction and page cap applied.

While the crawl runs, the app polls Browserless Get Crawl Status and Results and shows live progress: pages discovered, pages completed, and results paging in as they arrive rather than making me wait for the whole thing. The Browserless Crawl API is beta and Cloud plan only, so if a crawl cannot be started on my plan the app must degrade gracefully instead of dead ending. Fall back to Browserless Map Site URLs to discover pages from the sitemap and page links, and also let me paste a list of URLs in by hand. On that fallback path, gather each page's title, meta description and word count with Browserless Scrape Elements. Everything downstream in the app works identically no matter how the page list was built.

The main screen is a table of every discovered page showing its status code, title, meta description and word count. The app flags problems automatically: broken pages, redirect chains, missing titles, titles duplicated across more than one page, and thin content below my word count threshold. I can filter the table down to just the flagged rows, sort by problem type, and search by URL.

Each page can be tagged with a role: homepage, landing page, conversion page, article, or other. Roles are what keep the expensive checks affordable on a large site. Instead of auditing hundreds of pages, I pick one representative page per role and audit that one, and the app should nudge me toward that by showing which roles do not yet have an audited page.

From the table I select those key template pages and run Browserless Run Lighthouse Audit on them, showing performance, accessibility, best practices and SEO scores. Any score below the threshold I set is flagged clearly. Scores are stored against the page so they sit alongside its crawl data in the table rather than living in a separate report.

For the same selected pages the app captures Browserless Take Screenshot at a desktop width and a mobile width, and shows them in a single gallery so I can eyeball every layout in one pass instead of resizing a browser by hand. Clicking any shot opens it full size, and desktop and mobile for a page sit next to each other so a layout that breaks narrow is obvious.

Every page carries a review mark I set myself: Pass, Needs work, or Ignore. Marks persist between sessions and are shared across the team, so two of us can work the same sweep at once and see what the other has already cleared, including who set each mark and when. I can leave a short note on any page explaining what needs fixing. A counter at the top of the screen shows how many pages are still unreviewed, which is what makes this a checklist rather than a dashboard.

An Export button finishes the sweep. It renders the findings with Browserless Generate PDF, covering the flagged pages, the Lighthouse scores against my thresholds, the screenshots, and the review marks with their notes. The app then files that report into a per client folder in Google Drive using Create Folder, uploads it with Upload File (Multipart), produces a shareable link with Create Permission, and posts a short summary plus the link to our team channel with Slack Bot Send a Message. The Slack summary should lead with the numbers that matter: pages crawled, pages broken, pages below threshold, and pages still unreviewed.

Keep past sweeps per client so I can open the previous one before a launch and see what we flagged last time, and so the client folder in Drive builds up a history of reports rather than one file being overwritten each run.

## How to customize

- Set your own pass and fail scores for speed, accessibility, best practices and SEO, so the flags match the standard you hold your team to
- Change the page cap and the word count that counts as a thin page, and keep every sweep locked to a single domain
- Adjust the page roles you tag, so a large site only spends checks on one representative page per template
- Choose which Slack channel gets the summary and who the shared Drive link is opened up to

## FAQ

### Do I need a paid Browserless plan to crawl a whole site?

Full site crawling is a Cloud plan feature and still in beta at Browserless. The app is built to handle that: if a crawl is not available on your plan it falls back to discovering pages from the site's sitemap and links, and you can always paste in a list of addresses by hand. Every other part of the console works the same either way.

### Will this run away on a big site and cost a fortune?

No. Each sweep is locked to the one domain you start from and stops at a page cap you set, so it never wanders onto other sites or crawls forever. The heavier speed and accessibility checks only run on the handful of pages you pick, not on everything the crawl found.

### Can two of us work through the same checklist together?

Yes. That is the point of it. Every page carries a Pass, Needs work or Ignore mark that saves and stays put between sessions, and both of you see who marked what and when, so you can split a large launch list and not redo each other's work.

### Does it show me mobile layouts as well as desktop?

Yes. For every page you pick it captures a desktop and a mobile screenshot and puts them in one gallery, so you can scan every layout side by side instead of dragging a browser window narrower page after page.

### Does this cover keyword rankings and backlinks?

No, and that is deliberate. This console reports on what your pages actually do when they load: whether they work, what their titles and descriptions say, how fast and accessible they are, and how they look. Rankings and backlinks are a different job for a different tool.

Use this prompt in General Input: https://www.generalinput.com/prompts/site-qa-console-your-web-team-runs-before-every-launch