Professional website maintenance services

Most support work does not begin with a site we made. It begins with one built by an agency that stopped answering, or by a developer who left, and the first task is not a fix. It is working out what we have become responsible for.

That starts with access, and access is always incomplete. The hosting account is in a former employee's name. The domain sits with whoever registered it in 2014. The analytics property belongs to a contractor's personal address. The code exists in exactly one place. The server. Before anything is changed, all of it is listed, moved into accounts the client owns, and written down in one document. Companies tend to discover they do not own their own domain at the worst possible moment.

Then an inventory, because nothing can be supported that cannot be seen: platform and version, components and their update status, how code reaches the server if it reaches it at all, where backups go and — the part nobody has tested — whether they can be restored. A backup nobody has restored is a belief, not a backup. We restore one into a scratch environment before calling the site covered.

What comes back is a list in two halves. Things that threaten the site: an unpatched version, a component abandoned by its author, no way to undo a bad change. And things that are merely inherited awkwardness: an odd theme structure, copied code, a plugin doing what fifteen lines would do. The first half gets dates. The second waits. The second gets repaired when we are already in that file for another reason, because rewriting somebody else's working code on principle is how a support budget disappears in a quarter.

Only then does the routine begin — updates on a schedule with a staging step, monitoring for uptime and certificates, and a monthly note saying what was done and what comes next.

A checkout returning a 500 error and a footer link pointing at the wrong page are both bugs. Treating them the same way is how a two-minute fix waits behind a queue while a real outage is triaged at the pace of a typo. Severity gets decided in advance, in a document anyone can point to during an incident. Three questions settle it. Does the issue block a transaction? Does it hit every visitor or a slice of them? Is there a workaround? A P1 gets a person immediately and a status update on a clock. A P4 goes into the next sprint. Without that line drawn ahead of time, every report arrives urgent — which means nothing is.

A library three major versions behind is not a cosmetic problem. It is the reason a security patch cannot be applied without a rewrite, because the patched version dropped an API the codebase still calls. Staying current works as a habit, not a project. Read the changelog before merging. Run the existing test suite against the new version in a branch. Ship minor and patch bumps on a routine cadence, so no single upgrade carries two years of breaking changes at once. The upgrades that go wrong are almost never the ones done often. They are the ones postponed until a security notice forces the issue and three unrelated breaking changes land in the same afternoon.

The first two weeks on an undocumented handoff are not spent writing code. They are spent reading git history to see who touched what and why. Tracing which environment variables the app actually reads, and which are dead. Writing a smoke-test suite for the paths that would be expensive to break, before touching anything. Skipping that to start fixing tickets is how a support engagement introduces its first regression in week one, on a system it does not understand yet. A structural map — what calls what, what is load-bearing, what is dead weight — is the real deliverable of a takeover. It produces zero visible features.

A CVE announcement for a widely used library does not mean patch immediately regardless of what breaks. It means triage exposure first. Is the vulnerable code path even reachable from outside? Does the fix require a version bump with its own breaking changes? Is there a config-level mitigation that buys time for a proper upgrade? Sites that patch only reactively, after a scanner or a client flags something, run with a known gap for as long as it takes someone to notice. A subscribed changelog and a monthly patch window close that gap before an audit finds it.

A synthetic check pinging the homepage every five minutes confirms the server responds. It says nothing about the checkout flow, the search endpoint or the login form. Real user monitoring closes that gap by watching actual page loads and transactions instead of one synthetic probe. That is how a payment gateway broken on a single browser gets caught in minutes — rather than surfacing three days later as a drop in completed orders nobody connected to a deploy. Alert fatigue is the failure mode on the other side. A monitor tuned to fire on every blip trains the team to ignore it, which is worse than no monitor at all.

An automated nightly backup that completes successfully every night for a year is still unproven. The file exists. Whether it restores a working database is untested until somebody tries. Restore drills, run on a schedule against staging rather than waited on until an emergency, turn we have backups into we know this works and how long it takes. During a real incident the number that matters is not whether a backup exists. It is how many minutes the restore takes, and whether anyone has done it before under pressure.

