A redesign creates a better starting point. It does not freeze the website in that state.
Browsers change, dependencies receive security updates, offers evolve, forms connect to external services, and teams add new content. Website maintenance protects a redesign by checking whether the live system still works as intended: the important pages load, the routes resolve, the forms arrive, the content remains accurate, and search engines can still understand the site.
This guide replaces two earlier eXstrue articles that covered the same subject. We consolidated them into one practical reference and removed unsupported benchmark claims. The examples below come from public production checks on four live client projects.
Start the maintenance plan before launch
The useful question is not “Who will fix the site if it breaks?” It is “Who owns each part of the system after handover?”
A post-launch agreement should identify:
- who can approve content and design changes;
- who controls the domain, hosting, analytics, and third-party accounts;
- which updates are included in routine support;
- how urgent incidents are reported and prioritised;
- where backups live and how restoration is tested;
- how larger improvements move into a separate scope.
That ownership map matters because many website failures are coordination failures. A form can be technically healthy while nobody notices that its receiving mailbox changed. A page can remain online while its offer is no longer accurate. Maintenance needs business owners as well as technical owners.
What we check on a modern website
The exact checklist depends on the stack. A WordPress site, a React application, and a multilingual Next.js product do not need identical care. The maintenance routine should follow the real architecture instead of a generic package.
Availability and critical journeys
We start with the actions the website exists to support. For a business site, that may be the contact form, phone link, booking request, or checkout. For a web application, it may be authentication, a search flow, or a dashboard task.
Monitoring the homepage alone is not enough. A site can return a successful response while a deep route, language variant, or third-party integration fails.
Security and dependencies
Updates should be reviewed, tested, and deployed with a rollback path. The goal is not to install every update immediately without context. It is to understand which dependencies affect security or compatibility, test the important journeys, and keep a record of what changed.
Access is part of maintenance too. Remove accounts that are no longer needed, protect administrator access, and make sure ownership does not depend on one person’s private login.
Performance and visual quality
New content can quietly change performance. A large image, extra tracking script, animation, or embedded widget may be reasonable on its own and still make the whole page heavier.
Review the pages that receive traffic and the templates used across the site. Check image dimensions, loading behaviour, layout stability, keyboard access, and mobile interactions. The design should remain usable, not merely visually intact.
Search and content health
Maintenance protects the technical conditions that support organic visibility. Check that important URLs remain indexable, canonical tags and language alternates are correct, sitemap entries resolve, redirects lead to the intended page, and internal links do not end at errors.
Content needs the same attention. Update services, contact details, project evidence, author information, and claims when the business changes. A technically perfect page can still lose trust if its information is stale or impossible to verify.
Field notes from four live eXstrue projects
We inspected the public production technology of the projects in the eXstrue work collection. These observations do not reveal private backend services; they show why maintenance has to match the visible system.
9anon AI: multilingual routes and content parity
9anon AI publicly uses Next.js, React, Tailwind CSS, i18next, and Google Analytics. For a legal-information product in Arabic, French, and English, maintenance is not only a dependency task. It includes checking language routes, direction and layout behaviour, translated interface states, internal links, and analytics across the same question-led journey.
The project also has a reported traffic range: daily clicks moved from roughly 5–10 to 103–200+. Because that result matters, the site should preserve the routes, content, and measurement needed to keep the claim auditable over time.
Pegasus Ride: booking intent must stay visible
Pegasus Ride publicly uses React, Vite, Lucide icons, and Google Analytics. Its website helps travellers compare tours, transfers, and routes before making an enquiry. The maintenance priority is the complete decision path: trip information, calls to action, enquiry links, mobile layout, and analytics—not only whether the homepage loads.
Reservo: client-side routes and server delivery
Reservo publicly uses React, Vite, React Router, Google Analytics, and Caddy. That combination makes deep-route checks important. A client-side route should still resolve when opened directly, refreshed, or shared. Response headers, TLS, caching, and analytics also belong in the live-site review.
Scolink: a richer interface needs a wider regression check
Scolink publicly exposes React, Vite, React Router, Tailwind CSS, Framer Motion, Radix UI, Lucide icons, i18next, Three.js, and Google Analytics. A broader visible stack creates more interaction points to test. Navigation, translated states, animation preferences, component accessibility, mobile behaviour, and bundle changes should be checked together.
These examples lead to one practical rule: maintain the user journey and the operating system behind it, not a list of tools in isolation.
A post-launch checklist your team can own
Use this as a starting point and adjust the cadence to the site’s risk and rate of change.
- Test the primary enquiry, booking, purchase, or product journey.
- Open important deep links directly on desktop and mobile.
- Check language variants and alternate links where applicable.
- Review dependency and platform security notices.
- Confirm backups complete and that restoration instructions are current.
- Review uptime, error logs, and form-delivery failures.
- Inspect high-traffic pages for performance and layout regressions.
- Check sitemap URLs, redirects, canonicals, and broken internal links.
- Verify analytics on the actions used to measure the site.
- Review services, contact details, team information, and public claims.
- Record changes, access ownership, and the next improvement decision.
In-house maintenance or a specialist partner?
Either model can work. Keep routine content ownership close to the people who know the business. Give technical responsibilities to someone who can inspect the stack, test changes, and recover safely when something goes wrong.
The decision should be written down. Define what the internal team owns, what the specialist monitors, expected response routes, and what falls outside routine maintenance. This avoids the common gap where everyone assumes somebody else is watching.
eXstrue treats maintenance as part of delivery, not an emergency add-on. The website maintenance service is scoped around the actual platform, business-critical journeys, ownership, and post-launch priorities.
Protect the system, then improve it
Good maintenance does more than prevent failure. It gives the team a reliable base for better decisions. Once the site is observable and its core journeys are healthy, you can improve content, performance, accessibility, and conversion with more confidence.
If you are planning a redesign, include the post-launch operating model in the proposal. If the redesign is already live, begin with a small evidence-based review: critical routes, forms, access, backups, search signals, and the claims customers rely on. That is the practical work that keeps a strong launch useful.