How to Write a Website Audit Proposal That Actually Gets Signed

I have written somewhere north of two hundred of these, for agencies, for solo consultants, and for a few people who should probably not have been selling audits at all. The website audit proposal is the document that decides whether a fifty-page technical review turns into paid work or into an unpaid sample nobody reads twice.

Most freelancers treat the proposal as an afterthought. They do the audit first, because the audit is the fun part, then push the findings into a template they found on a design blog and hope the client signs. Then they wonder why the client takes the free report, thanks them, and goes quiet.

The problem is almost never the quality of the audit. It is that the proposal answers a question the client never asked. Your client did not ask “what is wrong with my site.” They asked “is this worth spending money on, and are you the person to spend it on.” A findings dump does not answer either.

Below is the structure I use now, the order I build it in, and the specific sentences that do the work. It is a long read because the document itself has to handle objections that would otherwise surface as silence. If you only take one thing from it: the proposal is a business document with technical evidence attached, not a technical document with prices stapled to the end.

What a website audit proposal actually has to do

Four jobs, in this order of importance. If your document does not do all four, it will underperform no matter how good the audit behind it is.

1. Prove you looked. Specificity is the cheapest credibility you can buy. A proposal that says “your site has performance issues” is a template. A proposal that says “your homepage ships 2.4 MB of JavaScript before first paint, and 61 percent of that is three plugins you are not using” is a person who opened the site.

2. Translate findings into business consequences. The client does not care about LCP. They care that their mobile bounce rate is 71 percent and their contact form submissions dropped by a third after the redesign. Every technical line item needs a sentence next to it that a non-technical stakeholder can repeat in a meeting.

3. Define the scope boundary explicitly. The single largest source of scope creep in audit work is a vague boundary. If the client can point at any future task and say “that was in the audit,” you have a problem. Say what is in, say what is out, and say what happens when something out becomes urgent.

4. Make the next step a single, cheap decision. Not “let us know how you would like to proceed.” One decision, with a date, and an honest alternative if they want to do nothing.

Notice what is missing from that list: proving you are the best person for the job. Credentials belong in the proposal, but they belong as evidence that you can execute the fix, not as a substitute for it. Long about-the-agency sections in audit proposals are usually a symptom of the writer not trusting the findings.

The order I write a website audit proposal in (it is not the order you read it)

I build the document back to front. The reason is practical: the executive summary is the only section most decision makers read, and you cannot write a good summary of a document that does not exist yet. Writing the summary last means it is a compression of real content instead of a promise you have to keep.

My build order:

1. Findings table (raw, unsorted, no prose)
2. Severity and effort scoring for each finding
3. Grouping into phases
4. Scope and exclusions
5. Timeline and assumptions
6. Pricing
7. Executive summary (written last, placed first)
8. Appendix (screenshots, raw data, methodology)

If you have ever run a batch audit across a lot of pages, you already know why step one happens before any writing. The content audit workflow I run for large libraries is where this habit comes from: collect first, judge later, and never let narrative get ahead of the evidence.

Section 1: The cover and the one-line premise

Boring cover, one line of substance. Client name, site URL, date, your name and contact. No stock photo of people shaking hands, no gradient banner.

The line that matters sits underneath the title, and it states the premise of the document in plain language. Examples that work:

• “A technical and content review of example.com, with eleven findings ranked by revenue risk, and a proposed four-week remediation plan.”
• “What is slowing down your checkout, what it costs you per month in abandoned carts, and what it takes to fix.”
• “An independent review of the site you are about to acquire, focused on liabilities that would affect the purchase price.”

Note that each of these names the audience’s actual decision. The first is a general engagement, the second is a conversion problem, the third is due diligence. Same service, three different documents.

The premise line also does quiet scope work. “Eleven findings” tells the reader how much is coming. “Four-week remediation plan” tells them this is a plan, not a 90-page PDF. Under-promising on the cover and over-delivering in the appendix is a much better error than the reverse.