A support relationship accumulates tribal knowledge fast. Which server this site actually lives on. Why that one plugin is pinned to an old version. What the deploy script undocumented flag does. Written into a runbook the first time it is worked out, that knowledge survives a handoff to a different engineer, or a 2 a.m. incident where the usual person is unreachable. Left in one head, it turns every absence into a risk and every incident into the rediscovery of something already solved once.

A site that gets slower every few months without code changes usually has a database problem, not an application one. A table has grown past the point where a missing index matters. A query that used to scan a thousand rows now scans a million. Watch slow-query logs on a schedule. Waiting for a complaint is not maintenance. Track replication lag as a number too, rather than noticing it only when a read from a replica returns stale data. None of this shows up in a feature demo. It shows up eighteen months later, as the difference between a site that still feels the same and one that has quietly degraded.

A maintenance window used to mean a back-soon page and an apology email. Most of what needed that treatment can now run against a live system. A schema change staged so the table keeps serving reads and writes through the migration. A deploy that rolls new instances in behind a load balancer before draining the old ones. A cache warmed before traffic reaches it. The maintenance still happens on a schedule and still gets announced in advance. What changes is that scheduled maintenance and the site goes down stop meaning the same thing.

A support plan with one tier works fine until the person on call hits something outside their depth at 11 p.m. A defined escalation path — a second contact, and a clear threshold for using it — keeps that from becoming hours of trial and error on a live production issue. The threshold counts as much as the contact. Paging a senior engineer for every minor question burns trust fast. Never escalating turns a fifteen-minute fix into an overnight outage, because nobody wanted to make the call.

A staging environment earns its name only if it mirrors production closely enough to catch what actually breaks there. Same PHP or Node version. Same plugin set. Same database size class. Not a stripped-down copy running on a laptop. A change validated against a staging environment that has drifted for months will pass every check and still fail on the real thing, because the divergence is exactly where the bug was hiding. Keeping staging in sync is ongoing maintenance in its own right, not a setup step.

A payment gateway. A shipping-rate API. A mapping service. Any third-party dependency can deprecate an endpoint or change a response format on its own schedule, with or without warning that reaches the team relying on it. A site that discovers this when checkout starts failing is treating a known risk as a surprise. Subscribe to the changelog or status page for anything load-bearing. Pin API versions where the vendor supports it. That turns the failure mode into a scheduled update.

Every content change routed through a developer is a bottleneck. It is also an expensive way to fix a typo. The opposite mistake costs more. Give a non-technical editor raw database or template access, and a dropped closing tag takes down a page nobody was trying to touch. The middle ground is a CMS interface scoped to what an editor actually needs, with structured fields instead of raw markup. Then the flexibility developers need and the safety editors need stop trading off against each other.

A site that passes a performance audit at launch can still slow down afterward. An image uploaded at full resolution instead of compressed. A tracking script added for a campaign and never removed. A database table grown past what an old index handles well. None of these is a dramatic failure. Each shaves a little off load time, until eighteen months of small additions add up to a site noticeably slower than the one that shipped. Tracking performance on a schedule, rather than when someone launches something new, catches the drift while it is still small.

A plugin that stops receiving updates does not announce it. It quietly falls behind the CMS core it depends on. Then an unrelated core update breaks it, or a known vulnerability in it never gets patched because no maintainer is left to patch it. Waiting for a break to force the issue is not a plan. An annual audit of what is installed against what is still actively maintained is — with a migration plan for anything that has fallen off that list, written before it becomes the reason an upgrade has to be rushed.

A report listing every ticket closed last month tells a client that activity happened. It does not tell them whether the site is healthier than it was. A useful report pairs the activity log with a few numbers that persist across periods: uptime, average response time, open versus resolved issues by severity. Then a client sees a trend rather than a bare list. Cadence matters as much as content. Monthly for a steady retainer. Faster during an active incident. Never so frequent that the report itself becomes overhead nobody reads.

Configuration that lives as a hardcoded value in one environment — an API key, a feature flag, a database host — is how it works on staging becomes a production incident the moment the two stop matching. Pull environment variables from a per-environment config. Do not commit them. Then the same build deploys anywhere. Keep a documented list of what differs between environments, and why. That turns staging does not match prod from a mystery into a checklist. Secrets belong in a vault or environment variable, never in a repository. A key committed once stays in git history long after it is deleted from the current file.

