How Hosting Limits Can Affect Large Website Redesigns

When Digg relaunched in 2010, it lost more than a quarter of its audience inside a few months, and the post-mortems all pointed at the design. Most redesign failures are quieter and more mechanical. The design was fine, the copy was ready, and the server underneath could not carry the work the rebuild demanded of it.

A redesign is the heaviest thing a site ever does. For several weeks the account holds two versions of the site, imports and exports run at full tilt, and the database is rewritten while visitors keep arriving. The limits on a hosting plan go unnoticed during a normal month and become immovable during that one.

Disk Space for Two Copies of a Site

A rebuild means the old site and the new site are held in the same account at once, along with a backup of each and an archive of the media library. A 12 GB site becomes a 30 GB account before anything has launched.

Plans advertised with generous storage often meter it in ways that matter more than the number. Some count backups against the quota, some count email, and some impose a file count limit that a media library with 40,000 images will reach long before the disk fills. When the account hits the wall mid-import, the failure looks like a corrupt database, and the developer spends two days chasing the wrong problem.

Check the ceiling and the file count allowance before the project starts. Both are cheap to raise in advance and expensive to raise during a migration.

Database Size and Import Timeouts

A large site has a large database, and the tools that move it have time limits. An export that takes 6 minutes to produce may take 40 minutes to import, and a shared plan that terminates any process at 300 seconds will kill the job at the same point every time.

The symptom is a partial import. Half the products arrive, the taxonomy tables are truncated, and the site appears to work until somebody clicks a category page. Command line access solves this, because the same import runs without the timeout that governs the browser. Plans without shell access force the work through a web interface that was never designed for a 4 GB file.

Post revisions and orphaned metadata make the problem worse. A 10-year-old site can hold more revision rows than post rows, and pruning them before the migration cuts the import from hours to minutes.

Memory Limits During Bulk Operations

Regenerating thumbnails, reindexing a catalog, or rewriting internal links across 5,000 pages are all memory-hungry jobs, and every one of them happens during a redesign. A plan with a 128 MB per-process limit will fail on the first large image and stop.

The limit is usually adjustable, and the interesting question is by how much and by whom. Providers that allow a temporary increase during a migration make the project routine. Providers that treat the limit as a hard boundary of the plan tier turn a rebuild into an upgrade decision taken under pressure, which is the worst moment to be making it.

Plan Stability Through a Rebuild

A redesign is a stress test the account did not ask for. Three numbers decide how it goes, which are the memory ceiling, the process timeout, and the availability of a staging copy, and any provider selling reliable web hosting should be able to state all three without checking.

Read those numbers before the design work starts. A plan chosen for a brochure site in 2019 was sized for a brochure site, and nobody thought about the day it would hold two versions of a 900-page catalog at once.

Staging Environments and Their Absence

Without staging, the rebuild happens somewhere else and arrives as a single event. The developer builds on a local machine or a temporary subdomain, then moves everything across in one operation and finds out in production what did not survive the trip.

A staging environment on the same server removes most of that risk, because the copy runs on the same PHP version and the same limits as the live site. A rebuild that works on a laptop and fails on the server is almost always a version mismatch or a limit that the laptop never had.

Staging also gives the client somewhere to sign off. Approval on a working copy of the site, at a working address, catches objections that screenshots never surface.

Content Inventory Before the Rebuild

The content decisions cause much of the crunch that the technical limits get blamed for. A site with 900 pages usually needs 300 of them, and nobody wants to be the person who says so.

Inventory the pages, record their traffic, and mark each one to keep, merge, or drop before the build begins. Auditing for structure costs less than any other stage of the project, and skipping it turns a redesign into a rebuild of the same problems in a new theme. It also shrinks the database, the media library, and the redirect map, which are the three things that break under a hosting limit.

Redirect Maps and the Move Itself

If the URL structure changes, every old address needs a destination. Google's guidance on site moves is to prepare a mapping from old URLs to new ones, redirect each old address to its closest match, and monitor both sets afterwards.

Hosting shapes how that is done. A redirect map with 4,000 entries in a server configuration file is fast and fragile. The same map inside a plugin is easier to edit and adds a database lookup to every request that misses. On a plan with tight process limits, the plugin version is the one that falls over during the crawl that follows a relaunch, when search engines request thousands of old URLs in a short window.

Chained redirects make it worse. Old address to interim address to final address costs two extra round trips per request, and search engines follow a limited number of hops before giving up.

Concurrency During the Cutover

Relaunch day produces a spike nobody plans for. Search engines recrawl, the marketing email goes out, and the team clicks through the new site while the client's staff do the same. A plan that handles 30 simultaneous requests can queue at 300.

Schedule the cutover for the quietest hour the analytics can identify, lower the DNS record's lifetime a day in advance so the switch propagates quickly, and keep the old site running until the new one has served real traffic for an hour. The rollback plan is the part that gets skipped, and it decides how far a bad launch can fall.

Accessibility and Markup Requirements

A rebuild is the moment to fix the parts of a site that a design refresh usually paints over. Contrast ratios, form labels, heading order, and keyboard operation are all specified in the accessibility guidelines, and they are far cheaper to satisfy in a new template than to retrofit into an old one.

Accessibility work competes for the same hours in the same project plan, and teams that leave it until after launch usually leave it undone.

Planning Errors Mistaken for Server Problems

When a relaunch goes badly, the host takes the blame first. Sometimes that is right. Often the traffic drop came from a redirect map nobody finished, a page hierarchy that dropped the pages that ranked, or a launch date fixed before the content was written. Digg spent the months after its relaunch restoring the Digg v3 features it had removed, which shows what a product decision costs once it ships, and no hosting plan would have prevented any of it.

Separating the two is straightforward once the site is live. If pages are slow at every hour and the server logs show queued processes, the plan is undersized. If pages are quick and traffic fell anyway, the problem is in what was moved and how it was mapped.

The Question to Ask Before the Rebuild

Every redesign eventually meets one of these ceilings, and the only variable is how much notice the team gives itself. So put one question to the provider weeks before a designer opens a file. What happens on this plan when the site is twice its current size, running two copies, importing a 4 GB database, and taking a relaunch spike on the same afternoon? The answer decides if the redesign becomes a project or an emergency.