Section 2: The executive summary (half a page, no jargon)

This is the section that gets forwarded to the person who controls the budget, who will not read anything else. Write it for someone who has never opened Search Console and never will.

Four paragraphs, in this structure:

Paragraph one: the finding. One sentence on overall health, one sentence on the most consequential problem. “The site is fundamentally sound on content but has a technical regression introduced in the March redesign that is costing an estimated 15 to 20 percent of organic clicks on mobile.”

Paragraph two: the cost of inaction. Put a number on it if you honestly can, and say how you got the number. Do not invent a number. If you cannot quantify it, quantify the trend instead: “mobile conversion has declined four consecutive months since the redesign.”

Paragraph three: what you propose. Phase names, durations, and total investment. Three lines maximum. The reader should be able to repeat this paragraph from memory after one read.

Paragraph four: the decision. What you need from them, by when, and what happens if they do nothing. Not a threat, a fact: “Without changes, the current trajectory continues, and the plugin stack will be three versions behind by Q2.”

Do not put a single number in this section that you cannot defend. The summary is where proposals die. If a stakeholder spots an inflated estimate here, they will discount every number in the rest of the document, including the accurate ones.

Section 3: The findings table (the part most proposals get wrong)

Full findings, as a table, one row per issue. Columns: what, where, severity, business impact, effort to fix. Sort by severity, then by business impact.

The mistake is dumping every issue you found. A 47-row table reads as thorough to the author and as exhausting to the reader. It also invites the client to cherry-pick the three cheapest rows and call it done.

My rule: the table contains every finding with a severity of medium or above, plus a single consolidated row for all low-severity items (“14 minor items: broken social icons, inconsistent heading levels, missing alt text on nine images”). The full low-severity list lives in the appendix. Nobody has ever complained about that.

Severity needs a definition printed right above the table, or every row becomes a negotiation:

• Critical — actively losing money today, or blocks a pending launch.
• High — measurable loss, will compound within a quarter.
• Medium — degrades performance or credibility, no immediate revenue impact.
• Low — hygiene. Fix when adjacent work is already scheduled.

Effort gets its own scale, in hours or half-days, not in adjectives. “Small” means nothing. “Two to three hours including QA” means something, and it is the number you will be held to if the client later asks why the fix took longer than the audit suggested.

The business impact column is where most proposals go blank, so here is the pattern I use. For each finding, name the mechanism, not the metric: “Checkout JS error on iOS Safari — 31 percent of mobile sessions hit this path, and affected sessions show a 2.1x higher abandonment rate.” The mechanism is what a stakeholder can reason about. The metric alone is trivia.

If your audit covers content as well as technical issues, separate them into two tables. Mixing “missing canonical tag” with “your top landing page targets a keyword you cannot rank for” makes both feel smaller. The site audit checklist I work from has the full category breakdown if you need a starting taxonomy.

Section 4: Grouping findings into phases

Phases exist for one reason: to let the client buy part of the work without buying all of it. A proposal with a single price fails whenever the client’s budget does not match your total, because the only alternative to yes is no. A proposal with three phases fails less often, because the client can say “phase one and two” and you still book work.

I use three phases with a specific logic:

Phase 1 — Stop the bleeding. Only critical findings. Shortest possible duration, usually one to two weeks. The goal is that within fourteen days the client can see something visibly fixed. This phase is deliberately priced so that saying no to it feels unreasonable.

Phase 2 — Structural fixes. High severity, plus the architecture changes that make Phase 1 fixes durable. Longer, usually three to six weeks. This is where most of the value is and where most of the money sits.

Phase 3 — Ongoing. Monitoring, regression prevention, quarterly re-audit. Priced as a retainer, not a project. Optional, and honestly optional — some clients genuinely do not need it, and saying so buys credibility for the clients who do.

