Working on a site nobody can explain means the risk is breaking something rather than failing to improve it. The workable approach is to measure first, then apply changes in order of how safely they can be reversed, starting with the ones that cannot break anything.

The different problem

On a site you built, you know what each component does and what depends on it. On an inherited one you know neither.

That changes the priority. The question is not what would make the biggest improvement, it is what can be done without breaking a site whose construction is unknown and whose builder cannot be asked.

Which means the order of operations matters more than the individual techniques, and a cautious sequence produces a better outcome than an aggressive one that breaks the contact form.

Before touching anything

That last one is worth pursuing. Where staging exists or can be created, the whole exercise becomes safe. Where it does not, everything below is done on a live site and the sequence matters much more.

Measure before assuming

Two measurements answer where the problem actually is.

The server response time, which tells you whether the delay is before anything reaches the browser. And the waterfall, which shows what is loading, in what order, and what is large.

Those two split the problem into server-side and page-side, and the fixes are entirely different. Guessing at this stage is how businesses buy more hosting to solve an image problem.

On an inherited site this matters more, since the assumptions you would make about a site you built do not apply.

The order, by reversibility

First: things outside the site

Image compression on files you replace individually, a caching layer at the host or a content delivery network, enabling text compression, and updating the language version after checking compatibility.

None of these change the site's code, and all are reversible by switching them off.

Second: removing what is unused

Plugins and components that are deactivated, obviously abandoned, or duplicated. Remove one at a time, checking the site after each.

Reversible by reinstalling, provided you noted what was there.

Third: configuration changes

Caching plugin settings, lazy loading, deferring scripts. These change behaviour and can break things, particularly script deferral, which is the single most common cause of a page that suddenly stops working.

Reversible by changing the setting back, and worth doing one at a time.

Last: touching the code

Editing theme files, combining resources, or rewriting anything. On an inherited site with no documentation this is where breakage happens, and the changes are frequently overwritten by the next update anyway.

The specific traps on inherited sites

Custom code in the theme. Somebody edited the theme directly rather than using a child theme, so an update wipes their work. Check before updating anything.

A plugin doing something invisible. Removing what appears unused occasionally removes the thing handling redirects, form delivery, or a tracking script. One at a time, with checks.

Hard-coded settings. A configuration value in a file rather than in the interface, which means a change made through the panel silently does nothing.

Two things doing the same job. Two caching mechanisms, two image optimisers. Removing one occasionally fixes more than any optimisation.

An integration nobody mentioned. A booking system, a payment link, or a feed to another platform, which breaks quietly and is discovered when somebody complains.

What usually turns out to be the problem

On most inherited small business sites, in rough order of frequency.

Images uploaded at full camera resolution and displayed small. A page builder loading its entire framework on every page. A dozen plugins where four are used. An old language version. And a hosting plan the site outgrew.

The first is usually the largest single win and it is entirely safe, which is a fortunate combination and the reason to start there.

When to stop and rebuild instead

An honest threshold, since some sites are not worth optimising.

Where the site runs software that is no longer supported, where the theme is abandoned, where the construction is so unusual that every change breaks something, or where you have spent more time investigating than a rebuild would take.

That is a judgement rather than a rule, and it is worth making explicitly rather than drifting into an open-ended project. A site that resists three safe changes is telling you something.

Document what you find

The step that makes the next person's job possible.

What is installed and what each does, what you changed and when, what broke and how you fixed it, and anything unusual you discovered.

That record is what you wish had existed when you started, and it takes minutes to keep while working, which is the same argument as any change log, as covered in plugins, add-ons, and accumulated weight.

Frequently asked questions

What is different about optimising an inherited site?

The risk is breaking something rather than failing to improve it, since you do not know what each component does or what depends on it.

What should be done before touching anything?

A full downloaded backup, current measurements, a test that forms still deliver, a note of what the site does, and finding out whether a staging copy is possible.

What order should changes be made in?

By reversibility: things outside the site first such as caching and image compression, then removing unused components, then configuration changes, and code last.

What are the specific traps?

Custom code edited directly into a theme, a plugin doing something invisible such as redirects, hard-coded settings that override the interface, and duplicated components.

What is usually the actual problem?

Images at full camera resolution displayed small, a page builder loading everything on every page, unused plugins, an old language version, and an outgrown hosting plan.

When should I rebuild instead?

When the software is unsupported, the theme abandoned, every change breaks something, or you have spent more time investigating than a rebuild would take.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Slow site and no way to reach whoever built it?

We measure first, work in order of what can be safely reversed, and leave you the documentation that was missing.

Start a Conversation