Why websites get worse after launch
A website is usually at its best on the day it launches. Everything has been checked, the images are the ones the designer chose, the copy is the copy that was signed off, and nothing has been added in a hurry.
Then it goes into service, and it starts getting worse.
This is not a failure of care. It is what happens when a site is treated as a project that finishes rather than a system that runs. The interesting part is that the decay is predictable, and most of what causes it is decided before handover, not after.
What actually degrades
Four things, in roughly the order you notice them.
Content stale-out. The team page lists someone who left. The pricing is last year's. A seasonal banner is still up in March. None of this is hard to fix; it stays broken because nobody owns it and nothing surfaces it.
Visual drift. A new campaign needs a banner that does not fit any existing block, so someone forces one. A landing page needs a wider column, so the grid is overridden. Each change is reasonable on its own. Twenty of them and the site no longer looks designed.
Performance creep. An analytics tag here, a chat widget there, three uncompressed images from a phone. Nothing individually alarming, and no single change big enough to notice, which is exactly why it accumulates.
Dependency rot. The libraries the site was built on keep moving. A year in, updating one of them is no longer a small job, so nobody does, and the gap widens.
Why handover is where it breaks
The common pattern goes like this. An agency designs a site, builds it, and hands over a set of design files and a codebase. The client's marketing team then needs to publish things: a campaign, a new service page, a seasonal offer. The site does not have a way to do the thing they need.
So they do the only thing available: they break the pattern. They paste a block from somewhere else, override a style, or ask a developer for "just a quick change" that adds a one-off component nobody will ever maintain.
The root cause is that the design rules lived in a document, and documents are advisory. A PDF explaining the spacing scale does not stop anyone using the wrong spacing. A Figma file showing three approved card layouts does not stop a fourth being invented at 6pm before a campaign goes live.
Rules in code, not in documentation
The alternative is to make the constraints structural. The site should make the right thing easy and the wrong thing awkward, without anybody having to remember a rule.
In practice that means a few specific things.
Give the CMS real block patterns. Not a rich-text field that accepts anything, but a defined set of blocks (a hero, a two-column feature, a quote, a call to action), each with its own fields. If a marketer needs a section, they pick one and fill it in. They cannot produce a layout the design never anticipated, because the tool does not offer one.
Constrain the content, not just the layout. A headline field with a character limit will not break the design when someone writes a long one, because they cannot. The same applies to image dimensions, list lengths, and how many items a carousel accepts.
Decide performance before you build, not after. A budget set at the start (a page weight, a limit on third-party scripts, rules about image formats) changes what gets built. The same budget applied after launch is a cleanup job that competes with everything else for time, and usually loses.
Make the handover include the mechanism, not just the output. The difference between a site that ages well and one that does not is often whether the client can do their ordinary work inside the system. If routine updates require the agency, the client will eventually route around the agency, and that is when the design goes.
If you are commissioning a site
There are a handful of questions worth asking before work starts. None are technical, and the answers tell you a great deal about what you will be living with.
- When my team needs to add a new page in six months, what exactly do they do?
- Which parts can we change ourselves, and which need a developer?
- What stops someone on my team accidentally breaking the layout?
- Who updates the dependencies, and what happens if nobody does?
- What does this site weigh, and what keeps it from getting heavier?
A studio that has thought about the second year will have ready answers. One that has not will talk about the launch.
The point
Designing for launch day is designing for the easiest day the site will ever have. Everything after it is harder: more content, more people touching it, more pressure to publish quickly, less attention.
A site built for that second year does not need to be more complicated. It usually needs to be more constrained: fewer ways to do things, each one designed, each one hard to get wrong. That is less exciting to specify and it is the whole difference between a site that still looks deliberate in eighteen months and one that quietly stopped being designed some time in month four.
Source and further reading: Smashing Magazine: why a website should never stop changing
Questions people also ask
Content whenever it stops being true, which for prices, staff and services is more often than most businesses expect. Platform and plugin updates monthly. A proper review once a quarter, checking that the contact details are right and the enquiry form still delivers, catches nearly everything before a customer does.
Platform and plugin updates, backups you have tested restoring, uptime monitoring, security patches, and a small allowance of content changes. It should be written down and priced separately from the build, so you can see what you are paying for rather than guessing.
If the structure still matches how you sell and the pages still load quickly, it is a refresh: new copy, new photographs, a tidy of the design. If you have changed what you do, or the site cannot express a new service without a developer, the structure is the problem and no amount of restyling fixes it.
One named person inside the business, not a job title and not the studio. It does not need to be someone technical, only someone with the access to make a change and the responsibility for noticing when one is needed. Sites decay because nobody is that person, not because nobody is capable.