Every phase needs an explicit “done” definition. Not deliverables, a finish line. “Phase 1 is complete when: mobile CLS is under 0.1 on the five template pages, the checkout error no longer reproduces on iOS Safari 17, and the redirect chain on /pricing/ resolves in one hop.” A client can verify those without you, which is the point.

The same logic applies to any client-facing deliverable with a fixed fee: as covered in the case study workflow, naming what is out of scope at the start is what makes a fixed price survivable in practice.

Phase boundaries also protect you. If Phase 1 is “fix the checkout,” you will end up rebuilding checkout. If Phase 1 is three named, testable conditions, you have a defensible exit.

Section 5: Scope and exclusions (write the exclusions first)

Nobody reads the exclusions until there is a disagreement, and then the exclusions are the only thing that matters. Write them before you write the scope, because the exclusions are what turn “audit the site” into a number you can quote.

My exclusion list, near-verbatim, for a standard audit engagement:

• Not included: writing or rewriting copy beyond the recommendations in the findings table.
• Not included: implementing fixes. Audit and remediation are separate engagements and separately priced; a client is free to implement internally or with another vendor.
• Not included: paid media accounts, analytics property configuration, or CRM data. If access is needed for diagnosis, it is read-only and time-boxed.
• Not included: pages that require authenticated sessions, including customer accounts and the internal admin.
• Not included: any remediation of findings discovered after the audit cut-off date.
• Not included: server-level work, infrastructure migration, or theme rebuilds.
• Not included: legal, accessibility certification, or compliance sign-off. Findings relating to these are advisory only.

Then, the sentence that saves the engagement: “Items outside this scope are welcome to be raised. I will quote them separately before any work begins, and no out-of-scope work proceeds without written approval.”

That single line does more for retention than any pricing structure. It tells the client you will not surprise them, which is the actual fear behind most scope objections. It also gives you a clean way to say no to a request without seeming difficult.

The accessibility and compliance exclusion is not boilerplate. If your audit tags something as an accessibility issue and the client reads that as a certification, you have taken on liability you did not price. Say advisory, say clearly, say it in the exclusions and again in the findings table footer.

Section 6: Timeline, assumptions, and access requirements

Three sub-sections, each short. This is the section that separates proposals that close from proposals that stall in “let me check with my developer.”

Timeline

Give the timeline in working days from a named trigger, not calendar dates. “Fourteen working days from receipt of access and payment of the deposit” survives weekends, holidays, and a client who signs on a Friday afternoon. Calendar dates in a proposal create a deadline that starts before you have access, which is a deadline you will miss.

Break the timeline into the same phases as the pricing, with one extra line: the client’s review window. If every draft you send sits for a week before feedback, the project slips and it looks like your problem. Naming the review window up front — “two working days per review round, after which the schedule shifts by the delay” — is not hostile. It is arithmetic, stated in advance.

Assumptions

Assumptions are the things that, if wrong, change the price. List them explicitly:

• Staging environment is available, or changes can be scheduled outside trading hours.
• CMS and server access is provided within one working day of signing.
• One stakeholder has authority to approve changes; conflicting approvals will pause work.
• The site is not undergoing a concurrent redesign or platform migration.
• Content volume does not exceed the page count stated in the introduction.

That last one matters more than people expect. If the client adds a hundred pages mid-engagement, the timeline is wrong and it was not your fault, but you need the assumption on record to say so gracefully.

Access requirements

Be specific, and be specific about what you will not do with it.

“Read-only where possible. Editor or administrator access only where a fix requires it, and only for the duration of that fix. Credentials are stored in a password manager and revoked at project end. Two-factor authentication is required on every account I am given access to, and I will request it even if it adds a day to onboarding.”

That last clause costs you almost nothing and buys a surprising amount of trust. It also protects you. If a client’s site is compromised during an engagement and there was no 2FA, the conversation is very different from one where you required it in writing and they declined.

Section 7: Pricing (three numbers, one recommendation)

