1. Is everything you say still accurate?

Team members who've left. Services you no longer offer. Prices from two increases ago. Hours that changed. Awards from 2019 presented as current.

Read your homepage, about page, and service pages as if you were a customer. Fix what's false first — it's the only category on this list that actively misleads people.

2. Do all your links still go somewhere?

Internal links to pages you deleted, external links to companies that were acquired or shut down, a partner logo linking to a domain now serving something unrelated. Run a crawler over the site and check the list.

3. Does the contact path work end to end?

Submit your own form. Confirm delivery. Call your own listed number. Email your own listed address. Check that the address on your contact page is where you actually are.

4. Are the backups real?

Not "are backups configured." Restore one, somewhere that isn't production, and confirm the result is a working site with current content.

5. Who controls the domain?

Registrar, renewal date, payment method, and whether the account is accessible to someone still with the business. Five minutes, and it's the difference between an inconvenience and a catastrophe.

6. What's installed that shouldn't be?

Plugins, integrations, and third-party scripts. For each, name what it does for the business this year. Remove what fails the test — including deactivated plugins still sitting on disk.

7. How fast is it, on a phone, on cellular?

Not on your laptop on office Wi-Fi. Check field data if you have it. Compare against last year: speed decays as content and tags accumulate, and the decay is invisible until it's severe.

8. What does Search Console say?

Coverage errors, pages dropped from the index, a sudden fall in impressions for a page that used to perform, security notices. Most of this arrives by email to an address nobody reads, so look directly.

9. Is anything expiring?

SSL certificate, domain, premium plugin licences, service subscriptions, API keys and integration tokens. Put every renewal date in one calendar with a reminder a month ahead.

10. Does it still describe the business you have now?

The hardest one. Businesses change faster than their websites — new focus, better clients, a service that became the main event.

If your site describes what you were doing three years ago, everything else on this list is maintenance on the wrong building.

What to do with the results

You'll finish with a list. Sort it: broken things, false things, slow things, everything else. Do the first two categories this month. Schedule the third. Ignore the fourth until next year.

Then put a note in the calendar for twelve months' time, because the single greatest predictor of a healthy website is that somebody looks at it on purpose, on a schedule.

What it does

Schema markup is a machine-readable description of what's on a page. It doesn't tell a search engine anything a careful reader couldn't work out; it removes the guesswork.

The payoff is eligibility for rich results — star ratings, FAQ dropdowns, event dates, product prices, recipe times. Eligibility, not entitlement. You can implement it perfectly and see nothing.

Where it reliably earns its keep

LocalBusiness, for anyone with a physical location. Name, address, phone, hours, geographic coordinates. It reinforces everything your Google Business Profile says, and consistency between the two matters.

Product, for anything sold online. Price, availability, and rating in the results is the difference between being clicked and being scrolled past.

Article / BlogPosting, for content. Author, publish date, headline. Modest, but it makes the date visible, which affects whether people click on anything time-sensitive.

FAQPage, where you genuinely have questions and answers. Handle with care — display of FAQ rich results has been restricted repeatedly, and stuffing invented questions onto a service page to farm result space is exactly the behaviour that caused the restriction.

Event, Recipe, JobPosting, Course — highly effective for the specific businesses they apply to, and irrelevant for everyone else.

BreadcrumbList, which replaces the raw URL in the result with a readable path. Small, cheap, universally applicable.

Where it doesn't help

On a generic service page with no rich result type, structured data changes nothing visible. It's still fine to include the basics — it's cheap and it clarifies your site's structure — but it isn't a lever.

It also won't rescue a thin page. Structured data describes content; it doesn't create it.

The rules that keep you out of trouble

Mark up what's on the page. Ratings shown in schema and nowhere on the page are a violation, and penalties for it are applied.

Don't invent reviews. Self-serving review markup on your own site is against the guidelines and is checked.

Keep it accurate as things change. Prices, hours, and availability in schema that no longer match reality are worse than no schema at all — a visitor who arrives to find the price wrong has been actively misled.

Validate it. Both the schema validator and the rich results test, on real URLs, after launch.

The practical minimum

For a typical service business: Organization and LocalBusiness sitewide, BreadcrumbList on inner pages, BlogPosting on articles. That's an afternoon, it's stable, and it covers essentially all the available value.

Everything past that is specific to what you sell — and worth doing precisely when it is.

The members area with four members. The event calendar last updated in 2023. The three-step quote calculator that everyone abandons at step two and calls instead.

Each is code that must be maintained, updated, secured, and worked around forever.

Why "yes" is the default

Saying yes is easier for everyone in the moment. The client feels heard, the agency gets paid, the developer has clear work. The cost lands later, distributed across every future change, invisible to the person who approved it.

That's a bad incentive structure, and the antidote is a habit of asking a few questions before agreeing.

The questions

What are you actually trying to do? Nearly every feature request is a proposed solution in disguise. "We need a chatbot" is often "people ask us the same four questions and we're tired of answering." That's an FAQ, not a chatbot — and it can ship this week.

How will we know it worked? If nobody can name a number that should move, there's nothing to evaluate, which means it will never be removed either.

What is the manual version? Almost anything can be done by a person before it's automated. If the manual version isn't worth someone's time, the automated version probably isn't worth building.

Who maintains it? Content-driven features need a content owner. An event calendar without someone whose job includes updating it becomes a public record of neglect.

What does it cost if we don't? Sometimes the honest answer is "nothing measurable," and that's a fine reason to skip it.

How to say no well

Not "no." Say what you'd do instead, and why.

"We could build the calculator — it's about three weeks and it'll need maintaining as your pricing changes. Or we could put your three most common package prices on the page this week and see whether people still call for a quote. If they do, the calculator's clearly worth building and we'll know what to put in it."

That version is a service. It gives the client a cheaper path to the same outcome and a real decision to make. In our experience most people take the smaller option, and a good share of the time it turns out to be sufficient.

The ones to say yes to quickly

Anything that removes friction from a customer contacting you. Anything that fixes something broken. Anything that makes the site faster or more accessible. Anything the owner needs in order to update their own content.

Those compound. Features rarely do.

The annual subtraction

Once a year, list every feature on the site and check what it's been used for in the last twelve months. Remove what isn't earning its keep.

It is the least popular meeting of the year and reliably the most valuable one. A website that does five things well beats one that does twenty things adequately — and it costs far less to keep alive.

That problem is drift. Someone adds a page, picks a slightly different blue, uses a heading one size larger, adds a button with rounded corners that don't match. Repeat over two years and the site looks like four websites in a trench coat.

