# Picking which fixes to do first: impact vs effort, with numbers
> A report lists 40 findings and you have an afternoon. See how getReport ranks them, why points alone are the wrong order, and a 2×2 that turns the list into three fixes a week.
Updated 2026-09-25 · Workflows & checklists · HTML version: https://getreport.app/guides/picking-which-fixes-to-do-first-impact-vs-effort
A report with 40 open findings is not a to-do list; it is a menu. Some items take ten minutes and remove a real risk, some take a week, and a few have to wait for others. This guide shows how the report ranks findings, where that ranking stops being enough, and a 2×2 that gives you an order to hold to. Plan 20 minutes with the report open.
## Quick answer
- **Top fixes** are the five open findings that cost the most points. **Effort** (S, M, L) is a fixed label per check and plays no part in that ranking. Read both chips together.
- Order by four rules: whatever blocks indexing first, then failed security items, then the biggest speed item on each template, then breadth.
- Most sites share the same quick wins: security headers, compression, cache headers, title and description lengths, alt text, a stray `noindex` or canonical, certificate renewal, the WordPress rookie list.
- Skip for now: info-level items, best-practice warnings while Security is failing, minor accessibility items while a form is broken.
- Group tickets by owner (host, theme or CMS, content, developer), ship three fixes a week, re-run to close each one.
## Why the order matters
Two findings can be worth similar points and cost wildly different amounts of work. A missing `Strict-Transport-Security` header is one line of server config; a slow Largest Contentful Paint on a page-builder hero can be a week of theme work. Sorted by points alone, the week-long item comes first, the first afternoon goes nowhere, and the report gets closed as "too much".
Some fixes also depend on others. HSTS sent before every subdomain works over HTTPS locks visitors out of the one that does not. Hreflang added before the canonicals are right sends Google alternates it will ignore. Getting the sequence right is most of the skill.
## How getReport checks it
> **Free tool:** [Free SEO audit](https://getreport.app/tools/seo-audit): Every on-page and technical SEO check in one run: title and description, headings, canonical, robots and sitemaps, indexability, links, images and mobile readiness — each with a fix.
Every check in the catalogue has a severity, a weight and an effort label. A failed finding costs its full weight in points, a warning costs half, and info or passed items cost nothing. Six of the seven modules score 100 minus those points. Speed is the exception: its score is Lighthouse's performance score, while each speed finding still shows the points its catalogue weight gives it. The overall grade is the weighted mean of the modules: Speed 30 %, SEO 25 %, Security 15 %, Accessibility 10 %, Best practices 10 %, Structured data 5 %, Social 5 %. So a 10-point SEO finding is worth about 2.5 points overall.
**Top fixes** takes every finding with points above zero, sorts by points, puts failures before warnings on ties, and shows the first five with a points chip and an effort chip. The effort label comes from the catalogue: it estimates the usual size of the job, not the size on your site. **Fixes for your developer** (the button in the report header, or the report address plus `/fixes`) lists every open finding under Small, Medium and Large effort, highest points first within each group. Points are rounded there, so a 1.5-point warning shows as +2.
Four findings that show the spread:
> **Check: Largest Contentful Paint.** LCP is when the biggest thing on screen — usually the hero image or headline — finishes loading. Visitors judge "is this site slow?" on it, and Google uses it for ranking.
>
> 1. Find the LCP element (named in your report) and make it lighter, earlier or both — a compressed WebP/AVIF, sized to the screen, without lazy loading.
> 2. Preload it with or add fetchpriority="high" on the .
> 3. Cut what comes before it — render-blocking CSS/JS and slow server responses push LCP back.
Weight 25, effort M. Speed weights mirror the metric weights of the [Lighthouse performance score](https://getreport.app/learn/lighthouse-performance-score) (Total Blocking Time 30, LCP and Cumulative Layout Shift 25 each), so speed findings dominate Top fixes on slow pages.
> **Check: Strict-Transport-Security header is set.** HSTS tells browsers to always use HTTPS for your site, so after the first visit a typed address or an old http:// link never starts on an unencrypted connection. Only the preload list covers the very first visit.
>
> 1. Send the header: Strict-Transport-Security: max-age=31536000; includeSubDomains.
> 2. Start with a shorter max-age (e.g. 86400) if you are not sure every subdomain supports HTTPS.
A warning with weight 5, so 2.5 points (+3 on the chip), effort S. It is also the textbook prerequisite: only after HTTPS works on every host.
> **Check: Every image has an alt attribute.** Alt text is how Google Images and screen readers understand a picture. Missing alt text loses image traffic and fails accessibility.
>
> 1. Describe each meaningful image in a short alt attribute ("Blue running shoe, side view").
> 2. Give purely decorative images an empty alt="" so screen readers skip them.
A failure worth 8 SEO points with small effort: often the best points per minute on the page.
> **Check: Title length.** Google truncates titles past about 60 characters and may rewrite very short ones, so your chosen wording does not reach searchers.
>
> 1. Rewrite the title to 30–60 characters, main topic first, brand last.
> 2. Keep the most specific words at the start; they survive truncation.
A warning with weight 3, so 1.5 points, effort S. Cheap, but if the SEO plugin or theme builds the title, the fix belongs in the template ticket, not in a page edit.
## Step by step
### 1. Fix what blocks indexing, whatever the points say
Look in the SEO module for "The page cannot be indexed", a canonical pointing somewhere else, and robots.txt blocking the page; on WordPress, also "Discourage search engines" is switched on. Any of these on a page that should rank goes first: nothing else in SEO counts until the page can be indexed.
### 2. Sort the rest into the 2×2
**Impact** starts from the points and is adjusted by what the finding touches:
- **Visitors**: does everyone feel it (speed, a broken form, a certificate warning) or a few (a missing `apple-touch-icon`)?
- **Revenue**: is it on the checkout, the pricing page, the top landing page?
- **Risk**: could it cause harm if left (exposed files, no HTTPS, a certificate expiring next month)?
- **Ranking**: does it stop indexing, split signals across duplicates, or lose a rich result?
A 2-point finding that stops a page being indexed is high impact. A 12-point finding on a page nobody visits is not.
**Effort** starts from the label and is adjusted for your stack: an S becomes an M when you have no server access and must ask the host; an M becomes an S when the fix is a toggle in a plugin you already run.
| | Low effort | High effort |
| --- | --- | --- |
| **High impact** | **Do now.** Exposed files, `noindex` left on, an expiring certificate, alt text on the hero, compression, the header batch. | **Plan.** LCP on the hero, third-party scripts, CLS from ad slots, a page-builder change, a CSP rollout. |
| **Low impact** | **Fill in.** Title and description length, `apple-touch-icon`, Organization logo, the default "Hello world!" post. | **Park.** DOM size on a page that already scores well, a schema type you do not need. |
"Do now" is your first two weeks, "Plan" gets a ticket with an estimate, "Fill in" goes into spare hours, "Park" is reviewed next quarter.
### 3. Then the failed security items
Failures in Security (plain HTTP, readable `.env` or `.git` files, an expired certificate) affect every visitor or leak secrets. The header warnings are the classic quick win: one config block, ten minutes. The full config is in [security headers from zero to A](https://getreport.app/guides/security-headers-from-zero). Send HSTS last in that batch, once every subdomain answers over HTTPS.
### 4. Batch the quick wins most sites share
Check each against your report:
- Security headers (`X-Content-Type-Options`, `X-Frame-Options`, `Referrer-Policy`, `Permissions-Policy`, then HSTS).
- Text compression and long cache lifetimes for static files: two server settings.
- Title and meta description lengths on the pages you tested.
- Alt text on the images the finding lists, starting with the hero and the products.
- A stray `noindex`, a wrong canonical, a `Sitemap:` line missing from robots.txt.
- Certificate renewal set to automatic.
- The WordPress rookie list: default content, plain permalinks, the public `admin` author, attachment pages.
Eight of these in one afternoon is realistic.
### 5. One speed item per template
Speed findings repeat on every page that shares a template, so pick the biggest one per template: on a shop, the category page's LCP image, the product page's third-party weight. Fix it once in the template and re-run one page of each kind on the [speed test](https://getreport.app/tools/speed-test). The method for the most common one is in [how to fix Largest Contentful Paint](https://getreport.app/guides/fix-largest-contentful-paint).
The slow-but-worth-it list, each a "Plan" item with a ticket and a re-run date: LCP on the hero when the fix is a template or builder change; third-party scripts (tag managers, chat widgets, ad tags), where the fix is deciding what to remove; DOM size above 3,000 nodes; layout shift from ads or late embeds; a builder or theme change. One a month is a good pace.
### 6. Do not bother yet
- **Info-level items.** They carry no points (analytics detected, structured data types found). Read them; do not ticket them.
- **Best-practice warnings while Security fails.** A missing touch icon can wait until the site is on HTTPS.
- **Minor accessibility items while a form is broken.** A caption's contrast matters less than a submit button the keyboard cannot reach.
### 7. Group by owner and export
| Owner | Typical items |
| --- | --- |
| Host or server admin | HTTPS, security headers, compression, cache headers, TLS versions, certificate automation, HTTP/2, blocking dotfiles |
| Theme or CMS admin | Permalinks, default content, canonical settings, sitemap, the 404 template, cache exclusions |
| Content editor | Titles, descriptions, alt text, broken links in posts, thin pages |
| Developer | LCP element, render-blocking files, third-party scripts, DOM size, CSP, structured data properties |
The fixes view does the mechanical part: **Copy as Markdown** or **Download Markdown** gives a checklist grouped by effort, **Trello / Jira CSV** gives one card per finding with Priority (High for failures, Medium for warnings), Effort and Points columns, and **Open as GitHub issue** starts an issue with the checklist filled in. The hand-over is covered in [send the fixes to your developer](https://getreport.app/guides/send-fixes-to-your-developer).
### 8. Three fixes a week, re-run to close
A 40-item list nobody starts loses to three fixes a week that get done: pick Monday's three from "Do now", re-run on Friday, repeat.
Every fix ends with a re-run of the same page on the same device: the **Re-run** button skips the 12-hour cache. Each host allows 5 fresh runs an hour, so re-run per batch, not per fix. Keep both report links as the before and after.
### 9. A worked example: the example shop
The example shop fixture (a WooCommerce store on Elementor, the site the mockups show) has 42 open findings on its home page. Its Top fixes, as the report ranks them:
| Rank | Finding | Points | Effort |
| --- | --- | --- | --- |
| 1–2 | Cumulative Layout Shift is 0.271 | 25 (Speed) | S |
| 1–2 | Largest Contentful Paint is 10.5 s | 25 (Speed) | M |
| 3–4 | The site is served over HTTP, not HTTPS | 15 (Security) | M |
| 3–4 | Sensitive files are readable by anyone | 15 (Security) | S |
| 5 | 1 critical accessibility violation | 10 (Accessibility) | M |
Put through the 2×2, the order changes:
1. **Sensitive files first.** `/.env` and `/.git/HEAD` are readable: that is database passwords and source code. Small effort, the highest risk on the page, and the credentials need rotating the same day.
2. **HTTPS next.** Every visitor sees "Not secure", and the header batch and HSTS depend on it. Medium on paper; most hosts have a one-click certificate.
3. **Alt text, in one editor session.** The critical accessibility violation lists the same images as "15 images have no alt attribute" (SEO, 8 points) and the accessibility alt-text warning. One session clears three findings.
4. **Layout shift.** The catalogue says S because the usual fix is width and height on images, and "3 images have no width and height attributes" names them, the 1.8 MB hero among them. Do it with the alt text.
5. **LCP is a "Plan" item.** At 10.5 s the LCP element (a product thumbnail) waits behind render-blocking CSS, a 1.8 MB hero image and 12 requests on HTTP/1.1. That is a ticket with an estimate, not an afternoon.
One finding outside the top five jumps the queue: "The cart or checkout is served from a page cache" is 8 points, but a cached cart can show one shopper another's basket. On a shop that is high impact and goes straight after HTTPS. The fill-ins (title length, the "Hello world!" post) ride along with the alt-text session.
## Platform notes
### WordPress
Most "Do now" items are a setting: permalinks under Settings → Permalinks, titles and descriptions in the SEO plugin, alt text in the media library. The WordPress Doctor panel counts the rookie mistakes and, where it recognises your plugins, links step-by-step recipes for them.
### Shopify
HTTPS, compression, caching and HTTP/2 are the platform's job, so those rows are not yours. Your "Do now" list is content: titles, descriptions, alt text, menu links, the hero image size.
### Static sites and custom builds
Everything is a developer ticket, so batch by effort rather than owner. Headers and caching are one config file at the host and belong in the first pull request.
## Verify
- Each fixed finding moves to the passed list on a re-run of the same page, same device.
- The history strip under the score row shows the change for Overall, Speed, SEO and Security; open the module tabs for the rest.
- The quick-wins batch holds on other pages too: re-run one page per template.
- Every "Plan" item has a ticket with an owner, an estimate and a re-run date.
## Common mistakes
- **Chasing the score.** A page at 92 with a broken checkout is worse than a page at 78 that sells. How to say that to a stakeholder is in [explaining a score to a client](https://getreport.app/guides/explaining-a-score-to-a-client).
- **Starting with the hardest item.** The LCP rebuild is exciting and takes a month; the header batch takes an afternoon. Do the afternoon first.
- **Fixing a template on one page.** A title edited by hand while the template writes the same pattern on 400 pages. Find where the value comes from first.
- **Closing tickets without a re-run.** "Deployed" is not "fixed": a cache still serving the old header, a plugin overriding the setting. The re-run is the acceptance test.
- **Treating effort labels as estimates for your site.** S, M and L describe the usual job. A "small" header change on a host with no config access is a support ticket and a week of waiting.