Present pricing as three options with a clear recommendation. Not a menu, not a “contact us for a quote.” Three numbers, each tied to a defined outcome, and one of them marked.

The structure I use:

Option A — Audit only. The findings, the phased plan, and a handover call. Priced as a fixed fee tied to page count and scope. This exists so that clients who genuinely want to implement in-house have a legitimate path, and so that your proposal is not a hostage negotiation.

Option B — Audit plus Phase 1 remediation. Recommended. Marked as such. Usually 40 to 60 percent above Option A. This is the option you actually want and the one most clients take, because it is the smallest package that produces visible change.

Option C — Full remediation. All three phases, with the audit included at no additional charge. Priced high enough that it is a real option rather than an anchor, and honest enough that some clients choose it because the math works for them.

Two pricing rules I do not break. Both of them came from getting this wrong early on, when I was selling audit work as an add-on to other services:

The audit is never free. A free audit converts into an unpaid consulting session, and it attracts the clients who value it accordingly. If you want a low-friction entry, sell the audit at a deliberately low fixed price, not at zero. Why I stopped paying for audits covers the other side of this: what actually justifies an audit fee is evidence nobody else has collected, not a report nobody else could produce.

Every option gets the same findings. Never gate the findings behind the remediation purchase. It looks like hostage-taking, clients notice, and the ones who pay for remediation were never going to be converted by holding the report back anyway.

One thing worth saying out loud here: if the client is paying per deliverable elsewhere in their business, they will expect the same rhythm from you. The retainer logic in this service breakdown is a useful reference for how to structure recurring work without inventing a new model.

On payment terms, state them plainly: deposit percentage, invoice schedule, what happens to work already delivered if the engagement stops early. “Fifty percent on signature, fifty percent on delivery of the Phase 1 completion report. Work already delivered is billed at the phase rate if the engagement is terminated.” That sentence has ended exactly one uncomfortable conversation in my experience, because it existed.

If you want to understand what a fair number looks like before you commit to one, the way I price workflow and service engagements is laid out in the freelance audit service breakdown. The logic transfers: price the decision-support, not the hours.

Section 8: The ‘why me’ section that does not read like a brochure

Three short paragraphs maximum. No client logos you cannot name, no “passionate about digital,” no stock photographs of a conference lanyard.

Paragraph one: relevant specificity. One or two engagements that are genuinely similar in structure — similar platform, similar size, similar problem class. Not your biggest client, your most similar client.

Paragraph two: the method. One sentence on how you work that a client would notice as different. For me it is that every finding in the report is reproducible: the appendix contains the command, the tool version, and the timestamp for each one, so another developer can verify it independently. That is a claim you can check, which is worth more than any adjective.

Paragraph three: who does the work. Named person, not a company. If a subcontractor touches the site, say so here. Clients forgive a small operation; they do not forgive discovering it in month two.

That is the whole section. If it runs past half a page, cut the third paragraph and merge the second into the first. The findings table is your real credential.

Section 9: The appendix (where trust is actually built)

The appendix is what makes the proposal defensible in a room you are not in. When the client forwards the document to their developer, the developer will look at the appendix first and the findings table second. If the appendix holds up, the whole document holds up.

What goes in:

• Methodology. Tools, versions, dates, and settings. “Lighthouse 12.1, mobile emulation, throttled 4G, run three times, best run reported” is a methodology. “Performance testing” is not.
• Screenshots with timestamps. Every critical finding gets one. A screenshot is the difference between a claim and an observation.
• Raw data exports. Search Console queries and pages, crawl output, redirect chains. Even if the client never opens them, their developer will.
• Reproducible commands. Where applicable. A line like “curl -sI https://example.com/pricing/ | grep -i cache-control” lets anyone confirm your claim in five seconds.
• What I checked and found clean. This is the section almost nobody includes and the one that separates a review from a search for problems. “Checked and passing: HTTPS and HSTS configuration, sitemap structure, image compression on the ten largest images, canonical tags on all sampled pages.”