The six decisions

1. Colours — five of them. One dark for text, one brand colour, one accent, one light background, one border grey. Written down as hex values, not "our blue."

Five is enough for almost any business site. More than that and consistency stops being achievable by a non-designer.

2. Two typefaces, maximum. One for headings, one for body. Sizes fixed at a handful of steps — say five — rather than typed in per page. Most amateur-looking pages are amateur-looking because of typographic inconsistency, not colour.

3. Spacing on a scale. Pick a base unit and use multiples of it. Everything spaced at 8, 16, 24, 32, 48 looks deliberate. Everything spaced at 13, 27, 31 looks accidental — even when nobody can say why.

4. One button style, with one variant. A primary and a secondary. Same shape, same padding, same radius everywhere. The number of sites with six button styles is remarkable, and every one of them got there honestly.

5. Image treatment. Do photos have rounded corners? Is there a consistent aspect ratio for cards? Are illustrations flat or shadowed? One choice, applied throughout.

6. Voice. Not visual, but part of the same problem. Do you say "we" or "the team"? Is it "Contact Us" or "Get in Touch"? Sentence case or Title Case for headings? Write the answers down.

Where to keep it

One page. In whatever the business already uses — a shared doc is completely fine. Hex codes, font names and sizes, spacing values, a screenshot of each button, three sentences on voice.

The elaborate version, with tokens and component libraries, is genuinely valuable for a company shipping a product with a design team. For a service business, it's a document that gets made once and never opened.

The test that proves it works

Ask someone who isn't a designer to add a new page to your site.

If they can do it without asking what colour to use, without inventing a new heading size, and without the result looking foreign — the system is working. If they can't, the system isn't written down clearly enough, no matter how thorough it feels.

What it's actually buying you

Consistency reads as competence. A visitor can't articulate why one site feels professional and another feels improvised, but they respond to it, and they respond in the first few seconds.

Six decisions, one page. That's the whole system.

That uncertainty is the single largest unmanaged risk on most small business websites — bigger than the plugin vulnerabilities everyone worries about.

Own your domain, personally

Not your agency. Not your web developer. Not an employee's personal account.

The registrar account should be in the business's name, with the business's email, and someone in the business should be able to log in today. Everything else — hosting, DNS, email — can be moved if you control the domain. Lose control of the domain and you lose all of it at once, with no technical recourse.

Check three things this week: who the registrar is, whether renewal is on auto-renew with a card that hasn't expired, and whether the contact email is one somebody still reads.

The three records

A / AAAA — where your website lives. Point it at the wrong address and the site is gone. Point it at an address you no longer control and someone else's content can appear on your domain. When you leave a host, this is the record to change, and the old host account should not be cancelled until the change has fully propagated.

MX — where your email goes. The classic disaster: a developer migrates the website, recreates DNS from scratch at the new provider, copies the web records and forgets the mail records. The site works perfectly. Email stops, silently, and it can be a day before anyone realizes inbound mail has been bouncing.

Before any DNS migration, export every existing record. All of them. Then compare afterwards.

TXT — who is allowed to send as you. SPF, DKIM, and DMARC decide whether your mail lands in an inbox or a spam folder. They also decide whether someone else can send convincing mail pretending to be you.

If your contact form emails stopped arriving after a host migration, this is nearly always why: the new server sends mail that your SPF record doesn't authorize.

The habits that prevent the bad day

• Lower TTL before a planned change, so a mistake takes minutes to undo instead of a day.
• Export the whole zone before touching anything. A text file, saved somewhere findable.
• Change one thing at a time and confirm it before the next.
• Never let the domain and the hosting be a single account you can be locked out of.
• Document it. Registrar, DNS host, who has access, and where recovery codes live. One page, kept somewhere the business owns.

Why this is worth an afternoon

Hacking is the risk everyone plans for. In practice, we see far more total outages caused by an expired domain, a lapsed card, an inaccessible registrar account after someone left the company, or a migration that dropped the MX records.

Every one of those is preventable with an hour of documentation and an auto-renewal you've verified.

Three years later the homepage loads code from fourteen different companies and takes six seconds to respond to a tap.

What you're actually taking on

Every third-party script is a dependency on someone else's infrastructure, executed on your visitors' devices with full access to your page.

That means:

• Their downtime is your downtime. A slow tag server can block your page from becoming interactive. It's not hypothetical — a single unresponsive third party has taken large sites down more than once.
• Their code runs on your main thread, competing with your own interface. This is the usual cause of a page that looks loaded but doesn't respond.
• Their privacy posture is now yours. Whatever they collect, they collect from your visitors, on your site, under your policy.
• They can change without telling you. A script you vetted in 2023 is not the script running today.

The audit

Open your tag manager and your page source, and list every external domain the page loads from. For each one, four questions:

1. What business decision does it inform? Not "it collects data" — what did someone do differently because of it?
2. When was that last true? Heatmap tools are the classic case: intensely useful for a fortnight, then loading for three years.
3. Does it need to load on every page? The chat widget probably doesn't belong on the checkout. The scheduling embed doesn't belong on the blog.
4. Does it need to load immediately? Almost nothing does.

In our experience roughly half the tags on a typical site fail question one or two.

What to do with the survivors

Defer them. Analytics can load after the page is interactive. Chat widgets can load on interaction — a lightweight button that fetches the real widget when clicked cuts hundreds of kilobytes for the 95% of visitors who never open it.

Scope them. Load the booking script only on pages with booking, the map only on the contact page.

Self-host what you can. Fonts especially. Self-hosted fonts are faster, more private, and immune to a third party's outage.

Set a budget. A hard limit on how much third-party weight the site carries, checked when someone asks to add another tag. Without one, the answer to "can we add this?" is always yes, and the cost is always invisible.

The uncomfortable conversation

The pushback is always the same: marketing needs the data, so the tags stay.

The reframe that works: those tags are being paid for in visitors. If the pixel that measures your conversions is slowing the page enough to reduce your conversions, it isn't a measurement tool — it's a tax.

Measure the page with and without. On most sites we audit, removing the dead tags is worth a second or more of load time, and nothing of value is lost — because nobody had looked at the data in two years anyway.

Where the leak actually is

Track a hundred enquiries through a typical small business and the pattern is consistent:

• A hundred people land on the contact page.
• Around twelve to fifteen start the form.
• Eight or nine finish it.
• Seven or eight are replied to at all.
• Three or four get a reply within a day.
• One or two become customers.