A sale, a press mention or a seasonal peak is a known date on the calendar. That makes the load it brings a testable scenario rather than a surprise. Load testing ahead of the date — simulating concurrent checkouts rather than page views — surfaces the bottleneck while there is still time to fix it. A database connection pool sized for normal traffic. A third-party API with its own rate limit. A cache that was never warmed. Finding that bottleneck during a scheduled test costs an afternoon. Finding it during the spike costs the sale.

Handing someone their first on-call shift without context is how a routine alert becomes a panicked escalation for something the runbook already covers. A structured ramp fixes it. Shadow a few incidents before taking any solo. Walk through the architecture map and the runbook library before either is needed under pressure. Start on a rotation with a senior engineer reachable as backup. That produces someone who can actually carry a shift, rather than someone technically listed on the schedule.

A retainer billed by the hour earns trust only if the hours trace to specific, described work. A lump sum at the end of the month does not. Time tracked against a ticket and visible to the client as it accrues — rather than surfacing as a surprise at invoicing — turns trust us into something a client can verify. Unused hours need a clear policy too: rolled over, expired, or credited. Decide it upfront. Arguing it after the fact costs more than the hours did.

A scheduled maintenance window and an unplanned outage look alike from outside. The site is down. They still need separate categories, because conflating them hides the number that matters: how often something breaks unexpectedly, against how often the team takes the site down on its own terms. A plan reporting 99.9 % uptime without separating planned from unplanned is either hiding a reliability problem or overstating one. A client who asks the right question here should get a straight answer, with the two numbers kept apart.

A marketing brochure site and a platform processing customer transactions do not need the same monitoring depth. Full distributed tracing and per-query profiling are overkill for the first and close to the minimum for the second. Match the investment to the stake. Ask what actually breaks, and what it costs. Otherwise the monitoring becomes a maintenance burden larger than the problem it was meant to catch, and a small site spends its support budget on infrastructure a small site does not need.

A WordPress front end pulling product data from a headless commerce platform. A marketing CMS sitting in front of a separate application layer. In setups like these an update on one side can break the other while neither system reports an error: a content field renamed in the CMS silently breaks a template expecting the old name. So the seam gets its own monitor. Watch it alongside the two systems it connects. That seam is where a change on one side turns into a visible failure on the other.

Over a long support relationship, a deploy that introduces a regression is a normal event. What separates a five-minute recovery from a two-hour one is whether a rollback path existed before the deploy went out. Keep the previous build ready to restore. Write database migrations to be reversible wherever that is feasible. Name the person who makes the call to roll back, so the default is not wait and see. All of it gets decided ahead of the deploy, not during the incident it is supposed to shorten.

A support engagement rarely starts on a blank slate. There is usually an in-house developer, a previous agency, or a founder who has been patching things together. Each of them holds context that lives in no codebase. So onboarding starts with an interview. Talk to whoever has been keeping the lights on, before assuming the documentation tells the whole story. The gap between what the code does and what everyone knows about why it does that is exactly where a takeover goes wrong when the step is skipped.

A single error entry rarely tells the whole story. The useful signal sits in the pattern across a week of logs. The same exception firing at the same time every night. A spike that lines up with one traffic source. A warning quietly accumulating for months while nobody treated it as urgent. Reviewing logs on a schedule, rather than only when something visibly breaks, catches a slow-building problem while it is still a warning and not yet an incident.

Some issues are neither purely technical nor purely editorial. A layout that breaks only with a long product title. A form validation error triggered by one character an editor pasted in from elsewhere. Fixing these well means the developer and the content owner comparing notes on the actual case, instead of each assuming it belongs to the other side. The fix is usually smaller once both perspectives are on the table than either side guessed alone.

A client pausing a retainer for a few months — a slow season, a budget freeze — does not have to restart from zero. It depends on whether the runbook, the architecture notes and the open-issue list were kept current during the active period, rather than living only in whoever handled the account. A pause handled well leaves a clear record. Pick it up and carry on. A pause handled poorly turns the restart into a second onboarding, paid for twice.