That last bullet does real work. It tells the client you were not hunting for a billable issue, and it tells their developer you know what a healthy site looks like. It also protects you: if a problem later appears in an area you reported as clean, you can point to the date and scope of what you tested.

If you are running the audit with a scanner rather than by hand, the reproducibility point gets easier and the presentation point gets harder. A tool that checks a site against structured signals produces evidence that is trivially verifiable but reads as machine output. The approach I use for review at that scale is the compromise: automate collection, hand-write the interpretation, and keep the raw output in the appendix where it belongs.

The three objections every audit proposal has to answer before they are raised

Clients do not usually voice objections. They go quiet, and quiet reads as disinterest when it is actually an unresolved doubt. There are three common ones, and every one of them can be handled in the document itself.

“We already know our site is slow. Tell us something new.”

This is not an objection to your price. It is an objection to your information. The answer is not to insist that you will find more, because you might not. The answer is to reframe what the audit produces: not a list of known problems, but a ranked answer to “which of these is actually costing us money, and in what order should we fix them.”

Put that sentence in the proposal near the findings table: “The purpose of this review is not to discover that the site is slow. It is to determine which specific components are responsible, what each costs per month in lost sessions or conversions, and which three fixes between them account for most of the loss.” That converts a commodity into a decision, and decisions are what people pay for.

“Can our developer just fix it? Send us the report.”

Sometimes the honest answer is yes, and saying so wins you the next engagement. This is exactly why Option A exists as a real product with a real price.

But there is a second half of the answer that belongs in the proposal: a developer asked to fix “the site is slow” will optimise whatever is easiest to optimise, which is rarely the bottleneck. The audit’s value in this scenario is the priority order and the acceptance criteria, both of which the developer can work from and neither of which they will produce themselves. Frame Option A as handing their developer a specification, not a critique. It changes the emotional read of the whole document.

“Give us a discount and we will sign today.”

Not an objection, but it shows up in the same conversation, and it is worth deciding your position before it arrives. Mine is that the price does not move, but the scope can. If the budget is genuinely lower, I will propose a smaller document — fewer pages sampled, technical review only, no content assessment — at the lower price. What I will not do is the same work for less, because a discount on identical scope tells the client the original number was invented.

Having that position worked out in advance, and stated once in the proposal as “scope is flexible, price follows scope,” removes the negotiation from the relationship before it starts.

Writing the findings so they survive being forwarded

Your document will be read by at least two people: the person who commissioned it and the person who will implement from it. Those readers want different things, and the same sentence has to serve both. The pattern that works is a consistent two-part structure for every finding.

Part one, for the implementer. What is technically wrong, where exactly, and how to verify it. “On /products/, the filter form submits via GET and generates 1,100 indexed parameter URLs; none carry a canonical tag pointing to the base URL.”

Part two, for the decision maker. What it costs, in the currency the business actually uses. “These URLs dilute the crawl budget for real product pages and appear in search as near-duplicate results. Estimated impact: the four filter URLs currently ranking are variants of the same page, so all four compete for one query.”

Two sentences per finding, in that order, every time. The implementer skips the second sentence, the decision maker skips the first, and neither feels condescended to. When proposals fail in review, it is usually because the writer only wrote one of the two and lost half the audience.

One more formatting rule: never put an unresolved question inside a finding. If you are not sure whether something is causing harm, put it in a separate “open questions” list at the end of the findings section, with what you would need to answer it. Findings are assertions. Mixing in speculation is how an audit loses authority, and it is a harder habit to break than it sounds. When I started doing auditing before publishing rather than after, this was the single discipline that changed how clients responded: every line was either verified or explicitly flagged as unverified.

What a complete website audit proposal looks like, section by section

Here is the whole document as a checklist you can build against. Twelve sections, roughly eight to fourteen pages, of which the appendix is usually the longest.