The biggest single drop is between landing and starting. The most fixable one is between submission and reply.

Notice that neither of those is a design problem.

Close the gap after submission first

Acknowledge instantly. An automatic reply that says what happens next and when. It costs nothing to set up and it stops the "did that even send?" doubt that sends people to a competitor's form ten minutes later.

Reply fast, for real. Response speed is the highest-leverage variable in the funnel. Same-day replies convert dramatically better than next-day, and next-day beats "sometime this week" by more than most owners expect.

Have a second touch. Most people who don't reply to your first message aren't gone — they got busy. One follow-up after a few days recovers a meaningful share of them. Two is fine. Eleven is harassment.

Route by urgency. "My site is down" and "I'd like a quote in the autumn" should not sit in the same queue in the same order.

Then reduce the friction before it

Ask for less. Every field is an exit. Three fields converts better than eight, essentially always.

Offer a lower-commitment option. Not everyone is ready to "request a quote." A checklist, a 15-minute call, an audit — a smaller yes captures people who'd otherwise leave without a trace.

Put the form where the intent is. Making someone navigate to a separate contact page loses people. The end of a service page is where someone has just finished being convinced.

Say what happens next, next to the button. "We reply within one business day" reduces the perceived risk of clicking more than any button colour ever has.

What you don't need

You don't need a marketing automation platform, an eleven-stage nurture sequence, or lead scoring. Not at this size. Those are answers to problems you get after you've fixed the above.

The measurement that keeps you honest

Count enquiries, count replies, and record the time between them. Three numbers, tracked monthly.

Most businesses discover their real conversion problem lives in the second and third numbers — which is good news, because those are fixed with a calendar reminder rather than a redesign.

Ranking third and being clicked is better than ranking second and being skipped.

Write for the moment of choice

Someone has just searched. They're scanning a page of near-identical blue links, and they'll give yours roughly a second.

They're deciding one thing: does this look like it answers my question? Everything about the description should serve that decision.

What works

Answer the search, immediately. If the query is "how much does a website cost," the first six words should be about cost. Not your company. Not your commitment to excellence.

Be concrete. Numbers, timeframes, prices, specifics. "Plans from $99/month, 24/7 support, no contract" outperforms "affordable, comprehensive website solutions tailored to your needs" every time — because one is information and the other is decoration.

Say what happens next. "See the checklist," "compare the three options," "book a 15-minute call." A description that implies a clear payoff gets clicked.

Match the page. If the description promises pricing and the page doesn't have any, you'll get the click and lose the visitor — and the resulting bounce isn't a signal you want to send repeatedly.

What doesn't

Keyword stuffing. Your company name at the front, where it takes space from the answer. Truncated sentences that run past the display limit mid-thought. Identical descriptions across dozens of pages — a genuinely common problem, and a strong signal that nobody has looked at the site in a while.

And leaving them empty, which hands the search engine permission to invent one from your page text. It sometimes does this well. It often pulls your cookie notice.

Length, practically

Aim for roughly 140–160 characters. The real cut-off varies by device and query, but the discipline that matters is putting the important part first — write it so it still works if the last third disappears.

The bit almost nobody does

Search engines frequently rewrite descriptions anyway, matching the snippet to the specific query. That's not a reason to skip writing them; it's a reason to make sure your page contains good sentences worth rewriting into a snippet.

Then check what's actually being shown. Search Console reports impressions and click-through rate per query. Find pages with plenty of impressions and a poor click-through rate — those are pages ranking well that nobody is choosing. Rewriting the description on your top twenty of those is one of the cheapest traffic gains available.

No new content. No new links. Just better copy in the thirty seconds where someone decides whether you're worth a click.

Here's what to look for.

The baseline: things that must happen

Updates, applied safely. Core, themes, and plugins — on a staging copy first, with a visual check afterwards, and a rollback path. Auto-updating everything on production is not maintenance; it's a coin flip performed monthly.

Backups, off-site, tested. Daily, retained sensibly, stored somewhere other than the server, and restored on a schedule so you know they work.

Uptime monitoring. Checked frequently, from more than one location, alerting a human who is awake. Monitoring that emails a mailbox nobody reads is monitoring theatre.

Security scanning. File integrity, malware, and known vulnerabilities in what's installed — plus somebody actually reading the output.

SSL and domain renewal tracking. Both expire. Both take a site down completely when they do. Both are entirely preventable.

The part that separates real plans from cheap ones

Someone answers. A defined response time, and a way to reach a person that isn't a ticket form that replies in three days.

Fixes are included, not just updates. The plugin update broke the layout — who fixes that, and is it billable? The answer to this question tells you what you've actually bought.

Small changes are included. A price change, a new team member, a seasonal banner. Most owners need a handful of small edits a month, and a plan that excludes them will feel expensive at exactly the wrong moment.

Performance is watched. Speed decays. New content, new tags, new plugins — someone should be noticing before your visitors do.

You get a report you can read. What was updated, what was found, what was fixed, what needs a decision. Not a 40-page automated PDF; a page a busy person will actually look at.

Questions worth asking before signing

• What happens if the site goes down at 2 a.m. on a Sunday?
• If we get hacked, is cleanup included, or is that a separate quote?
• Who owns the hosting account, the domain, and the code?
• Can I get a full export of everything, today, if I want to leave?
• What did you fix on my site last month? (Ask this after three months.)

That last question is the real audit. Plenty of maintenance plans are a standing charge for a monthly automated update and nothing else.

What it's worth

For a site that generates leads, maintenance is not a cost centre — it's the reason a bad week stays a bad week instead of becoming a bad quarter. The cost of one serious incident, in downtime and recovery and lost enquiries, typically exceeds several years of a decent plan.

The trick is making sure you're buying the plan and not the phrase.

Leaving is a legitimate decision. Losing your search traffic on the way out is not a required part of it.

Understand what you're actually leaving

Most builders store layout as shortcodes or serialized data inside the post content. Deactivate the plugin and your pages become a wall of bracket syntax. That's the lock-in — the content and the layout are the same field.

Any migration has to separate them: extract the actual content, rebuild the layout in whatever you're moving to, and never let the old data be the only copy.

The plan

1. Freeze and inventory. Stop editing. Export a full list of URLs with traffic, rankings, and inbound links from analytics and Search Console. This is your protection: it defines what must not break.

2. Prioritize. You almost certainly have a small number of pages carrying most of the value. Those get careful, hand-checked migration. The long tail can be batched.

