Agency workflow: one report per client, every month

An agency with 20 clients does not need 20 dashboards. It needs the same measurement of the same pages every month, a place where the links live, and a short note per client that says what changed and what is next. getReport has no accounts, so the workflow is a spreadsheet plus permanent report links, and the exports do the rest: a PDF for the client folder, Markdown or CSV for the developer's board. This guide sets that up once and shows what the monthly pass looks like afterwards. Setup takes an hour; the monthly pass is about 15 minutes per client.

Quick answer

• One row per client per month in a shared sheet: date, three report links (home page, top landing page, one template page), the overall and Speed scores, what shipped, what is next.
• Run the same three pages on mobile every month. Reports are permanent for 12 months, so last month's link is the baseline.
• PDF from the report header goes into the client folder; the fixes view (report link plus /fixes) gives Copy as Markdown and a Trello / Jira CSV for the developer.
• The history strip on each report and the Core Web Vitals history tool show the trend; the monthly note quotes three numbers, two fixes shipped, one next step.
• Limits: 10 fresh reports per 10 minutes and 50 a day per connection, 5 per hour per client site. Opening an existing link never counts. The keyed API is announced on the API page but not live yet.
• The score is a health index, not a KPI. Report movement in findings, not the number.

Why one report per client per month

Client reporting fails in two ways. The first is too much: a 40-page export of every metric a tool can produce, which nobody reads and which hides the one thing that changed. The second is too little: a score in an email, which invites the question "why is it not 100?" and nothing else.

A fixed monthly report on fixed pages solves both. Because the pages and the device are the same every month, any change in the numbers is real and has a cause. Because the report is one link, the client can open it, the developer can open it, and you can open it in six months when someone asks what the site looked like before the relaunch. And because every finding carries its own plain-language explanation and fix, the report does the explaining that would otherwise be a paragraph in your note.

How getReport checks it

Every tool page runs the same full report and opens it at one module; the SEO audit and the speed test are the two most agencies start from, and both give the same seven-module report. The part of it built for hand-over is the fixes view, at the report address plus /fixes:

Four findings that anchor a typical monthly note, one per kind of conversation:

The Speed score is Lighthouse's own number, unchanged, so a client who also runs PageSpeed Insights sees the same thing. It moves a few points between runs on its own; quote it, but explain change in terms of the findings under it.

LCP is the finding clients feel (it is the slow hero image), broken links are the one they can see for themselves, and HSTS stands for the group of security items that are invisible until something goes wrong: cheap to fix, and a good "we also closed this" line in a note.

Step by step

1. Build the sheet

One tab per client, or one tab with a client column. Columns:

Month | Page | Report link | Overall | Speed | SEO | Security | Top fix | Shipped | Next

Three rows per month, one per page. The first three columns are the record; the scores are copied from the score row for quick scanning; the last three are the note in short form. A shared sheet is enough because report links need no login: anyone with the link can open the report, and the reports carry noindex, so they do not turn up in search.

2. Choose the three pages per client, once

• Home page: the page most often linked and most often tested by the client themselves.
• Top landing page: the page with the most organic entries in analytics, often a service or category page. This is where speed and SEO findings cost money.
• One template page: a product, an article, a location page; whatever the site has hundreds of. Findings here multiply across the site.

Write the three URLs into the sheet and do not change them. If the client relaunches, add a note and keep the old links; the before/after is the point.

3. The monthly pass, per client

1. Open last month's three links. On each, press Re-run (the same URL within 12 hours would otherwise return the stored report). Three fresh runs per client fit comfortably in the limits: 10 per 10 minutes and 50 a day per connection, and 5 fresh runs per hour per client site.
2. Read the history strip under the score row: the change since the previous report for Overall, Speed, SEO and Security, with a small trend line across every report of that domain.
3. Read Top fixes. A new entry at the top since last month is this month's story; an unchanged list means the backlog is the story.
4. Copy the new links and scores into the sheet.

For 20 clients that is 60 fresh runs, which is more than one connection's daily allowance of 50; spread the pass over two days or two people, or run the third page only every other month. When a limit is hit, the check page says so and how many minutes to wait. The API page announces a free keyed JSON API with its own quota; it is listed as coming in a later milestone, so plan around the web limits for now rather than an API key.

4. Export for the client and for the developer

Two audiences, two exports, both from the report:

• PDF (report header): the whole report with every finding expanded. File it under the client and month. It is the document to bring to a review meeting because it cannot change after the fact.
• Fixes view (report link plus /fixes, or the "Fixes for your developer" button): only the open findings, grouped by Small, Medium and Large effort, each with its module, severity, points and steps. Copy as Markdown pastes into a GitHub or GitLab issue, Notion or an email; Trello / Jira CSV downloads one row per fix with Title, Description, Priority, Labels, Effort, Points, Module, Check, Guide and Report columns; Open as GitHub issue starts an issue with the checklist filled in.

The Markdown starts with the report link, the page and the device, so a developer who was not in the meeting can reproduce what you saw. The hand-over itself is covered in send the fixes to your developer; the short version is: one batch of up to ten items, security first, then speed failures, then anything that blocks indexing, then the rest.

5. Write the monthly note

A format that clients read, because it is short and the same every month:

example.com – September

Numbers (home page, mobile): overall 82 (+6), speed 71 (+9), LCP 2.8 s (was 3.9 s)
Shipped: compressed the hero image and set it to load eagerly; added the
         Strict-Transport-Security header at Cloudflare
Next:    3 broken links on /resources (small); the pricing page loads a
         chat widget before anything else (medium) – proposal attached

Reports: home … | /pricing … | /blog/example …   (links open without login)

Three numbers, two fixes shipped, one next step, the links. The numbers come from the score row and the LCP finding; "shipped" comes from the fixes that moved from open to passed; "next" is the top of the fixes view. When you want a longer explanation of what a score is, explaining a getReport score to a client has the three-sentence template.

6. Show the trend, not the run

Two views beat any single number:

• The history strip on the newest report of each page: one trend line per score across every report of that domain, and the delta since last time.
• The Core Web Vitals history tool for the client's domain: up to 40 weekly points of real-user LCP, INP and CLS, which is the data Google ranks with. A line that moved into green three weeks after your fix is the clearest evidence of value an agency can show, and it costs nothing. Sites with little Chrome traffic have no data here; say so rather than substituting the lab number.

7. Have the score conversation once

The score is a health index built from checks with fixed weights; it is not a ranking prediction and it is not a comparison with competitors unless you run their pages too (you can, on the same three page types). Say that in the first month, in writing, and then report movement in findings: "the LCP finding passed", "two security headers added", "no broken links on the three pages". A client who chases 100 will spend your hours on the five-point items; a client who understands the index will fund the fixes that matter.

8. Offer the badge to clients who want it

At the bottom of every report, Show your score gives a badge in Markdown and HTML. It links back to the report, updates with each new report of the domain and is cached for 24 hours. Some clients like it in a footer or a status page; it is also a quiet reminder to re-run the report.

Platform notes

Clients on WordPress

The WordPress Doctor panel after Top fixes names the plugins, theme and page builder the page reveals and adds the plugin-level findings (abandoned or closed plugins, duplicate SEO or caching plugins, plugin weight). It is the fastest way to write the "next" line, and its "Send to my developer" link opens the same fixes view.

Clients on Shopify, Wix or Squarespace

Some findings cannot be fixed on a hosted platform: server headers, redirects at the server, some caching. Mark them "platform" in the sheet the first month so they do not come up again, and report the movement on what the platform does allow: images, apps, theme code, titles and descriptions, structured data. The platform guides say which is which: Shopify: what you can and cannot fix, Wix: speed and SEO limits, Squarespace: the checklist.

Clients with their own developer

Send the fixes view link rather than the export: it is always the current list for that report, and the developer can press Re-run themselves after the deploy and send the new link back. The report link in the sheet is then updated by them, not you.

Verify

• Every client tab has three links per month, and each link opens without login.
• On the newest report of each page, the history strip shows a delta against last month, and the fixes you marked "shipped" no longer appear in the fixes view.
• The monthly note fits on one screen and quotes the same three numbers every month.
• The PDF for the month is in the client folder before the review meeting.

Common mistakes

• Different pages each month. Pages differ more than months. Fix the three URLs per client and keep them.
• Desktop one month, mobile the next. The device is in the report header; use mobile, always.
• Sending the whole PDF to the developer. They need the fixes view: fewer items, with evidence and steps, in a format their board imports.
• Reporting a 3-point rise as a win. Lighthouse moves that much between runs. Report the finding that passed, and the CWV history when there is one.
• Running 20 clients from one connection in one sitting. The daily allowance is 50 fresh reports; the check page tells you when to come back. Spread the pass, or share it across the team.
• Promising 100. Some items are platform limits, and some are not worth the client's money. Promise the batch, and show it passed.