On this page
An assistant can help organize a website audit when it can inspect the right evidence and explain what that evidence does not show. Prerender Buddy MCP combines public HTTP checks with optional, scoped reads of saved workspace information. That lets an agency start with a public page, add relevant account context when authorized, and produce a focused action list.
The local package checks HTTP responses. It does not launch a browser to render JavaScript, and the workspace tools do not perform repairs. Keep those boundaries visible in the audit.
Prepare an approved public URL
Choose a page the client has approved for inspection: for example, a public product page, a pricing explanation or an important documentation page. Use the final intended hostname and path. Do not paste credentials, signed private URLs or a customer-only route into the audit prompt.
This worked workflow uses https://client.example/product as a placeholder. Replace it with the client's approved public URL. No checks or results for that example domain are being claimed here.
Connect the local tool
The published package reviewed for this guide is @prerenderbuddy/mcp version 0.2.0, which requires Node.js 20 or later. In a compatible local MCP client, configure a stdio server that launches:
npx --yes @prerenderbuddy/mcp@0.2.0Use the client's actual MCP configuration instructions for the command and arguments. The server runs locally. This command does not establish that every assistant application supports local stdio servers or that a plugin is available in every marketplace.
Start with the public checks. Optional workspace evidence requires an eligible account and an appropriately scoped PB API key supplied through PRERENDER_BUDDY_API_KEY in the local server environment. Use only the scopes required for the audit, and keep the key out of prompts, screenshots and the client report.
The developer tools overview explains the public and workspace evidence paths and distinguishes MCP from the separate plugin packaging.
First pass: inspect the public response
Give the assistant a bounded request:
Inspect this approved public URL with the Prerender Buddy public HTTP tools:
https://client.example/product
Report the response evidence and available crawler-readability signals.
Distinguish an observed problem from an unavailable check. Do not describe
the result as browser-rendered, and do not make changes.Review the final URL, response status and the content evidence actually returned. A successful status does not by itself establish that the product content is present. Conversely, thin initial HTML suggests a question to investigate; it does not establish how every search engine eventually processes the page.
If the result depends on client-side rendering, add a separate browser or rendered-response comparison using an appropriate tool and authorized workflow. Label the two observations by method and time so they can be compared without confusing an HTTP fetch with a rendered result.
Second pass: add saved workspace evidence
If the client site belongs to your authorized workspace, ask the assistant to identify the correct site before reading its records. Depending on the key's scopes, it can retrieve bounded site, Health, crawler-activity, visibility, recommendation and content metadata.
For the matching authorized site, read the available Health and recent
crawler-activity summaries. Include their timestamps and scope. If visibility
or recommendation evidence is available with this key, use it to prioritize
questions for review. Say which evidence is missing or inaccessible.
Do not treat saved evidence as a new scan.The workspace read tools do not return every underlying artifact. Do not expect full provider-answer bodies, full Health HTML or saved article bodies from endpoints that expose summaries and metadata. Open the appropriate product view when a judgment requires the full record.
A permission error means the requested evidence was not accessible through that request. It is not a clean bill of health and not an instruction to bypass the account boundary.
Turn the evidence into a short action list
Ask for one row per actual issue, with the URL, observed evidence, observation date, uncertainty, recommended next check and owner. Rank problems by the importance of the affected page and the strength of the evidence.
| If the evidence shows… | A reasonable next action | Verification needed |
|---|---|---|
| The public response lacks expected product content | Compare raw and rendered responses and inspect delivery configuration | Confirm the same public route contains the expected content after any repair |
| A saved finding predates a deployment | Obtain a new authorized check | Record the later result and what changed |
| Visibility evidence is missing or incomplete | Review collection setup and completion | Obtain usable answers before judging brand absence |
These rows are conditional examples, not findings about a real client.
Read-only evidence collection ends with a proposal. Implementing a fix, changing monitoring questions, clearing cache or publishing content requires a separate authorized workflow; those mutations are not current workspace MCP tools.
Use JavaScript SEO Audit for Agencies for the broader audit framework and Prerender Buddy developer tools for the public tool options. The assistant's useful output is an evidence-backed next step with clear limits.