3. Extract content cleanly. Pull the real text and images out with the builder still active, so nothing is trapped. Keep headings hierarchical — heading structure carries meaning and is frequently mangled by builders that style everything as a div.

4. Rebuild on staging. Full copy of the live site, migration done there, nothing touching production until it's verified.

5. Preserve URLs exactly. This is the single most important rule. If a URL can stay the same, it stays the same. Every URL you change is a redirect you have to maintain and a small amount of value you leak. Redesigning the URL structure "while we're in here" is how migrations lose 40% of their traffic.

6. Match the content, then improve it. Migrate first, optimize second. If you rewrite while you migrate and traffic drops, you won't know which change caused it.

7. Check the invisible things. Titles, meta descriptions, canonicals, structured data, image alt text, internal links. Builders generate a lot of this automatically, and it disappears silently when the builder does.

Launch and the two weeks after

Launch during a quiet window. Then:

• Crawl the new site immediately, looking for 404s and broken internal links.
• Submit the updated sitemap.
• Watch Search Console daily for a fortnight — coverage errors and crawl anomalies show up there before they show up in traffic.
• Compare traffic to the pre-migration baseline by page, not in aggregate. Aggregate hides the one important page that broke.

A small dip in the first fortnight is normal as pages are recrawled. A dip that hasn't recovered by week six is a problem to investigate, not to wait out.

What you get

Typically: page weight down by half or more, an editing experience that's genuinely simpler, and a site the next developer can read.

It's a real project — not a weekend. But it's the difference between owning your website and renting it from a plugin.

So let's translate.

What the score is actually measuring

A Lighthouse score is a weighted average of lab measurements taken on a simulated device on a simulated connection, on your machine, at one moment. It's a useful diagnostic and a terrible target.

Two things make it misleading as a goal. It's synthetic — your real visitors are on different devices and networks. And it's non-linear — going from 40 to 70 is a genuinely different experience; going from 90 to 100 is often invisible to every human being.

What to measure instead

Field data. What actual visitors experienced, from real-user monitoring or the Chrome UX Report. This is the number that reflects your business and the one search engines use.

Time to first meaningful content on a mid-range phone on cellular. Not the score — the seconds. Everyone in the room understands seconds.

The bounce curve by load time. If your analytics can segment by speed, this is the most persuasive chart in the building. It reliably shows that visitors who waited longer left more.

The translation that lands

Take real numbers off the site. Suppose 8,000 organic sessions a month, a 2.4% enquiry rate, and an average job worth $2,400.

Now: your mobile pages take 5.8 seconds to become useful, and mobile is 61% of your traffic and converting at less than half the desktop rate.

The question stops being "should we spend on performance" and becomes "what is the mobile gap costing per month." That's a question a business owner can answer, and the answer is usually much larger than the cost of the work.

Where the time actually goes

For most business sites, in this order: oversized images, third-party scripts, render-blocking CSS and fonts, and unnecessary platform overhead. That's the whole list, and the first two are usually more than half the problem.

Which is worth saying out loud, because it means the work is finite. Speed optimization is not an endless money pit — it's a handful of specific fixes with a clear end point.

What "good enough" looks like

For a small business website: something meaningful on screen within about two seconds on a mid-range phone on 4G, interaction that responds immediately, and no layout that jumps around while loading.

Past that, keep the discipline rather than chasing the number. Set a page weight budget, check field data monthly, and don't let a new marketing tag quietly add 400 KB in November.

Nobody has ever chosen a supplier because their Lighthouse score was 100. Plenty have left because a page took six seconds.

Here are the five that matter, and what each one has to accomplish.

1. The homepage

Job: tell a stranger what you do, who for, and what to do next — within about five seconds.

Not your history. Not your values. What you do, in words your customer would use. Then the proof (numbers, names, a testimonial that says something specific), then one obvious next step repeated down the page.

The commonest homepage failure isn't ugliness. It's that after fifteen seconds a visitor still can't tell what you sell.

2. The service page — one per service

Job: convert someone who has a specific problem.

One page per thing you sell. Not a single "Services" page listing nine offerings in bullet form — that page ranks for nothing and converts nobody, because it speaks to everyone.

Each should cover: the problem in the customer's language, what you actually do about it, what it costs (or the range, or why it varies), what happens after they enquire, and who it's not for. That last part builds more trust than any amount of praise.

3. The about page

Job: make it feel like real people.

It's usually one of the most visited pages on any service business site, and usually the most neglected. People check it before they call, because they want to know who they'd be dealing with.

Real photos of real people. How long you've been doing this. Something specific enough that a competitor couldn't paste it onto their own site.

4. The proof page

Job: answer "has this worked for someone like me?"

Case studies, results, client names — whatever form your evidence takes. Specific beats glowing every time. "They were great to work with" persuades nobody; "load time went from 6.1 seconds to 1.4, and enquiries rose by a third over the following quarter" persuades everybody.

Even two short case studies outperform a wall of anonymous five-star quotes.

5. The contact page

Job: make it effortless, and set expectations.

Every method you actually monitor. A form that asks for the minimum. A clear statement of when you'll reply. If you have a physical location, a map and parking notes. If you have hours, the real ones.

And test that it works, from a phone, this month.

The order to fix them in

Contact first — it's fastest and it's where the money leaks. Then your best-selling service page. Then the homepage. Then proof. About last, because it matters but rarely blocks a sale.

Once those five are genuinely good, you've earned the right to think about the blog. Before that, publishing content to drive traffic toward pages that don't convert is just paying to fill a leaky bucket faster.

First, what is the blog for?

There are really only three reasons a business blog earns its keep.

To rank for things people search. Then cadence is irrelevant and coverage is everything. Twelve genuinely good pages answering twelve real questions will outperform a hundred thin posts, permanently.

To give existing prospects a reason to trust you. Then depth matters. Someone deciding whether to hire you reads three or four things, and they should be your best three or four.

To stay in front of an audience that has already opted in. This is the only one where frequency is the point, because you're building a habit on the other end.

Most business blogs are trying to do the first, publishing as if they're doing the third, and achieving neither.

The case for daily

Daily is a strong choice under specific conditions: you have a real audience, a subject with genuine daily surface area, and someone whose actual job includes it.

What daily buys you is compounding — an archive that keeps earning, a reason for people to check back, and a body of work that becomes the reference in your niche. What it costs is relentless: five posts a week is 250 a year, and quality decay is the default outcome without a system.

The case for weekly

Weekly is where most businesses should live. It's frequent enough to build the habit on both ends, slow enough that each piece can be worth reading, and survivable through a busy quarter.

