Website fixes: what they include, how to write the task and when to rebuild instead

Website fixes: changing a site that already works

Website fixes is the trade name for any change made to a site that is already live and bringing in requests: a broken form repaired, a slow page made faster, a new section added to the menu. The site is not started again. It keeps its address, its content and its search history while parts of it are corrected or extended. The risk is that every change lands on a working system that customers are using at that moment.

A redesign changes how the whole site looks and is organised; it usually touches every template and often the structure of the pages. Support, often called maintenance, is a standing arrangement: someone watches the site every month, installs updates, keeps backups and reacts when something breaks. Building from scratch means a new site that replaces the old one. Fixes sit between these: a defined list of changes, done once, with a result you can check.

The borders are not sharp. A long list of changes can quietly grow into a redesign, and small jobs ordered every month are already support. Naming what you order sets the expectation. A fix is judged by whether the specific problem is gone, a redesign by whether the whole site works better, and support by how quickly someone answers when it does not.

Typical tasks, from broken forms to speed and phones

The most common request is a bug: a button that does nothing, a page that returns an error, a price that shows wrongly, a form that sends requests nowhere. Forms deserve special care, because a silent failure there looks exactly like a quiet week. Sending a test request and checking that it reaches the inbox, the CRM or the team chat is one of the cheapest and most useful website fixes there is.

Speed is the second large group. web.dev, Google’s site for developers, describes three Core Web Vitals and gives a target for each: the main content should appear within 2.5 seconds (Largest Contentful Paint), the page should respond to a tap or click within 200 milliseconds (Interaction to Next Paint), and the layout should shift no more than 0.1 on the Cumulative Layout Shift scale. It recommends measuring at the 75th percentile of page loads, separately for mobile and desktop. The usual cures are lighter images, fewer heavy scripts and fixed sizes for blocks that jump.

The phone version is the third. Google Search Central states that Google uses the mobile version of a site’s content for indexing and ranking, and that only the content shown on the mobile site is used for indexing. A text hidden on phones, or a table that does not fit the screen, is therefore a search problem as well as a usability one. The rest of the list is familiar: page titles and descriptions, broken links, a new block on the homepage, an online payment, a chat widget, a product feed for a marketplace.

Writing a fix request a developer can act on

A good request answers four questions. What is broken, in one sentence. Where exactly: the address of the page, the device, the browser. How to repeat it: the steps from opening the page to the moment it fails. And how you will know it is fixed: the result you expect to see. A screenshot or a short screen recording beats a long description.

Separate errors from wishes. “The form does not send” is an error with a clear end. “Make the homepage more modern” is a wish that needs a design brief before anyone can estimate it. Put first the problems that cost requests or money, and the cosmetic ones last. A numbered list with one problem per line lets the contractor estimate every item separately and lets you approve them one by one.

Access rights and a fresh backup before any change

The work needs access: the admin panel of the CMS or site builder, the hosting or server, the domain registrar, sometimes the analytics and the email service behind the forms. Give a contractor separate accounts rather than your own password, so access can be removed afterwards. Larger changes are safer on a copy of the site, a test version where mistakes cost nothing, moved to the live site only after a check.

The second precondition is a backup. The WordPress documentation splits a backup into two parts, the database and the files, and says you need both to restore a typical site. It suggests weekly backups for smaller sites and daily ones for busy sites, always a backup before an upgrade, and at least three to five recent copies kept in different places, such as the hosting server, cloud storage and a local computer. The advice is written for WordPress, but the logic holds for any platform: before a change, make sure there is a way back.

Keeping search positions when fixes change page addresses

Most fixes leave page addresses alone, and search engines barely notice them. The risk appears when a fix renames pages, merges sections or moves the site to another domain or to HTTPS. The site-move guide on Google Search Central starts with a map: a list of the old URLs with the new URL for each, built from sitemaps, server logs and the CMS.

The map then becomes a set of redirects. Google asks for server-side permanent redirects, such as 301 or 308, sent straight from each old URL to its final destination without chains, and says to keep them generally for at least a year. Its page on redirects explains the difference: after a permanent redirect Google treats the target as the canonical address, while after a temporary one, such as 302 or 307, the old address can stay in results. JavaScript redirects are called a last resort there, since Google may never see them if rendering fails.

Even a careful move is not invisible. The same guide warns to expect temporary fluctuation in rankings while Google recrawls the site, which can take weeks for a medium-sized one. Internal links should point to the new addresses, the sitemap should be updated, and each new page should carry a canonical tag that points to itself.

Updating the CMS and plugins without breaking the site

Updates are the kind of fix that never ends. The WordPress documentation says that since version 3.7 most sites install minor and security updates automatically in the background, while major releases still need someone to press Update Now. It also warns that an update replaces the core files, so any change made directly in them is lost. Its manual procedure deactivates plugins before the update, reactivates them afterwards and clears the cache so visitors see the new version. A change written into core files instead of a theme or plugin is a change with an expiry date.

Security follows the same line. OWASP calls its Top 10 the reference standard for the most critical web application security risks; the current release is from 2025. Its third category, Software Supply Chain Failures, covers breakdowns or compromises in building, distributing or updating software, and it grew out of an older entry about using components with known vulnerabilities. Among the measures OWASP lists are removing unused dependencies, features and components, updating in a timely, risk-based way, and rolling updates out in stages rather than everywhere at once. For a small site: fewer plugins, regular updates, a check after each.

When rebuilding costs less than another round of fixes

Fixing makes sense while the base is sound. The signs that it is not are easy to spot: every change breaks something elsewhere, nobody dares to update the CMS because the code was edited in place, the theme or platform is no longer supported, the mobile version is a separate site that no one maintains, and estimates for small tasks keep growing. Each new fix then buys less than the one before it.

A practical test is to add up what the next year of changes will cost and compare it with the price of a new site that solves the same problems, including redirects and the transfer of content. If the list touches most templates, or the business has changed so much that the structure of the site no longer fits, a redesign or a rebuild is usually the honest answer. If the problems are local and the platform is alive, fixing costs less and keeps the search history intact.

What to prepare before ordering website fixes

Plenty can be done without a contractor. Texts, photos, prices and simple blocks in a site builder or CMS are meant to be edited by the owner, and updates and backups through the admin panel are within reach too, if you follow the platform’s documentation and check the site afterwards. Code, server settings, redirects, integrations and anything that touches payments or personal data are better left to someone who does that work every day.

Before ordering, prepare the list of problems written as described above, the access accounts, proof that a fresh backup exists, and analytics figures showing which pages bring requests and which are slow. Decide who on your side checks each change and how quickly. With that on one sheet, any studio, VITON13 included, can estimate each item separately, and you can choose which website fixes come first.