The first 30 days of a care plan decide whether the client thinks of you as a vendor who sends invoices or a partner who keeps the site healthy. Most of the work is unglamorous: access, baselines, backups you have actually tested, and one report the client can understand. Here is the sequence, in order, with the reasoning behind each step.
Days 1 to 3: get access and take stock
Do not touch anything until you know what you are looking after. Collect hosting access, DNS or registrar details, the WordPress admin, and any third-party logins the site depends on: email service, payment gateway, analytics, CDN. Put them in a password manager with the client's site name, not in a spreadsheet and not in email.
Then inventory the site. Record the WordPress version, PHP version, active theme, plugin list with versions, and which plugins are premium with licences that will expire. Note who the licences are registered to. Renewals fail more often than they should because the licence is tied to a former developer's email address.
Ask two questions the client will not volunteer. What on this site makes you money or generates leads? And what has broken before? Their answers define your priority pages, your update caution level and your alert thresholds. A site whose booking form is the business gets different treatment from a brochure.
Days 3 to 7: baseline everything
You cannot show improvement, or prove you did not cause a problem, without a starting point. Capture it now, before you change anything.
- Backups: run a full backup, store one copy on the server and one in offsite storage you control, then restore it to a staging copy. A backup you have not restored is a hope.
- Performance: record load time and the main speed metrics for the homepage and two key pages.
- Security: run a vulnerability scan and note known issues in installed plugins and themes.
- Visuals: take reference screenshots of the priority pages on desktop and mobile.
- Uptime: set up monitoring on the homepage and on the page that matters most, such as checkout or booking.
This is also when you find the ugly things. An abandoned plugin, a site running an end-of-life PHP version, an admin account belonging to someone who left in 2021. Write them down without drama. You will present them as a plan, not a scare.
Days 7 to 14: fix the risk, not the taste
Resist the urge to redesign. The goal in week two is to remove the risks that could turn into an incident.
Update what is safe to update, using a restore point first and checking the priority pages afterwards. Remove plugins that are inactive, and replace ones that are abandoned or have known vulnerabilities. Delete or downgrade unused admin accounts, turn on two-factor authentication for the admins who remain, and check that login is not exposed to unlimited attempts.
Anything that needs a client decision or extra budget, put in a short list with a recommendation and a price. Do not fix it silently and bill for it, and do not leave it unmentioned. If a plugin needs replacing and the replacement costs $200 in licences, say so and let them approve.
For a fuller view of what belongs in the recurring scope, our maintenance checklist breaks down what clients actually expect to pay for.
Days 14 to 21: set the rules of engagement
By now you know the site, so you can write the agreement precisely. Tell the client how updates work, when they are applied, and whether they want approval on some or all of them. Give them one way to reach you for problems, and tell them what response time to expect.
That last point deserves care. If clients email your personal address, ring your mobile and message you on social media, support turns into a fog. Point them to a single channel, ideally a help desk where each request becomes a ticket with a status. Then make it easy: a magic link that opens the ticket portal without a password removes the excuse for emailing instead.
Also agree what is out of scope. Small text edits, new pages and plugin configuration changes are common grey areas. Decide whether they are included, capped at a monthly allowance or billed separately, and put it in writing.
Days 21 to 30: the first report and the first conversation
The first report is the most important one you will send, because it sets the client's expectation of every report after it. Keep it to one page. Include what you found on day one, what you fixed, what is still open with your recommendation, and the current state of backups, uptime, updates and security.
Write it for a person who does not know what PHP is. "Your site was running a version of PHP the vendor no longer supports, and we moved it to a supported one on the 12th" beats a table of version numbers. Add a single line saying what you plan to do next month.
Then have a short call or exchange. Not a sales pitch, a check-in. Ask what they have noticed, whether anything has changed in the business, and whether any page has become more important since the audit. That conversation is where upsells come from, because you are responding to something they said rather than pitching.
What to track
A rough measure of whether your onboarding works: at day 30, can you answer yes to each of these for every new client?
- Do I have every credential and licence recorded in a shared vault?
- Has a backup been restored successfully from offsite storage?
- Does the client know how to contact me and what to expect back?
- Have they received a report they read?
If the answer is no for any, that is your first task on day 31.
Where this leaves you
Onboarding is mostly repetition, which is a reason to write it down as a checklist and run it the same way every time. Access first, baseline second, risk reduction third, rules and reporting last. WPClientHub gives each site a health score plus backups, scans and uptime checks from the first day, so the baseline step is mostly clicking through rather than assembling tools. WPClientHub is free for 3 sites if you want to try this on a real client site: onboard your next client.