Make an Old Site Responsive or Rebuild?

Your old website was designed around a desktop screen. On a phone, a potential customer has to pinch, zoom, and scroll sideways to find the contact form, and your team agrees the site needs to work on phones and tablets too. Now you have two directions in front of you.

One is a retrofit: adapt the templates the site is already built from, such as the reusable page layouts for articles or product pages, so the same pages work at different screen sizes. The other is a rebuild: replace those templates, or other foundations under them, with new ones.

The labels sound like a clear choice, but each proposal decides for itself what it keeps, adapts, and replaces. This guide helps you compare the two routes and ask for that detail before you approve either.

It starts after you know something has to change.

If you’re still weighing whether a redesign is justified, read Signs Your Website Needs a Redesign first.

• If a finished page is already in front of you, How to Test Your Website Before Launch is the better starting point.
• Here, a responsive site means one page at one address that displays differently depending on the screen size.
• For the difference between responsive and mobile-friendly, see Responsive vs Mobile-Friendly: Are They the Same?

Compare the Two Routes Before You Compare Quotes

Use this table to compare what each proposal would keep, change, and need to demonstrate. Age, a fixed width, or a separate mobile site doesn’t settle the choice. Ask the team which required changes the current templates can support.

Ask These Questions About Any Proposal

Use this card with an agency, a freelancer, or your own developers, for either route. Each question turns a label into something the team can show you.

1. “What will you keep, adapt, and replace?” The answer defines the route better than the word “retrofit” or “rebuild.”
2. “Which page types and tasks does this cover?” A text article and a page with a wide table can need different work.
3. “Are colors, text styles, and page parts defined once and reused, or repeated page by page?” The answer shows how many places one fix has to be made.
4. “Can you show the approach on one difficult page first?” Pick a page with a wide table, a long form, or an embedded form, video, or map.
5. “Which third-party tools or platform limits affect the work?” Booking or payment services, embeds, and the platform version can all limit what is possible.
6. “What will still be broken or hard to maintain afterward?” A named exception can be planned for. An unnamed one turns up after launch.
7. “Will any page addresses change, and who owns the redirects and checks?” The section on site moves below explains why this matters.
8. “How will we review the result, and who fixes what we find?” Agree this before the work starts.

Compare the answers on coverage. A proposal that leaves out forms, difficult pages, or testing isn’t the same work as one that includes them.

How Easy Is It to Retrofit This Site?

The site’s age matters less than one practical question: how many places does a fix have to be made? A site built from shared parts can be adapted by changing those parts. A site where every page carries its own styling has to be adapted page by page.

Designers call this shared kit a design system. In marketer terms, it is a set of colors, text styles, and spacing, ready-made parts such as buttons, menus, and cards, and the rules for using them. Nielsen Norman Group defines it as “a complete set of standards intended to manage design at scale using reusable components and patterns.” Two pieces matter for a retrofit:

• Tokens give a design decision a name. A name such as “body text size” stands in for the raw value, so the team can change it once and know where the change will show up. Design Tokens Explained shows how that works.
• Components are the reusable parts. A button, card, or menu is built once and used on every page that needs it. What Is in a Design System? covers what else belongs in one.

The difference changes the effort in a concrete way. Say the main button is too small to tap on a phone. If the site has a button component, the team fixes it once, and every page that uses it picks up the change. If each page has its own hand-built button, the team has to find and fix every one, and the same goes for text sizes, menus, and layouts. On a site with a few pages, that is manageable. On a site with many pages, fixing everything by hand can add up to reworking most of it. At that point it is fair to ask whether the team should set up those shared parts and compare that option with the retrofit. That is an editorial judgment, not a measured figure, and this guide doesn’t put a number on it.

Not having a design system doesn’t settle the question. A small site, or one whose pages all come from a few shared templates, can be adapted without one, because the templates do the same job. A retrofit can also set up shared styles for the most-used parts as it goes. Shared parts don’t make a site responsive by themselves: a shared layout built at a fixed width still has to be changed, and shared parts need people to keep them up to date. What matters is how much is shared, how much has to change, and what each team proposes to replace.

Ask the team these questions:

• Are colors, text styles, and spacing defined in one shared place, or repeated on each page?
• Are there reusable components for buttons, menus, forms, and cards?

The answers tell you what to ask next. If most styles are repeated across many pages, ask for a rebuild option beside the retrofit and compare what each would keep, adapt, and replace.

What Does Making an Existing Site Responsive Involve?

If you ask for a retrofit, the proposal should describe work like the six steps below. There doesn’t appear to be a single official retrofit checklist, so treat this order as a practical sequence, not a standard. Each step draws on guidance from MDN, the W3C, or Nielsen Norman Group. For each step you’ll see what changes, why it matters, and how to check it without reading code. You’re checking what a visitor sees, and the team works out the cause.