1. Cover. Client, URL, date, author, contact. One-line premise under the title.

2. Executive summary. Half a page. Finding, cost of inaction, proposal, decision. No jargon, no new numbers that do not appear later with evidence.

3. Scope. Page count sampled, categories reviewed, date range of data used, and one sentence on what the review is designed to support.

4. Exclusions. Written before scope. Explicit list plus the out-of-scope handling sentence.

5. Findings — technical. Table with severity, business impact, effort. Severity definitions printed above.

6. Findings — content and structure. Separate table. Same columns, different categories.

7. Open questions. What you could not determine, and what access or data would resolve it.

8. Phased plan. Three phases, each with a testable definition of done.

9. Timeline and assumptions. Working days from a trigger, review windows stated, assumptions that would change the price.

10. Pricing. Three options, one recommended, payment terms, scope-flexibility statement.

11. About. Half a page maximum. Similar engagement, method, named person.

12. Appendix. Methodology, timestamps, screenshots, raw exports, reproducible commands, and what you checked that passed.

If you build the document in that order, the executive summary writes itself, because by the time you get to it you have already made every decision the summary has to communicate.

The mistake that costs the most: treating the audit as free marketing

I want to be direct about this because it is the most expensive habit in the category. Doing a free full audit as a sales tactic does three things, and all three are bad.

First, it sets your price at zero for the most skilled part of the work. Clients are not irrational for concluding that the remediation is similarly negotiable.

Second, it attracts clients who are shopping rather than deciding. Someone collecting three free audits is not close to a decision, they are building a decision document out of other people’s labour.

Third, and least discussed, it corrupts your own findings. When the audit is a sales tool, there is quiet pressure to find something urgent and expensive. Once you notice that pressure in yourself, the honest-reporting habit is already damaged. A paid audit that concludes “your site is in good shape, here are three small things, no engagement needed” is a genuinely valuable product. A free audit that reaches the same conclusion has wasted everyone’s week.

If the goal is a low-friction entry point, a short fixed-price review is the right instrument: five pages, one week, a clear list of what it does and does not cover. It converts better than a free audit because the commitment is real but small, and it starts the relationship with an invoice rather than a favour.

How to run the audit that feeds the proposal

The proposal is only as good as the evidence underneath it, and most of the evidence comes from a smaller set of checks than people expect. Here is the sequence that produces the findings table without eating a week.

Step one: crawl and inventory. Get a complete list of indexable URLs, response codes, titles, and canonical targets. This alone surfaces more revenue-relevant problems than any single performance tool.

Step two: template sampling. Group URLs by template — homepage, category, product or post, checkout, contact. Run the technical checks against a representative sample of five to ten per template rather than every URL. Problems are almost always template-level, which means sampling finds them and full crawls mostly confirm them.

Step three: search data. Search Console for the last ninety days: queries, pages, click-through rate by position. This is where you find the pages that rank but do not earn, which is usually the most actionable finding in the entire document.

Step four: field performance. Real user metrics where available, lab metrics as a fallback. If you only have lab data, say so in the methodology — it changes how much weight a developer will give the number.

If you need a fuller example of what the structured review looks like end to end, including how the output is formatted for a client, this walkthrough of a subscription-free audit covers the same ground with different tooling.

Step five: manual read. Open the five most commercially important pages and use them as a customer would. This step finds things no crawler reports: a form that silently fails on one field, a shipping cost that appears only at the last step, a phone number that is an image.

The structured version of this list is in the workflow I use to review a hundred pages in a morning; the ordering above is what makes it produce a proposal rather than a spreadsheet.

Using a scanner without letting the scanner write the proposal

Automated tools are excellent at collection and terrible at interpretation. A scanner will tell you that fifty-one images are missing alt text. It will not tell you that forty-four of them are decorative, six are product thumbnails in a carousel that never renders on mobile, and one is the only image on the page that carries pricing information.

