---
title: "What We Check Before Taking On A Client Blog, And Why We Sometimes Say No"
url: https://hostmy.blog/what-we-check-before-taking-a-client-blog/
date: 2026-09-10
modified: 2026-09-03
lang: en
author: "Aditya Sharma"
description: "We turned down four of the last eleven blogs that asked for our help. Here is the audit we run first and the five things that end the conversation."
categories:
  - "Hosting"
image: https://hostmy.blog/wp-content/uploads/2026/09/hmb-card-1851-1024x538.jpg
word_count: 1619
---

# What We Check Before Taking On A Client Blog, And Why We Sometimes Say No

We turned down four of the last eleven blogs that asked us to look after them.

That is a higher refusal rate than most service businesses would admit to, and it is deliberate. A care plan is a fixed monthly fee against variable work, which is the same trade underneath [every managed hosting bill](/managed-wordpress-hosting/). Take on a site whose real condition you have not looked at and you are not selling a service, you are buying a liability.

So before quoting anything, we spend about two hours with read access to the site and the server. Here is what that audit covers, what changes the price, and the five findings that end the conversation.

## The audit, in the order we run it

Read only access to WordPress admin and, where possible, the host. No changes.

| Check | What we are looking for |
| ----- | ----------------------- |
| Plugin and theme inventory | Count, abandoned plugins, anything not from a known source |
| Update lag | How far behind core, plugins and PHP are |
| Core file integrity | Modified core files, unexpected files in `wp-includes` |
| Theme provenance | Parent theme edited directly, no child theme |
| Backup state | Whether one exists, where it lives, when it was last restored |
| Error log | Volume and repetition of PHP warnings and fatals |
| Database health | Autoloaded option size, table bloat, orphaned meta |
| Response time and LCP | On article templates, not the homepage |
| Redirect inventory | Where the rules live, how many, whether they still fire |
| Search Console access | Coverage errors, manual actions, indexing state |
| Email delivery | SPF, DKIM, whether the site sends through a real service |
| User accounts | Dormant administrators, shared logins, old developer accounts |
| Server configuration | PHP version, memory, cron setup, object cache availability |
| Ownership of everything | Domain, host, registrar, DNS, analytics, and who actually controls each |

The last row is not technical and it is the one that has caused us the most trouble historically. More on that below.

Three commands cover a surprising amount of it:

`wp core verify-checksums --allow-root
wp plugin list --status=active --format=table --allow-root
wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto');" --allow-root`

`verify-checksums` compares core files against the official release. It takes seconds and it is the fastest compromise check available.

Fourteen read-only checks, and what each outcome means

Fourteen read-only checks, and what each outcome means

Inventory and update lag
plugins, theme, core, PHP

Integrity and provenance
core checksums, parent theme edited directly

Backup state
whether one exists and when it was last restored

Health signals
error log volume, autoloaded option size, table bloat

Delivery and access
email authentication, Search Console, dormant admins

Ownership of everything
domain, host, registrar, DNS, and who controls each

The audit is read-only and changes nothing. What it produces is a price, a plan, or a refusal, and the last row decides more of those than any technical finding.

## Three findings that raise the price rather than stop the deal

Most audits turn up problems. Problems are normal and they are usually why somebody is calling us. These three change the number without changing the answer.

**A large plugin count with real dependencies.** Forty plugins is not automatically bad. Forty plugins where six are abandoned and two are doing the same job is a month of careful untangling before routine maintenance is even possible, and [deciding what to remove without breaking the site](/wordpress-plugin-bloat/) is most of that month. We quote that as a separate piece of work rather than absorbing it into a monthly fee.

**No redirect inventory.** If the site has been through a restructure and nobody can tell us where the redirect rules live, that is a day of archaeology. It is worth doing, and the reason it is worth doing is in [the migration checklist](/how-to-migrate-wordpress-site/), where a lost set of redirect rules costs weeks of traffic.

**A backup that has never been restored.** This is close to universal, so it barely counts as a finding. We test a restore during onboarding regardless, and the reason that is a hard requirement rather than a nice to have is in [our piece on proving a restore works](/wordpress-backup/).

## The five findings that end the conversation

**Nulled or pirated plugins.** This is the clearest no. Nulled premium plugins are the most reliable source of injected backdoors we encounter, and beyond the security question, we are not going to run a business on somebody else's stolen licence. The path back is straightforward: buy the licences, or replace the plugins, and then we can talk. Two of the four refusals were this.