The case for "when we have something"

Fine for a business whose website isn't a marketing channel. Genuinely fine — a practice with a complete Google Business Profile and six solid service pages does not need a blog. Publishing nothing beats publishing filler.

What doesn't work is the middle: four posts in January, silence until August, two in September. That pattern reads as abandonment, which is worse than never having started.

What makes a cadence hold

A backlog. The reason cadences collapse is that Tuesday arrives and there's nothing to write. Work a few weeks ahead and one bad week stops being a break in the chain.

Ideas captured continuously. Every client question is a post. Every explanation you've given twice is a post. The idea shortage is a capture problem, not a creativity problem.

A format that repeats. Not templates — recognizable shapes. The checklist, the audit, the "here's what we actually do." Constraints make writing faster.

Permission to be short. A useful 400-word answer published today is worth more than a 2,000-word guide that never ships.

The number, if you want one

Weekly, for at least six months, before you judge it. If you can genuinely do daily with a system behind it, daily compounds faster — and everything above is the system, not the ambition.

That gap is not pedantry. A backup is a claim; a restore is a fact. Until you've done the second, you have a claim.

The ways backups fail quietly

They're on the same machine. A backup stored on the server it's backing up covers exactly one failure mode — you deleted something — and none of the others: the server dies, the account is suspended, the host has an incident, ransomware encrypts the volume.

They only cover files, or only the database. A WordPress site is both. Restore one without the other and you have a working site full of missing content, or content with nowhere to live.

They're too shallow. Seven days of retention sounds reasonable until you discover a corruption that started three weeks ago. Something monthly, kept for a year, costs almost nothing and has saved more than one client.

They silently stopped. The plugin was deactivated during an update. The destination's credentials expired. The disk filled. Nobody was told, because failure notifications go to an address nobody reads.

They contain the problem. If a compromise happened before your oldest backup, every restore point includes the backdoor.

What a real backup policy looks like

The old rule still holds: three copies, two kinds of storage, one of them somewhere else. For a website that usually means the live site, an automated backup on the host, and an off-site copy in independent storage.

Add to that:

• Automated, not remembered. Anything requiring a human to think about it monthly will lapse within a year.
• Monitored. A successful backup should be as noisy as a failed one — or at least, a failure must reach a person.
• Retained on a schedule you chose deliberately. Daily for a fortnight, weekly for a quarter, monthly for a year is a sane default.
• Encrypted, if it contains customer data, which it does.

The test

Once a quarter, restore to somewhere that isn't production — a staging site, a local environment, anywhere.

Then check the things nobody checks: does the site load, are the images there, does the database include last week's content, do the forms work, is the plugin configuration intact?

Time it. "We can be back within two hours" is a very different conversation with an anxious client than "we think we have backups somewhere."

The two numbers worth agreeing on

How much data can you afford to lose? That sets backup frequency. A brochure site can lose a day; a store taking orders cannot lose an hour.

How long can you afford to be down? That sets what you need standing by. If the answer is "an hour," a nightly archive in cold storage isn't enough on its own.

Most businesses have never been asked either question, and both turn out to be surprisingly easy to answer once someone does.

Four habits fix most of that.

1. Decide what a good month looks like before you look

Write it down first: "We want 40 form submissions and at least 12 from organic search." Then open the dashboard.

Do it the other way around and you'll find a metric that went up and call it a result. Every dataset contains a number that improved. Choosing it afterwards is how businesses spend three years feeling good about traffic that never became revenue.

2. Compare like with like

Traffic is seasonal, weekly, and lumpy. Month-over-month comparisons in a business with any seasonality are close to meaningless.

Compare to the same period last year. Compare 28-day windows rather than calendar months, so you're not counting a different number of weekends. And when something spikes, check the date against your own calendar before crediting your marketing — a lot of "campaign successes" are a mention on someone else's newsletter.

3. Segment before concluding

Aggregate numbers hide everything interesting. "Conversion rate 2.1%" is one number covering a mobile experience converting at 0.8% and a desktop one at 4%.

The three splits that pay for themselves immediately: device, source, and new versus returning. Nearly every real insight we've found for a client lived in one of those three, invisible in the total.

4. Know which numbers are lies

Bounce rate on a page whose job is to answer a question is not a failure signal. Someone found the answer and left satisfied — same data as leaving frustrated.

Time on page is measured badly almost everywhere and is heavily distorted by anyone who leaves a tab open.

Direct traffic is a bucket of things the tool couldn't attribute — dark social, apps, mistyped campaign links, privacy tooling. A big direct number often means broken tagging, not brand strength.

Rankings for terms nobody searches are decorative. Check the volume.

The numbers that survive scrutiny

For a small business site, there are usually about five:

1. Qualified enquiries per month.
2. Cost per qualified enquiry, by channel.
3. Organic sessions to your top ten commercial pages.
4. Conversion rate by device.
5. Speed of first response to an enquiry.

Everything else on your dashboard is context for those.

A monthly review that takes twenty minutes

Look at the five numbers against last year. Note anything that moved more than 20%. For each, write one sentence saying why you think it moved and how confident you are. Then pick one thing to change, and only one.

That last constraint is the important one. A review that produces eleven action items produces zero completed actions — and next month you'll be reading the same numbers, wondering the same things.

Here's the actual rule: alt text is what someone hears instead of seeing the image. Write it for that person and the SEO takes care of itself.

The question to ask

Not "what is in this image?" but "what is this image doing here?"

The same photograph gets different alt text depending on its job:

• Illustrating a case study → "The Fulton Dental waiting room after the 2025 refit"
• Demonstrating a product feature → "The scheduling calendar showing three appointment types side by side"
• Purely decorative, next to text that already says it → alt=""

That last one matters. An empty alt attribute is a real, correct answer — it tells a screen reader to skip an image that adds nothing, rather than announcing "image, dot, hyphen, decoration" in the middle of a sentence.

What good alt text sounds like

Read the page aloud, substituting your alt text for each image. If the sentence still makes sense and nothing important vanished, you've written it correctly.

Some practical guidance:

• Be specific, be brief. A sentence, usually. If it needs a paragraph, the information belongs in the page text.
• Don't start with "image of." The screen reader already announced it's an image.
• Include text that appears in the image. If your infographic contains numbers, those numbers must be in the alt text or a caption — otherwise they simply don't exist for a portion of your audience.
• Describe function for anything clickable. For an image that is a link or a button, the alt text is what the control does: "Download the 2026 pricing sheet," not "PDF icon."
• Charts need their finding, not their appearance. "Bar chart" tells nobody anything. "Site speed improved from 4.2 to 1.6 seconds after optimization" is the actual content.

