Some days start with a neat task list. This wasn’t one of them.
I got into work on Monday morning and wondered if it’d be interesting (to me or others) if I logged what I got up to that day. So I did just that, and this post is the outcome. If you’ve ever wondered what your website manager actually does for the fee they charge you, this is for you. I can’t say this is a typical day, or that it showcases all my skills, but it’s what happened on that particular Monday.
Over the course of Sunday I’d been getting website monitoring alerts for one of my retainer clients and had been keeping an eye on them. The pattern looked very familiar to me. The frequency and duration of the downtime were consistent with a hosting company throttling resources, which can cause a four- or five-minute outage.
I sat down at my desk, logged in and found one retainer client’s website showing a traffic increase of more than 31,000%. Not the good kind of spike you get from a successful campaign, or a nice bit of press coverage. I know this because I asked the client that question specifically to help give some context to my troubleshooting. This was strange traffic, from places that don’t normally visit the site, and enough of it to push the server past its resource limits.
Sometimes real-time events lead my day instead of my calendar.
The plan had been ordinary maintenance work: updates, checks, reporting, a few improvements. Instead, the first question became: is this just weird traffic, or has a vulnerability been found and shared online?
It is noticing that something looks wrong, taking it seriously, and calmly
This is the bit of website management that’s hard to explain until you see it happening. It’s not glamorous. It’s not a redesign. It’s not a new feature anyone’s going to get excited about.
It’s noticing that something looks wrong, taking it seriously, and calmly working through the possibilities before it becomes a bigger problem. And to be honest, that’s a lot of the role.
The morning started with evidence, not panic
When a site is under unusual pressure, and once we’ve taken measures to alleviate that pressure, the next job isn’t to leap to the first conclusion that’s suggested. It’s to work through the evidence. I find fairly routinely that it isn’t normally the first thing you think it is. It’s always something more obscure, less obvious.
I checked error logs, import logs, analytics, installed plugins, themes, and anything that might have become a security risk. I updated themes and plugins where needed, partly to close possible security holes and partly to remove obvious weaknesses from the equation.
Some platforms let you reinstall all free plugins, which can be a useful way to replace files that may have been changed maliciously. But it still may not remove the cause.
From the outside, that can look like routine maintenance. Someone logs in, runs some updates, checks a few screens, and moves on. In practice, it’s more proactive than that.
Could this be connected to something I changed?
You’re asking: has anything changed recently? Is this plugin still safe to run? Is the traffic pattern harmless, hostile, or somewhere in between? Could this be connected to something I changed, something the client changed, or something completely external? In this instance I checked all my task tracker sheets for things that I could’ve done. I also checked site logs to see if the client had changed anything without involving me.
That judgement matters because a WordPress site isn’t a static object. It’s a collection of code, services, users, integrations, hosting limits, analytics, plugins, forms and content. When something unusual happens, you need someone who understands enough of the history to know where to look first.
It isn’t just whether the site is technically “up to date”. It’s whether someone knows what normal looks like, spots when something is abnormal, and has enough context to respond sensibly.
A possible security incident changed the investigation
Later, a possible lead emerged that changed how I needed to think about the traffic issue. I used AI-assisted research to check the list of installed plugins against vulnerabilities reported around the time the traffic surge began.
It turns out a reputable and paid-for plugin on the site may have been connected to a reported supply-chain incident around the same period as the instability. I’m being careful with the wording here, because this isn’t the same as saying the site was compromised. That still needs evidence, but it does change the classification of the work.
There’s a big difference between “the site is receiving odd traffic” and “the site may have briefly received a compromised plugin update through legitimate update channels.” The first is a performance and traffic investigation. The second needs to be treated more like incident response and my approach becomes more forensic until compromise can be ruled out.
Preserve evidence before doing broad cleanup.
A website can be patched now and appear normal, yet still need investigation. Updating plugins to clean versions may replace the affected files, but it doesn’t automatically undo anything that code may have done while it was active or remove other malicious files that may have been hidden away elsewhere.
At this point, maintenance moves beyond what people expect. The job becomes evidence gathering, risk reduction and calm decision-making because you have to know when a problem deserves a more serious lens.
That’s the work clients often pay for without ever seeing the detail. The methodical investigation before the presented conclusion and fix. The boring checklist that might save a much worse conversation later.
A browser-specific problem needed a different kind of testing
With the high-traffic site no longer getting throttled by the host, it became a monitoring task while another client issue needed attention.
Some users in an online community platform were reporting that they couldn’t access content that should be available to them. The same kind of approach was used. Gather evidence, look for common denominators, test and consider “what kind of problem is this?”
Was it a permissions issue? A plan limitation? A recent platform change? A browser issue? Something specific to the app?
A quick meeting with the project lead helped test the issue on Apple devices, because I don’t use Apple equipment day to day myself. That’s a small but important detail. If you can’t reproduce the environment yourself, you still need to coordinate testing properly or you need to acquire the right testing environment.
A quick meeting with the project lead helped test the issue
A pattern started to emerge. Chrome worked. Safari on macOS and iOS failed. The mobile app also failed on iPhones. There was still a possible complication because the test devices were running public beta versions of Apple’s operating systems, but the evidence was useful enough to identify a short-term workaround using Chrome instead of Safari. Not a complete fix, but a usable workaround that helps reduce the number of frustrated platform users.
Real support work is often less about having the perfect answer immediately and more about isolating variables: what works, what fails, for whom, on what device, in which browser, under what conditions.
By late morning, I’d written a detailed support ticket and submitted it to the platform providers. The moderator who raised the issue had been updated and they helped manage the community response. The site owner had been updated. The task tracker and bug tracker were being updated so the issue was trackable and shareable.
Once the technical issue is understood, the work becomes communication, traceability and keeping people calm. No one wants a vague “we’re looking into it” if there’s a better answer available.
Expectations are high. Stakeholders need to know what’s been tested, what the current workaround is, who’s been contacted, and where the issue is being tracked.
By lunch, I was uncovering layers of legacy website problems
Later in the morning, I moved on to an ecommerce website on a maintenance plan.
The site had recently been migrated, and I was running updates and security scans. Because the site had a history of poor performance, this morning’s other issues made me look a bit closer for any anomalies and signs of inherited mess.
Previous work by less experienced contractors appeared to have duplicated files and structures in places they shouldn’t be. I often see this, where someone installs WordPress to the wrong folder and you get a tonne of duplication of files in the wrong places. That sort of thing doesn’t usually announce itself with a dramatic error message. It just sits there, making the site harder to maintain, harder to understand and sometimes harder to trust because directory contents don’t look like they should. (We tend to know what files should be in a directory).
Cleaning it up isn’t a quick job. It needs to be done carefully, unpicking the botched installation from the valid one. Imagine, if you will, someone chucking a packet of short grain rice into a bucket of long grain rice and mixing them up and then having to separate them again.
Then a smaller issue appeared: the map in the footer wasn’t displaying properly. It wasn’t a critical fault, but for an ecommerce business with a physical shop, it still mattered. A broken map affects usability, undermines trust and may prevent customers from finding the premises. That can lead to lost sales, as well as making the business look less credible when part of its website isn’t working properly.
We can measure that in lost sales.
The cause turned out to be malformed legacy code inside a theme content block. The Google Maps iframe URL had been damaged, combining the site domain with the Google Maps URL into a non-existent address. There were also some unused and mismatched CSS rules hanging around.
The fix was simple once the cause was clear: replace the broken embed with a cleaner map iframe, use the correct URL, add a proper title for accessibility, and keep it responsive.
Then I went for a run
At about half eleven, I paused to feed the dogs and go for a run before lunch. That might sound like a break from the working day, but I’m not sure it is. Not completely.
When you work on your own, especially across several support and consultancy roles, your attention is part of the operating system. If that gets overloaded, the quality of your judgement drops.
The run helped and I came back feeling better for it. I’d been out in the countryside, seen butterflies, a red kite hunting on the wing, so many flowers, blackberries, sloes, and all the small signs that the season’s moving on towards Autumn.
Exercise and detaching from your work location matters because technical work is also cognitive. You’re holding several problems in your head, switching context, making judgement calls, and trying not to turn every small uncertainty into panic. Going and doing something else allows the subconscious time and space to keep working on the problems while you get the dopamine and restoration that being in nature brings.
Work isn’t just technical. It’s also cognitive.
A lot of problem-solving happens away from the screen. Stress drops and thoughts settle. The next step often becomes clear once you stop staring at the problem. The only issue is having to stop running every ten minutes to email yourself the latest amazing idea you had.
So yes, feeding the dogs and going for a run sits in the middle of this article about website management. Because that’s part of a real working day too.
A day in the life of a solo digital continuity partner isn’t just tickets, logs, plugins and bug reports. It’s also managing energy and headspace so there’s enough clarity left to make good decisions for my clients.
In the afternoon, client support meant buying an iPhone
In the afternoon, I bought an iPhone 14 as a dedicated test device. It’s slightly odd when buying an iPhone counts as client support, but here we are. That decision came directly from the morning’s browser issue and from the general problem of unreliable viewport simulation.
Browser developer tools and responsive previews are useful. But quite honestly, I’ve just had too many discrepancies between simulated and real-world behaviour. Software-based device testing doesn’t always reveal actual behaviour across actual devices, operating systems, browsers and hardware. Sometimes you just need the device you’re testing for in your hand.
Sometimes you just need the device you are testing for in your hand.
So now my testing setup includes an iPhone, not that I particularly desire a drawer full of devices. It’s because diagnosis becomes easier when you limit the number of variables you’re working with.
If a client or their users are seeing a problem on iOS or Safari, simulation only gets you so far. Physical hardware gives better evidence and if enough of your day to day work uses those devices, you should probably have them to hand.
This is one of the hidden costs of providing technical support. The tools, devices, subscriptions, monitoring services, testing environments and accumulated context all matter. They aren’t always visible in the final invoice line, but they’re part of what makes the service reliable.
Client work wasn’t the only work
Not every part of the day was client delivery. At one point, I checked one of my new mailing lists and saw that someone had signed up.
That first subscriber to a list may look small from the outside. But when a list’s been empty until now, one subscriber changes everything. It stops being a someday marketing idea and becomes a live relationship with a real person waiting at the other end.
That creates a new responsibility: the follow-up experience now needs to be worth their trust.
The follow-up experience now needs to be worth their trust.
So the work shifts again. From website incident response, platform troubleshooting, ecommerce maintenance, to business development. The next job is to create some drip content for the mailing list so the first subscriber, and the next ones after them, receive something useful and structured.
This is one of the realities of solo consultancy. You’re not only doing the work. You’re also building the machine that brings in future work and those two things can collide on the same day.
Strategy looked like turning something off
Later, I checked analytics performance for an ads customer. We’d been discussing their enquiry volume for a specific service they sell.
We discussed whether we could pause paid activity for keywords that were already performing strongly in organic search, then redistribute the saved budget to other priorities. That’s a PPC and SEO overlap question, rather than a simple ads performance review.
It’s easy to assume ads management is always about doing more. More keywords. More campaigns. More spend. More optimisations.
It is easy to assume ads management is always about doing more.
But sometimes the useful question is do we still need to pay for traffic we’re already earning organically?
That doesn’t mean the answer is automatically no. Paid and organic results can support each other, and there are plenty of cases where protecting visibility is sensible. But it’s worth testing.
If organic search is already doing the job, paid spend might be better reduced, paused, or redirected somewhere it can make a bigger difference. It also means checking whether an old strategic decision is still valid.
The day ended where it started
By late afternoon, I returned to the site with the suspicious traffic surge. The earlier mitigation appeared to have helped and server resource usage was back within acceptable limits.
That’s the moment where it’d be tempting to say ‘fixed’ and walk away, but stabilising the site isn’t the same as understanding what happened.
So the next layer was timeline reconstruction. I checked uptime monitoring to understand when the issue started. The pattern appeared to begin a few days before the worst of the instability. I then looked back through the work log for that date to see whether any work, updates, changes, or issues might have contributed.
If nothing obvious appears in the work log, the next step is to ask the client whether anything changed around that date, or shortly beforehand.
This is the methodical side of maintenance work. Stabilise first. Then investigate what changed.
Stabilise first. Then investigate what changed.
As part of tightening the site back up, I also added security reporting to my own email address so I could receive the same alerts as the client. I have my own monitoring services, but it’s useful to know exactly what information reaches the client, and when.
It’s a small change, but it improves the support relationship. If a client raises a concern about a security alert, I’m not relying only on forwarded messages or second-hand context. I can see the alert, understand the pattern, and respond from the same information.
Support often requires taking positive action to put yourself in the client’s line of sight.
I also carried out user account administration on the retainer site. That’s another quiet risk area. Security isn’t only about plugins, firewalls and server resources. User accounts matter. Access matters. Roles matter. Dormant accounts matter, especially on a site where multiple contractors and service providers get involved and don’t perhaps have great security hygiene.
AI-supported work needed oversight too
The last notable task of the day was updating my AI agent instructions in Notion.
That may sound like a completely different category of work, but it fits the same pattern. In practice, this is closer to maintaining an internal process document, checklist, or staff handbook than simply “prompting an AI”.
If the instructions are vague, outdated, or based on older tool capabilities, the agent may still sound helpful while actually doing the job badly. That’s quite a dangerous combination.
A dangerous combination. Confident output, weak alignment.
This is the part of AI-supported work that doesn’t always make it into the exciting demos. AI agents aren’t magic employees. They’re living documents and systems that need managing as the work and the models themselves evolve.
That might sound like a slightly strange note to end the day on, but it fits. Whether it’s a website, a support process, an ad account, a testing setup or an AI agent, the job is often the same: keep it accurate and aligned with reality.
The common theme was continuity
Looking back over the day, there wasn’t a single grand project.
The day moved from a suspicious traffic surge, to a browser-specific video issue and platform support, to ecommerce maintenance, analytics checks, security admin, and even buying an iPhone as a test device. Somewhere in the middle, I went for a run, checked on my own marketing, updated an ads campaign, and ended the day updating AI agent instructions. Not exactly one clean project, but very much a real working day.
That might sound scattered, but the work was all connected by the need for continuity.
A lot of professional website work isn’t about big dramatic launches. It’s about keeping systems stable, useful, safe, understandable, and aligned with business needs.
None of this is especially glamorous.
Sometimes that means incident investigation. Sometimes it means testing or cleanup work, but it almost always requires judgement and a sanity check on whether yesterday’s assumptions still hold.
None of this is especially glamorous, but it can be very enjoyable. I mean, who doesn’t like detective work? But it’s the work that keeps things from falling apart and for small teams that especially matters.
The real risk isn’t usually one dramatic failure. It’s the slow accumulation of neglected details and decisions that nobody has reviewed since they were first made. A good website partner notices those things.
Then they do something about them.