That distinction is the entire value of a human-written proposal, and it is also where clients can tell whether they paid for judgement or for a PDF export.

My rule: the scanner produces raw findings into a spreadsheet, then every finding gets one of three labels before it enters the proposal — real (confirmed and consequential), contextual (confirmed but not worth fixing in the near term, goes in the appendix with a reason), or false positive (dropped, and worth mentioning in the methodology that you triaged false positives, because it signals care).

If you run these checks repeatedly across a lot of sites, or across a lot of pages on one site, the collection side is worth automating properly. This is the problem space I built a desktop tool for: a scan that produces a structured findings list you can triage, with every finding independently re-checkable. The premise of the scanner I use for the collection step is the same as the premise of this article — the machine gathers, the person judges, and the proposal is where the judgement shows up.

Follow-up: what to do after the proposal is sent

Sending the proposal is the middle of the process, not the end. Three actions, in order.

Same day: a short message, not a chase. One paragraph naming the single most important finding, the recommended option, and the date the pricing holds. No summary of the document, no instructions to read it. The document exists; the message exists to make opening it a priority.

Day three: the finding, in public. Follow up with one concrete detail that is useful even if they never reply — a screenshot with an annotation, a specific query where they rank fourth with a two percent click-through rate. This is the follow-up that gets responses, because it gives before it asks.

Day seven: the honest close. “I have not heard back, which usually means either the timing is wrong or the priorities have moved. Both are fine. If the timing is wrong, when should I follow up? If the priorities have moved, I will close this out and you are welcome to come back to it.”

That message closes a surprising number of engagements, and it closes them forward rather than into silence. The clients who were never going to buy are released, which is good — they were consuming attention that belonged to the ones who will.

If they say yes, the proposal becomes the project brief. If you wrote testable completion criteria and explicit exclusions, the first two weeks of delivery are already defined. If you wrote a list of findings and a total price, you will spend those two weeks renegotiating scope. That difference is decided entirely at the writing stage.

What separates a proposal that closes from one that stalls

After enough of these, the pattern is clear enough to state plainly. Proposals that close share four properties, and none of them are about design or length.

They name a problem the client already suspected. The best audit proposals do not introduce a shock, they confirm a suspicion with evidence. Clients rarely pay to learn that something unexpected is wrong; they pay to have something they already felt quantified well enough to justify a budget line.

They put a price on inaction. Even a rough, correctly-caveated number changes the conversation from “should we spend this” to “what happens if we do not.” A proposal with no cost-of-inaction section leaves the client comparing your fee against zero, which is a comparison you lose.

They make phase one small and visible. The first commitment should be under two weeks and produce something the client can point at. Long first phases are where enthusiasm dies, because there is nothing to show anyone in week three.

They are honest about what they do not know. An open-questions section, a false-positive note, and a “checked and passing” list all do the same thing: they demonstrate that the report was written by someone with a standard, not a sales target. In a category full of inflated findings, calibrated scepticism is the differentiator.

None of this requires a designer, a proposal tool, or a subscription. It requires an audit you actually ran, a document built back to front, and the discipline to write the exclusions before you write the scope.

The short version

Build the findings first and the words last. Write the executive summary for someone who will never open Search Console. Put every finding in two sentences, one for the implementer and one for the budget holder. Write the exclusions before the scope, and price three phases so the client can buy part of the work. Keep the audit paid, keep the findings ungated, and keep the appendix boring and reproducible.

Then follow up on day three with something useful and close honestly on day seven. The document is the easy part once the evidence is real — and the evidence is the only part a client cannot produce without you.

If you are building the review itself rather than the proposal, start with the site audit checklist and work outward from there. If you are trying to work out how to price the review before it exists, the the same pricing logic I apply to service retainers covers the numbers and the reasoning behind them.

Once the proposal is signed, the follow-up question becomes a delivery question: the client handoff checklist is what makes the last week of the project feel as organised as the first.