Where it overlaps with search

Search engines do read alt text, and it's how images get found in image search. But the version that ranks and the version that serves a blind visitor are the same version, because both want an accurate description of what's actually there.

Keyword stuffing fails both audiences and, these days, isn't even effective at the thing it was cheating at.

The part people forget

Alt text isn't only for screen readers. It's shown when an image fails to load — a slow connection, a broken path, a blocked CDN. On a bad mobile connection, alt text is what a sighted visitor gets too.

Getting an existing site fixed

Audit by traffic. Start with your most-visited pages, do the images that carry meaning, mark the decorative ones empty, and stop. You don't need to reach a hundred percent to be dramatically better than you were — and a site where the important images are described properly is worth far more than one where every image has a keyword glued to it.

What a redesign actually is

A redesign is a simultaneous change to your information architecture, your URLs, your copy, your visual identity, your templates, and often your platform — all at once, all going live on the same day.

Every one of those is a variable. Change them together and you cannot know which one helped and which one hurt. What you do know is that traffic will move, and the historical odds say down before up.

Why the redesign is being requested

In our experience the real reasons are, roughly in order:

1. Someone new has arrived and wants to make a mark. Legitimate motivation, poor diagnostic.
2. The site feels dated to the owner — who looks at it every day and is the least representative visitor there is.
3. It's hard to update, so it hasn't been updated, so it looks neglected. That's a platform problem wearing a design costume.
4. The business changed and the site describes a company that no longer exists. This one is real.
5. It isn't converting. Also real, but almost never solved by a new look.

Only two of those five call for a redesign.

What usually works better

Fix the pages that matter. Your homepage, your top three service pages, and your contact page account for most of your value. Rewriting those is a fortnight, not a quarter.

Make it fast. Speed improvements are measurable, uncontroversial, and don't risk your rankings.

Fix the funnel. Form fields, response time, and clarity of the next step move revenue more reliably than any visual change.

Update the content. A site that says something true and current about your business reads as modern regardless of when the design was made.

When to actually redesign

• The business genuinely does something different now.
• The platform is a real constraint — you can't publish without a developer.
• Mobile is broken in a way that can't be patched.
• Accessibility is failing and the templates can't be fixed.
• You've done the cheap work and the numbers still say the structure is wrong.

That last point matters most: earn the redesign with evidence first.

If you're going to do it, do it safely

Map every URL to its new destination before you start. Keep your top-performing pages' content largely intact — you can restyle without rewriting what already ranks. Launch in stages if the platform allows. Measure against a baseline you recorded beforehand.

And expect a dip. A well-run redesign recovers in six to twelve weeks. A badly run one is still explaining itself a year later.

The uncomfortable summary

The site you have, made fast, current, and clear, beats the beautiful site you'll have in five months roughly as often as not — and it costs a fraction as much. Sometimes the right answer is a redesign. It's just a smaller fraction of the time than anyone selling redesigns will tell you.

This is good news, because images are the easiest thing on a website to fix.

The four mistakes, in order of cost

Uploading straight from the camera. A phone photo is 4,000 pixels wide and several megabytes. Displayed in a 600-pixel-wide card, every one of those extra pixels is downloaded and thrown away.

Serving one size to everyone. A phone doesn't need the desktop hero. srcset has been well supported for a decade and remains widely unused.

Old formats. The same photograph at the same visual quality is typically 25–35% smaller in a modern format. That's a free third off the largest thing on the page.

Loading everything immediately. Images below the fold compete for bandwidth with the content someone is actually looking at. loading="lazy" is one attribute.

What good looks like

For a typical content image:

• Resized to roughly the maximum size it will ever display, at 2× for sharpness on dense screens.
• Compressed — quality around 80 is visually indistinguishable from 100 for photographs and dramatically smaller.
• Served in a modern format with a fallback.
• width and height attributes set, which also fixes layout shift.
• loading="lazy" unless it's the hero, which should be eager and preloaded.

Do that consistently and page weight typically falls by half without a single visible change.

The hero image deserves its own paragraph

It's your Largest Contentful Paint. It is the single most important file on the site.

It should be the smallest file you can make it while still looking good, preloaded, never lazy-loaded, and ideally not a photograph of a handshake. Test it on a mid-range phone on cellular, which is where most of your visitors actually are.

Where SVG belongs

Logos, icons, illustrations, and diagrams should be SVG: a few kilobytes, sharp at any size, and stylable in CSS. Exporting a logo as a 200 KB PNG is a habit worth breaking.

Photographs should never be SVG, and an SVG exported from a design tool without cleaning frequently carries more junk than the equivalent PNG. Run it through an optimizer.

Doing it to a site that already exists

You don't need to reprocess a decade of uploads. Sort by page traffic, fix the images on your top twenty pages, and you'll have captured most of the available benefit in an afternoon.

Then put a rule in place so it stops recurring: images get processed before upload, or by the platform on the way in. Otherwise you'll be doing this again next year, which is how most sites end up here in the first place.

Cleaning it is the easy part. Here's the rest.

What actually happens in a cleanup

Contain first. Take the site offline or into maintenance mode. Every hour it's live and infected is more damage to your search presence and more risk to visitors.

Get a forensic copy before you change anything. Files and database, preserved. If you clean first and investigate later, you've destroyed the evidence that tells you how they got in.

Find the entry point. Access logs around the first sign of trouble, file modification times, recently added admin users, scheduled tasks that shouldn't exist. The infection is a symptom; this is the diagnosis.

Replace rather than clean, wherever possible. Core files, themes, and plugins get reinstalled fresh from source instead of picked through. Cleaning malware out of a file by hand is how you leave a backdoor behind.

Then the database and uploads, which have to be cleaned by hand because they contain real content. Injected scripts in post content, rogue admin accounts, PHP files hiding in the uploads folder.

Why "just restore the backup" often isn't enough

The instinct is reasonable and frequently wrong for one reason: you usually don't know when the compromise happened. Restoring to last Tuesday restores the backdoor if it arrived the Tuesday before.

Worse, a restore rolls back the vulnerability fix along with everything else — so the site comes back exactly as exploitable as it was.

Restores are part of the answer. They aren't the answer alone.

The part that matters most

Once it's clean, the question that determines whether you're doing this again in six weeks: how did they get in?

In our experience it's nearly always one of four things.

