Send the fixes to your developer: a checklist they can actually use

You ran a report, the grade is a C, and someone else maintains the site. The fastest way to lose a week is to send them a screenshot of the score and "can you get this to 90?". This guide shows how to turn the same report into a checklist a developer can start on the same day: what the fixes view contains, how to export it into an issue or a board, the two sentences of context that save an hour of questions, and how to check the work when it comes back. Allow 15 minutes.

Quick answer

• Open the fixes view: the report address plus /fixes. On WordPress sites the WordPress Doctor panel links to it as "Send to my developer".
• Copy as Markdown and paste it into a GitHub or GitLab issue or an email. Trello / Jira CSV imports one card per fix.
• Add two sentences on top: what the site is for and what changed recently, plus the deadline.
• Agree the order: security failures, speed failures, anything that blocks indexing, then the rest. Send one batch of up to about ten items, not forty.
• Ask for the new report link back after the deploy, and compare the two in the history strip.

Why a score is not a brief

A score is the output of more than 150 checks. It says nothing about which page was tested, on which device, what exactly failed or where the evidence is. A developer who receives only the number has to re-run the check, probably with a different tool, get different numbers, and then guess what you care about. That first hour is pure translation, and the result is often a fix for something you did not ask about.

A brief is the inputs: the page, the device, each problem with its evidence and the steps to fix it, plus your priorities. The report already holds all of that. The fixes view strips it down to the part a developer needs and puts it in formats their tools read.

It also keeps the conversation friendly. "The theme loads 14 fonts" with the list of files is a task. "The site is slow" is a complaint.

How getReport checks it

Any report has a fixes view, whichever tool started it; the WordPress checker and the SEO audit are the most common starting points. The view shows every open finding (failed and warnings, no passed checks), grouped by effort:

Each item carries:

• The title with the real value ("Plain permalinks are in use (12 links like ?p=123)").
• Chips for Failed or Warning, the module, and the points it would give back to that module.
• Why it matters, in two lines.
• Numbered steps, with the admin path or config line where one exists.
• Affected: the first five items of the evidence (URLs, files, headers) and how many more there are.
• Guide: the learn page for that check, which links on to the in-depth guide.

Within each group the items are sorted by points, failures before warnings. Three items that turn up on many WordPress lists show how much the steps already carry:

Two of those three are a checkbox in wp-admin that you can tick yourself. That is the first thing worth noticing in any fixes list.

Step by step

1. Open the fixes view

Click "Fixes for your developer" in the report header, or take the report link and add /fixes: https://getreport.app/r/AbC123xYz0/fixes. On a WordPress report, the "Send to my developer" link in the WordPress Doctor panel goes to the same page. The page is not indexed by search engines; anyone with the link can open it, like the report itself.

If the report is older than a few days, press Re-run on the report first so the list reflects the site as it is now.

2. Split out what you can do yourself

Read the list once with a pen. Many items are settings or content, not code:

• Titles, meta descriptions, image alt text, the tagline, social preview images.
• WordPress settings: Settings → Reading (the search visibility checkbox), Settings → Permalinks, Settings → General.
• Switching on an option in a plugin you already use (browser caching, image compression).

Doing those yourself shortens the developer's list and means the brief contains only work that needs a developer. For the WordPress-specific ones, WordPress rookie mistakes has the admin paths.

3. Pick the first batch

A developer can plan ten related items; forty items across seven modules reads as "everything is broken". Take the top of the list in this order:

1. Security failures: HTTPS, the http-to-https redirect, certificates, exposed files.
2. Speed failures: LCP, CLS, INP or Total Blocking Time in red. The warnings under them (render-blocking files, oversized images) are usually the cause, so they travel together.
3. Anything that stops indexing: noindex, a robots.txt block, a wrong canonical. If one of these is on the list, it goes first, before everything else.
4. The rest, smallest effort first.

The report's own ranking helps: Top fixes and the points chips show where the score is. How that ranking works is explained in how to read a getReport report.

4. Export it into their tools

The four buttons at the top of the fixes view:

• Copy as Markdown copies the whole checklist. It pastes cleanly into a GitHub or GitLab issue, where the - [ ] lines become ticking checkboxes, and into most email clients as plain text.
• Download Markdown saves the same text as a .md file for a ticket attachment or a shared drive.
• Trello / Jira CSV downloads one row per fix with the columns Title, Description, Priority (High for failures, Medium for warnings), Labels, Effort, Points, Module, Check, Guide and Report. Jira's CSV importer maps these to issue fields; most other trackers accept a CSV import, sometimes through an add-on.
• Open as GitHub issue starts a new GitHub issue with the title and checklist filled in. Very long lists are cut to fit a link, so for those paste the Markdown instead.

The Markdown starts with the report link, the tested page, the time and the device, so the developer can reproduce exactly what you saw. If you removed items in step 2 and 3, delete them from the pasted text before sending.

5. Add two sentences of context

This is the part no tool can write, and it saves the most time. Answer three questions in two sentences:

• What is the site for? "Online shop, most orders from mobile" tells the developer that mobile speed and the checkout come first.
• What changed recently? A new theme, a new plugin, a host move, a new tag manager setup. Most new findings trace back to the last change.
• When do you need it? A date, and what happens on that date (a campaign, a launch, a client meeting).

A template that works as a GitHub or GitLab issue, or as an email:

Title: Website fixes for example.com – batch 1 (security + speed)

Context: example.com is our online shop; about 70 % of orders come from
phones. We switched to a new theme on 2 September. We would like batch 1
live before the autumn campaign on 14 October.

Report (before): https://getreport.app/r/AbC123xYz0
Tested page: https://www.example.com/ (mobile)

Batch 1 – please fix in this order:

- [ ] http:// does not redirect to https://  (Security, failed)
- [ ] Strict-Transport-Security header is missing  (Security, warning)
- [ ] Largest Contentful Paint is 4.1 s (aim for 2.5 s or less)  (Speed, failed)
- [ ] Render-blocking resources delay the first paint (saves 1.2 s)  (Speed, warning)

Already done on our side: meta descriptions, tagline, alt text.
Not in this batch: structured data and social preview items.

When it is live: please press Re-run on the report and send the new link,
or tell us and we will. If an item cannot be done on this host, a one-line
reason is fine.

(Full steps and evidence for each item: paste from "Copy as Markdown" below.)

6. Agree the order in a short call or thread

Let the developer re-group the list by where the fix lives. The four security headers are one block of server config; three image findings are one change to the theme. Your order says what matters; theirs says how to do it efficiently. Both are right, and five minutes of talking saves a week of back-and-forth.

If they say an item cannot be done, ask why and write it down. On hosted platforms some server settings are simply out of reach, and a finding that stays open for a good reason is fine.

7. Ask for a before/after link, not a screenshot

The deliverable is the new report link. With the old and the new link side by side, anyone can see which items passed, and the history strip on the new report shows the change since the previous run for Overall, Speed, SEO and Security.

Platform notes

WordPress

The WordPress Doctor panel after Top fixes names the plugins, theme and page builder the page reveals, so the developer knows the stack before logging in. Its findings are in the fixes list like any others. Plugin-specific items (a duplicate SEO plugin, a caching plugin without browser caching) are often a settings change, not development.

Shopify, Wix, Squarespace

Theme code and apps are editable; the server, redirects at the server level and most headers are not. Mark those items "platform" in the brief so nobody spends an hour looking for a setting that does not exist.

Verify

• After the deploy, open the original report and press Re-run. Without it you may get the stored report from the last 12 hours.
• The new fixes view is shorter, and the batch items are gone from it or have moved from Failed to Warning.
• The history strip on the new report shows a positive change for the modules the batch touched.
• Keep both links in the issue. They are the record of what was done and when.

Common mistakes

• Sending all 40 items at once. Nothing gets done first because everything looks equally urgent. Send one batch, verify it, send the next.
• Asking for "a 100 score". Some findings are out of reach on some hosts, and Lighthouse moves a few points between runs. Ask for the batch to pass, not for a number.
• Changing the site while it is being measured. A deploy, a cache purge or a new banner during the re-run gives numbers nobody can explain. Re-run after the deploy has settled and the CDN cache is warm.
• Comparing a desktop "after" with a mobile "before". The header of each report shows the device; keep it the same.
• No context. Without "what changed recently", the developer investigates the whole site instead of the last change.