Website upgrade and repair services

Every repair engagement starts with an audit, because guessing is expensive. We look at hosting and server configuration, PHP or Node versions, dependency ages, database health, error and access logs, uptime history and the field performance data Google has collected for the domain.

The output is a written findings list ordered by risk and cost, separating what is breaking the site now, what will break it within a year, and what is merely untidy. You decide what to fix.

If the honest answer is that a rebuild costs less than continuing to patch, we say so and show the arithmetic. We would rather lose a repair job than bill you monthly for a foundation that cannot hold.

The first job is containment: take a forensic copy, rotate every credential, close the entry point and check for scheduled tasks or database-level backdoors that survive a file clean. Restoring a backup without finding the entry point simply resets the clock until reinfection.

We then remove injected content, clean the database, patch the vulnerability that allowed entry, and submit reconsideration requests where Google Safe Browsing or a host has flagged the domain.

You receive a timeline of what happened and what was changed. Where your organisation falls under the CERT-In directions of 2022, that record supports the six-hour incident report, and where personal data was affected the Digital Personal Data Protection framework brings its own notification duties.

Legacy sites usually fail for the same handful of reasons: an end-of-life PHP or Node runtime, abandoned plugins with no maintained replacement, a theme edited directly so updates overwrite the changes, or a jQuery-era front end that cannot meet current performance expectations.

We upgrade in stages on a staging copy, with a rollback point at each step and a functional test of the pages that make money. Where a plugin has no maintained successor we replace the functionality with maintained code rather than freezing the whole site on an old version.

Where the front end is the bottleneck, we often keep the existing CMS as a content store and rebuild the presentation layer on a modern framework, which preserves your editorial workflow and your URLs.

Speed work starts with field data rather than a synthetic score, because a laboratory number can look fine while real users on a mid-range Android phone wait. We look at Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift for real sessions.

Typical remedies are unglamorous: correctly sized responsive images in modern formats, self-hosted subsetted fonts, deferred and audited third-party tags, sensible cache headers and a content delivery network for static assets.

We also fix the cause, not only the symptom, by adding automatic image compression at upload and a documented tag policy, so the site does not slowly get heavy again over the next six months.