1. An out-of-date plugin with a publicly known vulnerability. Overwhelmingly the most common.
2. A weak or reused admin password, with no second factor.
3. A compromised local machine — the credentials were stolen from someone's laptop, not from the server.
4. Shared hosting cross-contamination, where a neighbouring site on the same account was the way in.

Afterward

Rotate every credential — admin users, database, FTP/SSH, hosting panel, and any API keys stored in the site. Force a logout of all sessions. Turn on two-factor for every administrator.

Then request a review through Search Console if you were flagged, and watch for reinfection for a fortnight. Reinfection within days means you missed the entry point, and it's back to the logs.

The cheaper version of this article

Keep things updated. Use unique passwords with two-factor. Take backups you have tested restoring. Remove plugins you don't use.

That's most of it. Security work is boring, and the boring part is the part that works.

Here's ours, in order.

Before anyone touches DNS

Every page loads. Click through the whole sitemap. Not a sample — all of it.

Every form submits, and the mail arrives. Test each form, to each recipient address, and confirm receipt. Then check spam.

Redirects are mapped. If this replaces an existing site, every old URL that has traffic or links needs a destination. Export the old sitemap, crawl it, and map one to one where you can. This is the single most commonly skipped step and the most expensive one to skip.

Analytics is installed and firing. On the new site, with the right property. Verify a real pageview appears.

Search Console is ready for the new property, with the sitemap prepared for submission.

Content and legal

• Placeholder text: gone. Search the database for "lorem", "TODO", and the theme author's name.
• Contact details correct on every page they appear.
• Copyright year current, and generated rather than typed.
• Privacy policy and terms present and reachable from the footer.
• Cookie or consent notice, if you need one, actually working rather than just present.

Technical

• robots.txt does not disallow the entire site. Staging sites are usually blocked; the number of launches ruined by shipping that block to production is not small.
• No noindex left on production pages. Same reason.
• HTTPS everywhere, with HTTP redirecting, and no mixed content warnings.
• 404 page exists, is styled, and offers a route back.
• Favicon and social preview image present — check how the homepage looks pasted into a message.
• Titles and meta descriptions unique per page.

Performance and accessibility

• Field-representative test on a mid-range phone, not a laptop.
• Images sized and compressed; no 3 MB heroes.
• Keyboard navigation reaches everything interactive, visibly.
• Colour contrast passes on body text and buttons.

The switch itself

Lower DNS TTL a day ahead. Take a final backup of both old and new. Switch during your quietest hours, not at 5 p.m. on Friday. Then watch: uptime, error logs, and form submissions, for the first hour and again the next morning.

The week after

Submit the sitemap. Watch Search Console for crawl errors and for old URLs turning up as 404s you missed. Check analytics against the old site's baseline — a 30% traffic drop after launch is almost always a redirect problem, and it's fixable if you catch it in week one rather than month three.

Why it's written down

Every item on this list is here because it went wrong once. That's the only real qualification a checklist item needs.

The map pack is the whole game

For local searches, the three results in the map box get the overwhelming majority of clicks. Everything below is fighting for scraps. So the goal isn't "rank for chiropractor" — it's "be one of three."

