Prepare a website redesign before the design work

Start with the reasons someone visits your site. They may want to understand your offer, check whether you work in their region, prepare a request or open their client space. Write these tasks down with concrete verbs. “Modernize our image” expresses an intention, but it isn’t enough to decide which pages to keep or which buttons to put in the menu.

For each task, sketch a simple journey: the landing page, the information expected and the next action. Ask yourself what the visitor needs to know to move forward without calling you. A service page can explain who the offer is for, its scope, its limits and its availability. A login area must lead to real authentication, with planned behaviour for people who don’t have an account yet.

Next, build the page inventory. Note each page’s address, role, owner and planned action: keep, fix, merge or remove. Add the forms, downloadable documents and features that aren’t visible from the home page. A quote can then specify what belongs to the website project and what concerns a separate application or system.

Set the project’s limits before you compare proposals. A visual redesign, a content reorganization and the replacement of a client space are different kinds of work. List what must work at delivery and what will be decided later. For each postponed item, plan what the visitor will see in the meantime, so that no button promises a feature that isn’t there.

Finally, confirm the availability of the offers presented. An old page doesn’t prove that a service is still sold on the same terms. Check the plans and their availability, then have any information specific to your project confirmed. The content will need to distinguish what can be requested now, what is quoted per project and what remains unavailable.

Create a preparation space with one entry for each planned page. Gather the text, images, contact details and information needed to answer its main question. Indicate the status of each item: usable, to review, to produce or waiting for a decision. Missing content then becomes a visible task instead of being discovered when the layout is almost finished.

For business facts, name a person who can confirm the scope of the services and their terms. For contact details, check which contact addresses are actually monitored. For photos and illustrations, record their origin and the usage permission you hold. If an item remains uncertain, keep that uncertainty in the preparation file and remove the item from the version meant for publication.

In a fictional example, a business has several versions of a service description. An old document describes a complete service; a recent note narrows its scope. The writer shouldn’t pick the most flattering version. They need to ask which offer is the reference, who confirmed it and which passages need to be updated elsewhere on the site.

Plan a way to comment on the pages. Comments should name the passage concerned, the problem and the expected change. “I don’t like this page” calls for a new interpretation. “This sentence suggests that follow-up is included; its scope needs to be clarified” makes it possible to deal with a substantive decision. Keep the comments and the reviewed version together to avoid contradictory corrections.

Also define who settles disagreements and who gives final approval on the facts. Visual preferences, service terms and technical questions don’t necessarily belong to the same person. The guide to organizing your business documents helps you set up this flow. An approval must cover a specific version, with its text and images, before publication.

Before renaming pages, keep a list of their current addresses. Add the links found in your emails, documents and public profiles when you know them. A page can be barely visible in your menu while still serving as the destination of an old proposal. The inventory helps you decide whether it should stay accessible, be replaced or disappear with an appropriate message.

Build a mapping between each old address and its destination. If a new page meets the same need, note that link. If several pieces of content are merged, indicate which page actually takes over their information. Google recommends preparing this mapping and checking the redirects during a site move with URL changes (new tab). Avoid redirecting all old pages indiscriminately to the home page.

Next, choose the addresses for the public site and for the application, if there is one. Indicate which domain will be the primary one and how the other addresses will lead to the right place. Take inventory of the features tied to the domain: login, email links, forms, downloads and any connections to outside services. A visible name change can require settings in places other than the menu.

Decide who should be able to open the preview. A hard-to-guess address is not an access control method. If the pages are reserved for testers, plan appropriate authentication. The indexing instruction is a separate setting: Google explains how the noindex rule prevents the indexing of content its crawler can access (new tab). It doesn’t replace a protected entrance.

Keep a list of the settings specific to the preview and of those expected for publication. Specify who can authorize changing them. For pages meant for search engines, the guide to preparing an SEO audit helps you gather the useful observations. It lets you tell a deliberate protection of the preview apart from an unintended obstacle on the public site.

Write the test scenarios before delivery. For example: find a service, understand its availability, reach the right offer and start a request. For an existing client, add the journey from the home page to the real login. Note the expected result at each step. A page that displays doesn’t prove that the form works or that its recipient gets the message.

Check these journeys on a computer and on a phone. On a narrow screen, look for cut-off text, buttons that are hard to reach and information pushed behind a large illustration. Open the menus, use the keyboard and look at the error messages. Tests must cover the page’s real elements, because an overflow can be hidden without the content becoming usable.

Test the old addresses listed in your table, the downloads and the links between pages. Also have the titles, descriptions, contact details and business information proofread. For an action that sends a message or creates a record, use the authorized test path and confirm what was sent. A demonstration shouldn’t trigger unexpected messages to real clients.

Rank the fixes by their effect on the journey. An inaccessible login, a wrong recipient or an offer wrongly presented as available must be dealt with before the task is considered done. Presentation tweaks remain useful, but they must not hide these defects. For each fix, note the page, the expected result and the person who will check the change.

Finally, keep an understandable delivery status: what was built, what was checked, the points still open and the address everyone should use. Separate agreement on the content from the decision to publish. Your team can then review a concrete result, with its journeys and its limits, instead of having to guess what the word “done” covers.

Let’s scope your redesign together.