1. Set the page to use the screen’s width. Without a viewport setting, some mobile devices lay a page out in a virtual window wider than the screen and then shrink the result to fit, as MDN explains. That’s why an old page can arrive on a phone as tiny text a visitor has to pinch to read. To check it, open the page on a real phone. The text should be readable without pinching. A narrowed desktop window or a width-based preview may not show this problem, because it comes from how the phone handles the page.

On its own, that setting doesn’t fix a fixed-width layout. If the page is built at a set width, the browser now matches the phone’s width, but the page still doesn’t fit it. The visitor may have to scroll sideways, or the browser may shrink the page again. If a team says it added the setting and the site is now responsive, ask it to show you the page at phone width with no sideways scrolling of the page itself. A wide data table may scroll, which step 4 covers.

2. Let the layout resize and rearrange. MDN describes HTML as fundamentally fluid and says a fixed width “leads to scroll bars on narrow devices and too much empty space on wide screens.” Retrofit work replaces fixed widths with flexible ones, so columns and blocks shrink, grow, and stack. To check, narrow a desktop browser window slowly. The content should reflow instead of being cut off or running past the edge.

3. Make the navigation work on a small screen. A menu built for a wide screen often has to collapse or reorganize, and a collapsed menu is a trade-off. A 2016 test of six sites by Nielsen Norman Group found that people used hidden navigation less often than navigation that was visible or partly visible, on both desktop and mobile. On phones, participants used a hidden menu in 57% of cases and a partly visible menu in 86%. The study is from 2016, so treat it as a reason to ask, not a rule: ask what a visitor sees before opening the menu. To check, try to reach every main section from the menu at phone width. How to Review a Mobile Menu covers the details.

4. Make images and tables fit. MDN notes that a large desktop image can waste bandwidth on a phone, while a small image looks grainy when it’s enlarged, and that a page can offer the browser several image files to choose from. Wide data tables are a different case. The W3C’s Reflow guidance allows a data table to scroll sideways, and its tables tutorial says a table shouldn’t be cut off. To check, look for images that are cut off or blurry, and make sure you can reach every column of a wide table at phone width.

5. Make controls easy to tap. Buttons, links, and form fields built for a mouse pointer can be hard to hit with a finger when they’re small or close together. WCAG 2.2 sets a minimum target size for pointer targets, with exceptions, so ask which standard the team is working to. Before testing a form or checkout, agree on a safe test path with the team. Then try the main action, the menu, and every field of the main form on a real phone.

6. Check pages and tasks across widths. A change to a shared template can affect every page that uses it, so a fix that works on the page the team demonstrated can change pages nobody looked at. Ask the team to check each page type and each important task at several widths. The last section of this guide describes what to agree on.

Collect Evidence Before You Ask for Quotes

Quotes are easier to compare when every team looks at the same pages. Before you ask, gather evidence from your current site:

• Page types, not just pages. List the distinct kinds of page, such as home, article, product, and contact. One example of each is enough to start.
• One important journey. Include a path a potential customer takes to an inquiry or a purchase.
• Difficult content. Include a page with a wide table, a long form, an embedded form, video, or map, or long headings.
• What fails, where, and what it prevents. Note the page, the screen size, the problem, and the task it blocks.
• How many pages share each layout. Ask for a count by page type, and whether styles and parts are shared or repeated page by page.
• What the pages depend on. Ask the team which templates, connected services such as booking or payment tools, and platform version these pages use.

To see your current pages at three widths side by side, you can use Online Website Previewer. It’s free and needs no account. Each frame loads the live page, so a submitted form or an order has its usual effect. If the journey involves a form or checkout, agree on a safe test path with the team first.

Then paste an address and press Preview to see desktop at 1920 by 1080, tablet at 820 by 1180, and phone at 390 by 844, in CSS pixels.

Those are the previewer’s own sizes, a starting view rather than a match for your visitors. Custom sizes aren’t offered, so narrow a desktop browser window if you want to see widths in between, or see which screen sizes to use when reviewing a website.

The preview shows how a page lays out at a narrow width in your current browser. It doesn’t copy iOS, Safari, touch input, or device performance, so those need a real phone. If the phone frame still shows the desktop layout, the page may not be built to adapt at all. The previewer’s FAQ also says some sites choose their layout by browser type instead of screen width. Responsive vs Adaptive Design: What’s the Difference? explains what that can mean.

Turn each finding into a note the team can act on:

“On [page], at [screen size or window width], [problem] stops a visitor from [task]. Please confirm whether the proposed scope fixes this across every page that uses the same template, and name any exceptions.”

For more on writing notes like this, see how to give useful feedback on a website design.

When Does a Retrofit Stop Being the Right Scope?

There’s no official rule for when to rebuild instead. Treat each situation below as a question for the team, with the evidence to ask for, not as a verdict.

• Most of the site would be reworked by hand. If styles and parts are repeated on many pages, one fix has to be made many times. Ask each team how many pages it would touch by hand.
• The layout is built from tables or fixed widths. MDN calls older, float-based ways of building page grids “legacy,” and the W3C says tables shouldn’t be used for layout. A page with no flexible structure gives the work little to adapt, so the effort can come close to replacing the templates. Instead of accepting “it’s old,” ask the team to show which required changes the current templates can’t support. A table that holds data, such as a plan comparison, is a different problem. It’s a component to fix, not proof that the whole site needs a rebuild.
• The platform is no longer supported. If the version your site runs on no longer gets updates from its maker, ask what upgrading or moving involves and whether the responsive work would carry over. That question can drive the decision even when screen sizes alone wouldn’t.
• A separate mobile site exists. Google lists separate mobile addresses as one of three mobile configurations and recommends responsive design as “the easiest design pattern to implement and maintain.” Ask for a page-by-page list of which mobile page matches which responsive page, and who owns the redirects. Google’s 2017 guide to this move says to set up 301 redirects from each mobile address to its matching responsive page.
• A rebuild is already planned. Ask which fixes protect essential tasks now and which would be thrown away when the rebuild arrives. Google’s site-move guidance advises changing only one thing at a time, such as the domain name, the content management system, or the layout. It was written for moving a site, but it’s a useful test for a project too. If one proposal bundles all three, ask whether the changes can be staged.
• Nobody can explain the constraints. Ask for a short assessment before you pick a route. It should name the pages reviewed, show a demonstration where useful, list the unresolved risks, and give a written scope.

The routes can also be mixed. A proposal can adapt some templates and replace others. Ask it to name which templates it will adapt and which it will replace.

What Changes the Effort?

Effort here means the amount of work in the scope. This guide gives no prices or timelines, because they depend on the details below.

For a retrofit, ask about:

• Whether styles and parts are shared or repeated page by page, and how many pages that covers.
• How many distinct templates the site uses, and how different they are.
• How fixed or table-based the layout is.
• How much wide content there is, such as images, tables, embeds, and long forms.
• How complex the navigation is.
• Whether the team can edit the templates or theme.

For a rebuild, ask which of these are included:

• Content migration and cleanup.
• Mapping and redirecting page addresses.
• A platform or web hosting change.
• Connected services and forms that need reconnecting.
• Setting up shared styles and reusable parts, if the proposal includes them.
• New design work.
• Running the old and new sites in parallel, and testing before launch.

Both routes need testing at several widths and a site your team can keep updating. Ask each team which of these apply to your site and which are in its scope. Two proposals with different answers are describing different projects.

If Page Addresses Change, Plan for a Site Move

A retrofit that adapts templates in place keeps your page addresses (URLs), so it isn’t a site move. Any proposal that changes addresses, whatever it’s called, is one. Google’s site-move guidance lists the work: prepare a mapping from each current address to its new one, set up server-side permanent redirects from the old addresses to the new ones, update internal links, and monitor both sites. Google also says visibility in Search can fluctuate temporarily during a move, which it calls normal.

Not every rebuild changes addresses, so ask the team to say whether this one will. If it does, include the mapping, the redirects, and the checks in the scope, and ask who owns each.

Agree How You Will Know the Work Is Ready

Whichever route you choose, write the finish line into the brief before the work starts. These criteria describe what to agree with the team. They don’t replace the team’s own testing, and anything left over needs a named owner:

• The agreed page types and important journeys have been checked at the screen sizes you and the team agreed on.
• Content stays available and usable in each layout, with nothing important cut off or lost.
• Navigation, forms, and other essential controls work on a real phone.
• Wide data tables can be reached in full.
• Remaining exceptions are listed, each with an owner.
• If addresses change, the mapping and redirects have been checked. Where redirects go live only at launch, someone owns switching them on and checking them afterward.
• If the work adds shared styles or parts, the team can show where a change to one is made and which pages it reaches.
• Your team can update the result using its normal workflow.

Send each team the same brief: your evidence notes, the questions card, and these acceptance criteria. Ask each team to return its answers with the proposal so you can compare what each includes.

When the work is ready for review, use the pre-launch review for the full check, and see what a phone preview shows and what to check on a real phone for what to try on a phone.