Three things drive that: proximity (which you can't change), prominence, and relevance. The last two are entirely within reach.

Your Google Business Profile is the highest-leverage asset you own

It's free, it takes an afternoon, and most practices half-fill it and never return.

Complete every field. Real categories — the primary category matters more than any other single setting. Real hours, including holiday hours. Real photos, taken this year, of the actual place. Services listed individually. A description that reads like a person wrote it.

Then post to it. Weekly is plenty. It's an underused surface and activity is visible to the ranking system.

Reviews, honestly

Volume, recency, and responses all matter. Most practices ask for reviews at the wrong moment — in an email three days later, when the goodwill has faded.

Ask at the counter, at the moment someone says thank you. Make it one tap. And reply to every review, including the bad one, in a tone you'd be happy to have quoted back to you — because that reply is read by everyone deciding whether to call.

One page per service, one page per town

This is the part that requires actual work and is therefore where the advantage is.

If you offer six services, six pages — each one substantive, each one written for someone with that specific problem. If you draw patients from four towns, a page for each is worth having, provided it's a real page about serving that town and not a template with the name swapped in. The swapped-template version is transparent to both readers and search engines and does more harm than good.

The technical minimum

You don't need much, but you do need this:

• Name, address, and phone identical everywhere — site, profile, directories, down to whether it's "Suite" or "Ste."
• LocalBusiness schema on the site with the same details.
• A fast mobile site. Local search is overwhelmingly on phones, often on cellular, often in a car park.
• A clickable phone number in the header. It sounds trivial. Watch the call volume.

What to ignore

Buying citations in bulk. Directory listing services that submit you to 400 sites nobody visits. Anyone selling guaranteed rankings. And, mostly, blogging — for a single-location practice, a complete profile and six solid service pages will outperform a year of weekly posts.

A realistic timeline

Profile work shows movement in weeks. Service pages take a couple of months to settle. Reviews compound quietly and never stop mattering.

It isn't fast, but it's finite — and unlike most marketing spend, the work stays done.

Here are the nine we strike first, and what to write instead.

1. Solutions

"Innovative solutions for modern business." What is being solved? A solution with no problem attached is a noun doing nothing.

2. Innovative

Nobody describes themselves as uninnovative, which makes the word worth exactly zero bits of information. Show the innovation; don't claim it.

3. Seamless

Usually means "we hope you won't notice the seams." If the experience is genuinely smooth, describe the thing that used to be rough.

4. Empower

"We empower businesses to..." Whatever follows is the actual claim. Delete the first two words and the sentence gets stronger every time.

5. Leverage

A verb that appears exclusively in sentences that would be clearer with "use." It signals a company writing for other companies rather than for a person.

6. Passionate

Everyone says it, and it's unfalsifiable. Replace it with the evidence you'd use to prove it — twenty years, eight thousand sites, a support line that's actually answered.

7. Best-in-class

Which class? Judged by whom? An unbacked superlative reads as noise, and worse, it invites the reader to start doubting.

8. Transform

"Transform your digital presence." Everyone's transforming. The word has been used so heavily in marketing copy that it now means "change, but vaguely."

9. Your journey

The customer isn't on a journey. They're on a website at 11 p.m. trying to find out if you can fix their broken checkout by Thursday.

What to write instead

Answer these three, in this order, in plain language:

1. What do you do? Not the category — the actual service.
2. Who is it for? Naming your customer specifically loses you nobody who was ever going to buy.
3. Why you? One concrete, checkable claim.

"We maximize websites for high-growth entrepreneurs" works because you can picture it, it names a customer, and it makes a claim you could hold someone to. It isn't clever. Clever is a distant second to clear.

A test worth running

Cover your logo and read your headline to someone outside your industry. Ask them what your company does.

If they say "something with computers?", the headline isn't finished. If they say "they look after websites for busy business owners" — that's the whole job, done.

Here's what we actually compare.

What "unlimited" means

Unlimited storage, unlimited bandwidth, unlimited sites. All three are limited. The limits live in the acceptable use policy, they're usually expressed as CPU seconds or inodes, and you find out about them when your site is throttled during your best traffic day of the year.

Ask for the real number. A host that will tell you is a host worth considering.

Whether you share a machine with a thousand strangers

Cheap shared hosting means your site's performance depends on the behavior of neighbors you can't see. One badly written site on the same box can take the rest down with it, and "the server is busy" is not a problem you can fix from your end.

This is the single biggest driver of "the site is randomly slow sometimes," and no amount of optimization on your side addresses it.

The backup story, in detail

Every host says they back up. The questions that matter:

• How often, and how far back does it go?
• Is the backup stored on the same machine as the site? (If yes, it isn't a backup.)
• Can you restore it, right now, without a support ticket?
• Have you ever actually done that?

A backup you can't restore yourself, at 2 a.m., is a comfort blanket rather than a recovery plan.

Staging that isn't an afterthought

The ability to clone your live site, break it, fix it, and push the result live — without downtime and without manual database surgery — changes how carefully you can work. Hosts that don't offer it are asking you to test in production.

What happens when you need a human

Read support reviews rather than support promises. "24/7 support" describes availability, not competence. The relevant question is whether the person who answers can read a log, and whether the answer to a hard question is investigation or a link to a knowledge base article you already read.

The migration test

Before you commit, find out how you'd leave. A host that makes it easy to export everything — files, database, DNS — is a host that expects to keep you on merit. One that doesn't has told you something.

The honest summary

For a brochure site with modest traffic, cheap shared hosting genuinely is fine, and we'll say so. The moment your website is load-bearing for revenue — bookings, orders, leads that matter — the difference between $12 and $40 a month is the cheapest insurance in the business.

The expensive part was never the hosting. It's the day the site is down and nobody can tell you why.

The average site we inherit runs 31 active plugins. In our experience about nine are doing something the business would miss.

Step 1: List everything, with dates

For each plugin: version installed, last update from the author, active installs, and whether it's premium with a lapsed license.

A plugin the author hasn't touched in two years is not "stable." It's abandoned, and it's running with full database access.

Step 2: Sort into four piles

Load-bearing. Forms, e-commerce, memberships, booking. Break these and the business stops. These get updated carefully, on staging, and never on a Friday.

Doing something small that could be done in ten lines. "Insert header script," "hide the admin bar," "add a favicon." Each is a full plugin with a full attack surface, an update cadence, and a settings page, doing something a snippet does. These get consolidated.

Duplicates. Two caching plugins. Three SEO plugins where one was configured and two are half-configured and fighting. A security plugin and a firewall doing overlapping work. Duplicates aren't just waste — they interact, and the interactions are the bugs nobody can reproduce.

Nobody knows. Deactivated-but-installed, or active with no visible effect. Vendor plugins from a service that was cancelled in 2021.

Step 3: Check what they're loading on every page

This is the part clients find most surprising. A plugin used on one contact page frequently loads its CSS and JavaScript on every page of the site — including the homepage nobody has a form on.

Ten plugins doing this is a second of load time and a hundred kilobytes of script for no benefit. Conditional loading, or the right plugin, fixes it.

Step 4: Remove, don't deactivate

A deactivated plugin still sits on disk. Its files are still reachable by URL. Vulnerabilities in deactivated plugins have been exploited plenty of times.

If you're not using it, delete it. If you're nervous, take a backup first — which you have, because you tested your backups. (You did test your backups.)

What the numbers usually look like

On a typical audit: 31 plugins in, 12 to 16 out. Page weight down 20–40%. One or two genuine security issues found. And a site that a person can reason about, which matters more than any single metric.

The rule going forward

Every new plugin answers three questions before it's installed: what does it do that we can't do without it, who maintains it, and what breaks if it disappears tomorrow?

Most requests don't survive question one.

Here's how contact forms leak, roughly in order of how much money each one costs.

1. It doesn't deliver

This is not a subtle conversion problem. This is mail that goes nowhere, and it's alarmingly common — a hosting migration changes the sending address, SPF and DKIM stop matching, and every submission quietly lands in a spam folder or gets rejected outright.

Test it monthly. Send a real submission and confirm a real human received it. Better still, log submissions somewhere that isn't email, so a mail failure isn't a data loss.

2. It asks for too much

Every field is a chance to leave. "Phone number" costs you people who aren't ready to be called. "Company size" costs you everyone who isn't sure. "How did you hear about us?" costs you people who genuinely can't remember.

Ask for what you need to reply. That's usually a name, a way to reach them, and what they want. Everything else can be asked in the reply, when they've already committed.

3. It's an interrogation, not an invitation

Compare "Submit" with "Send my message." Compare a form headed "Contact Us" with one headed "Tell us what you need — we'll come back within one business day."

The second version answers the question every visitor is actually asking, which is what happens after I click this? Uncertainty is the friction.

4. It fails rudely

Error handling is where forms lose people they'd already won. If someone fills in six fields, hits submit, and the page reloads with everything blank and a red banner at the top, a good portion of them are gone.

Validate inline. Keep what they typed. Say what's wrong next to the field that's wrong.

5. It's unusable on a phone

Half your traffic, usually more. Check: does the keyboard cover the field being typed in? Does the email field bring up the email keyboard? Can you tap the submit button without zooming? Does autofill work, or did custom field names break it?

Fixing autofill alone measurably lifts completion. Use standard name and autocomplete attributes and let the phone do its job.

6. Nothing happens fast enough afterward

The form worked, the email arrived, and someone replied four days later. That lead is cold and probably already talking to a competitor.

Speed of first response is the highest-leverage number in the whole funnel, and it doesn't require touching the website at all. An auto-acknowledgment that sets an expectation buys you a day. Actually replying inside that day wins the work.

Where to start

Test delivery today. Cut one field this week. Rewrite the button label in the next five minutes. In that order — because a beautifully optimized form that doesn't deliver mail is just a beautifully optimized way to lose customers.