**An active compromise where the owner wants maintenance instead of remediation.** Finding a compromise is not a refusal. Refusing to deal with it is. If the site has injected spam links or an unknown administrator account, that is a remediation project first, priced separately, and only then a care plan. Signing a maintenance contract over an active compromise means inheriting a breach and being blamed for it in month three.

**Somebody else holds the keys and does not want to hand them over.** A previous developer who controls the registrar, or an agency that owns the hosting account and is being replaced acrimoniously. We have been in the middle of that and it is unwinnable. Until the client controls their own domain, DNS and hosting, there is no version of this where we can do the job. Getting that ownership sorted out is genuinely good advice even if the client then hires somebody else.

**Expectations we cannot meet.** If the conversation includes a guaranteed uptime percentage with penalties, or a traffic target, we say no. Nobody can honestly guarantee uptime on infrastructure they do not own end to end, and a maintenance service does not control what gets published. Better to lose the deal in week one than to fail in month four.

**Heavily modified core.** Rare now, still happens. Edited files in `wp-includes`, a hardcoded change to how users are authenticated, a custom patch somebody applied in 2017. Every core update becomes a merge conflict on a system with no version control. We will quote the work to unwind it, and we will not quote a monthly fee over the top of it.

## The one we should have said no to

Worth including because it is why the refusal list exists at all.

Picture a blog with 140 active plugins, a directly edited parent theme, and an owner who is pleasant and pays quickly. The audit finds all of it. Quote a normal care plan anyway, because you want the work and have told yourself the tidy up will take a week.

The tidy up takes about thirty hours across three months. Every plugin update needs a staging test, because there is no way to predict which of the 140 will interact. The edited parent theme makes theme updates impossible without reverse engineering somebody else's changes. Three separate incidents in the first quarter, each one absorbed under the fixed fee.

The owner is never the problem in that story. The estimate is. Somebody absorbs the difference, and it is the provider, for a quarter, because nobody wanted an awkward conversation in week one.

What changed after: the audit result now goes to the client in writing before any price is discussed, including the parts that make us look expensive. If the site needs 30 hours of remediation, that is in the document, and they can hire anybody they like to do it.

## What week one looks like when we do say yes

Assuming the audit is clean enough, onboarding is fixed and takes about six hours.

- Take a full backup and immediately restore it into a throwaway environment to prove it works.

- Bring PHP, core, plugins and themes current, in batches, on staging first.

- Match staging to production exactly, including PHP version. We learned that one the hard way, described in [the failures that run for weeks unnoticed](/what-breaks-when-nobody-is-watching/).

- Set up monitoring: response time, disk, database size, certificate expiry, cron due dates, 404 rate.

- Move outbound email to a real sending service and fix SPF and DKIM.

- Remove dormant administrator accounts and disable the admin file editor, following [the hardening that does not fight the host](/wordpress-security/).

- Document the redirect inventory in a file that lives outside the server.

- Check the technical SEO plumbing: sitemap, canonicals, robots.txt, structured data.

That last item now includes AI crawler access, because a meaningful share of the referrals we see on client blogs comes from AI assistants rather than a results page. We install [RankReady](https://wordpress.org/plugins/rankready-ai-llm-seo/) for it, a free WordPress AI SEO plugin from the WordPress.org directory. It runs alongside Rank Math, Yoast, AIOSEO or SEOPress without conflicting with them, which matters because every blog we take on already has one of those and we are not going to rip it out. Setup is about five minutes and it covers llms.txt, Markdown endpoints and crawler rules. It is plumbing, in the same category as the sitemap check above.

Then the monthly rhythm starts, which is itemised honestly in [the recurring upkeep, itemised](/wordpress-maintenance-service/).

## Why we tell people the answer before we quote

The audit is the same work whether or not the deal closes, and we hand over the findings either way. Some of the sites we turn down go and fix the problems themselves. Some of them come back later and become customers.

That is not generosity. A written audit that says exactly what is wrong is the only honest basis for a fixed monthly price, and it protects us as much as it protects them. Every care business that gets into trouble does so by quoting a number before looking at the site.

If you want that audit run on your own blog, that is a thing we do, and you are under no obligation to hire us afterwards.

The question worth asking yourself first: if somebody ran `wp core verify-checksums` on your site this afternoon, are you confident about what it would say?