How to Plan a Corporate Website Redesign Project? Scope, Content Inventory and Migration Checklist

In most companies, a corporate website redesign project starts out like a design job and ends like a data migration job. During the design phase everyone is excited: new colors, new visuals, a more modern homepage. Two weeks after launch, the agenda shifts. Organic traffic has dropped, some forms are not reaching the CRM, and when the sales team sends the link to an old product page, the customer lands on a 404.

The purpose of this article is to help you plan the redesign not as a visual refresh but as the combination of three separate jobs: the scope decision, the content inventory, and the URL/technical migration. If any one of these three is missing, the project either never finishes or, once finished, costs you more than it gains.

The numbers, tables and scenarios used throughout this article are explicitly hypothetical. Your own site’s page count, traffic distribution and technical infrastructure will change these figures significantly. The aim is to convey the decision logic, not to hand you a ready-made budget or timeline.

What should your redesign decision be based on?

The first question is not “how do we redesign” but “what is broken”. Projects that cannot answer this clearly end up reproducing the old problems on the new site.

In practice, a redesign request usually comes from one of the following five reasons, and each requires a different scope:

Visual aging and brand misalignment. The site does not reflect the company’s current corporate identity. The logo has changed, the color palette has been updated, but the site still looks the way it used to. This is usually the narrowest scope of work: the design layer is renewed and the information architecture is largely preserved. This expectation of alignment between corporate identity and the website requires the site to be consistent with the company’s physical presence and the service it offers.

Change in positioning and product. The company has entered a new segment, the product portfolio has changed, or it has moved from a single product to a platform. In this case the real work is messaging and information architecture. Design changes as a result of that new structure. In projects of this type, carrying the page structure over as is would be the biggest mistake.

Conversion performance. There is traffic, but forms are not being filled in and demo requests are not coming. Care is needed here: a conversion problem is not always caused by design. The offer may be positioned incorrectly, the target audience may be wrong, or the form may contain unnecessary fields. The analysis sources to consult before making this decision are analytics data, A/B tests, user surveys and heatmaps. Saying “let’s redesign the site and conversion will go up” without looking at this data is an expensive guess.

Technical debt. The CMS is old and cannot be updated, page speed is low, the mobile experience is broken, security updates are delayed. This is a platform change decision independent of design, and it often produces the riskiest migration, because the URL structure, form integrations and analytics setup all change at once.

Operational slowness. The marketing team has to wait two weeks for a single landing page, and publishing content requires a developer. This is a speed problem, and the solution is not a new visual language but a component system that lets an editor build pages on their own.

The practical benefit of separating these reasons is this: you determine up front how you will measure success at the end of the project. Expecting “let’s double the number of leads” from a redesign carried out because of technical debt is an easy way to declare the project a failure.

Redesign or incremental improvement?

Not every problem requires a full redesign. A rough distinction can be made as follows:

The distinction in the table is not clear-cut. In real projects more than one row applies at the same time. Even so, asking this question delays the “let’s rebuild everything from scratch” reflex by one step and clarifies where the budget is going.

Related reading: How to Prepare a Corporate Identity Guideline and Get Teams to Apply It

Defining the scope: what the project includes and what it does not

The most common budget and schedule overrun in redesign projects comes from the scope not being written down. The phrase “website redesign” corresponds to a different job definition in different people’s heads.

The scope document should give a clear answer to at least the following headings:

Page set. The list of pages to be renewed, one by one. Saying “corporate site” is not enough. Is the blog included? Career pages? Languages other than the main one? Old campaign landing pages? The help center? Producing this list is also the starting point of the content inventory in the next section.

Number of templates. Design cost scales not with the number of pages but with the number of templates. A typical B2B corporate site has 8 to 12 templates such as homepage, solution/product page, industry page, about us, blog listing, blog detail, resource center, contact and landing page. Discussing up front which components each template will consist of reduces the “this page does not look like the other one” debates.

Content responsibility. Who will write the copy? This is where projects are delayed most. Design is finished, development is finished, and six pages sit waiting with lorem ipsum. Is content production handled by the agency, by the company, or a mix of both? Is the number of hours the product specialist will dedicate written into the schedule?

Technical scope. CMS selection, hosting, form infrastructure, CRM integration, analytics setup, multilingual support, accessibility target, performance target. Each of these is a separate line item.

What is out of scope. This section is at least as important as the others. In-product interface, customer portal, e-commerce module, rewriting old blog posts, video production. Anything not put in writing as out of scope comes back in the middle of the project as “you will take care of this too, right?”.

Team and decision mechanism

Corporate sites have many stakeholders, and this is the main reason design rounds stretch on forever. Three roles need to be defined from the start:

• Decision maker: Who approves the design and the messaging? It should be a single person. Approval by committee produces an average site.
• Contributors: Sales, product, HR, legal. These people give opinions, not approvals. It should be clear at which stage their input will be collected.
• Implementers: Design, content, development, SEO.

Limiting the number of design rounds up front is also useful. For example, two revision rounds per template, with a third round priced as additional work. This is not rigidity but a method of disciplining feedback.

Timeline: what to expect and when

In projects run with an agency, managing expectations is as important as the timeline itself. The approach in Mochatouch’s digital marketing onboarding article recommends writing down both the output that can be expected and what should not be expected for each period (The First 90 Days With a Digital Marketing Agency). Carrying the same logic into a redesign project makes conversations with the management level noticeably easier.

The timeline below is purely illustrative and is based on the assumption of a mid-sized B2B corporate site (roughly 40 to 60 pages, blog included, single language). Page count, number of languages, integration complexity and content production capacity shift this table in both directions.

The last row is particularly important. Going live is not the end of the project; it is the beginning of the monitoring period. Teams that do not write this period into the schedule and budget from the start end up having to argue about post-launch issues as “additional work”.

Content inventory: the most skipped yet most decisive step of the project

A content inventory means listing every URL on your site in a single table and making a decision for each one. This step is tedious, which is why it gets skipped. When it is skipped, the result is this: the new site goes live, nobody knows where the 80 pages from the old site went, traffic from search engines disappears, and the links sales has been sharing for years break.

Which columns should the inventory table have?

The minimum set is as follows:

• URL: The full address.
• Page title and type: Product page, blog, resource, corporate, landing page.
• Organic traffic over the last 12 months: From your analytics tool. Tools such as Google Analytics are used to show which pages receive the most traffic.
• Number of conversions: How many forms and how many demo requests came from this page.
• Is it an entry page: Do users enter the site from this page, or do they arrive from within.
• Are there external links: Have other sites linked to this page.
• Content owner: Who is responsible for the accuracy of this page.
• Last update date.
• Decision: Migrate, rewrite, merge, delete, redirect.
• New URL: The target address if the decision is not “delete”.

This table is usually kept in a spreadsheet and becomes the single reference document of the project. The designer, the developer and the content writer all look at it.

Which of the five decisions should you make and when?

Migrate. The page is current, performs well and its message is right. It is carried over to the new design as is, and the URL is preserved. This is the cheapest decision and should be preferred whenever possible.

Rewrite. The page is needed but its content is outdated, its message does not match the new positioning, or it is simply very weak. The URL can be kept while the content changes.

Merge. If there are three pages covering the same topic at different depths, gathering them into a single strong page is usually better for both the user and the search engine. The URLs of the merged pages are redirected to the target page. When deciding to merge, choosing which URL will remain as the main page by looking at the one with the highest traffic and the most external links is a reasonable starting point.

Delete. The page is no longer valid: a discontinued product, a past event, an irrelevant announcement. If it has no traffic and no external links, it can be deleted. If it has traffic, it is not deleted but redirected to a relevant page.

Redirect. The page is being removed but it has traffic, external links or a history of being shared by sales. It is redirected to the closest meaningful page.

A hypothetical inventory example

The table below is an example imagined as if it were taken from the site of a fictional B2B SaaS company. The figures are made up for teaching purposes; they are not based on any customer data.

The practical lesson from this table is that the distribution of decisions is rarely even. On a typical site, the large majority of traffic and conversions is concentrated in a small number of pages. The most important function of the inventory is to identify those pages and make sure you treat them with special care throughout the rest of the project. Changing the URL of a blog post that brings 6,800 sessions over 12 months just so it “looks tidier” means taking on serious risk in exchange for nothing gained.

From inventory to information architecture

When the inventory is done, the page list you are left with is the raw material for the new menu structure. There are two traps here.

The first is copying the old menu as is. The old menu may reflect the company’s old organizational chart. A B2B buyer does not know your company’s departmental structure; they are looking for their own problem. Building the menu around whichever axis makes more sense to your buyer, whether problem, solution, industry or role, usually produces better results.

The second is trying to make room in the menu for every page. A menu is not an archive, it is a navigation tool. Pages that remain in the background are reached through internal links, search and the resource center.

When determining the site structure, the goal is for the visitor to reach the information they are looking for quickly. This structural decision also forms the basis of the XML sitemap; on the corporate SEO side, creating a sitemap and making it easier for search engines to understand the site are counted among the first technical SEO steps.

URL migration and technical preparation

This is the most technical and riskiest part of the project. A mistake in the design can be corrected afterwards. A mistake in the redirect map costs you traffic every day until it is fixed.

How do you prepare a redirect map?

The redirect map is the natural continuation of the inventory table: old URL, new URL, redirect type.

Basic principles:

Do not change a URL unless you have to. Every redirect is a small risk and a record that has to be managed. A new design does not require a URL change. A URL should change only if the information architecture has genuinely changed or if the current structure is meaningless (for example, if it is in the form ?p=1847).

Use permanent redirects. If a page has moved permanently, 301 is used. There is 302 for temporary situations, but a temporary situation is rarely the case in a redesign migration. (Redirects and Google Search — Google Search Central)

Avoid redirect chains. If page A redirects to B and B redirects to C, then A should point directly to C. This is especially common on sites that have already been migrated once before; old redirect rules need to be checked as well.

Do not redirect everything to the homepage. Redirecting all 30 deleted pages to the homepage is easy but it is a poor experience for the user. Someone looking for a product page who lands on the homepage will usually go back. If there is no closest meaningful page, showing a proper 404 page is a more honest solution.

Test redirects before launch. Checking them one by one in the staging environment or in a spreadsheet is cheaper than getting a surprise on launch night.

Technical items that need to be checked

Beyond redirects, here are the headings that get overlooked during migration and turn out to be expensive later:

• Form and CRM integration: Does every form create the correct CRM record with the correct fields? You should not go live without submitting a test form and seeing the record in the CRM.
• Analytics and conversion tracking: Is the tracking code present on every page of the new site? Have conversion goals been updated for the new URLs? Have the conversion tags of ad platforms been carried over? When this item is skipped, the post-launch performance discussion happens without data.
• Robots.txt and noindex: Have the rules placed in the staging environment to block search engines been removed at launch? This is the classic disaster of redesign projects: the site goes live, the noindex tag is forgotten, and within a few weeks the pages drop out of the index.
• XML sitemap: Has it been generated according to the new URL structure and submitted to the search console?
• Page speed and mobile compatibility: Page speed, mobile compatibility and the use of HTTPS are counted among the fundamental items of technical SEO. Heavy visuals in the new design may produce a slower result than the old site; this should be measured before launch.
• HTTPS and certificate: Especially if hosting is changing, it should be verified that the certificate works on the new server.
• Page titles and meta descriptions: Are the existing titles of migrated pages being preserved, or is the template automatically overwriting all of them?
• Internal links: Have the links given to old URLs from within body copy been updated? These work through redirects, but over time they create chains.
• Multilingual structure: Are the cross-language relationship tags (hreflang) set up correctly, and does each language’s counterpart point to the right page?
• Accessibility: Color contrast, keyboard navigation, alternative text for images. Corporate buyers, especially in public sector and large company procurement processes, may ask about this item.

Additional risks if the platform is changing

A CMS change noticeably increases the risk of a redesign project. During bulk transfer of blog posts, images can be lost, tables can break and custom formatting disappears. After the transfer, at the very least the highest traffic pages should be checked visually one by one.

There may also be integrations running on the old platform that nobody remembers: the form connection of an email tool, a live chat widget, a calendar embed code used by the sales team. An inventory of these is just as necessary as the page inventory.

Launch checklist

The list below contains the checks recommended to be carried out in order on launch day and afterwards. It is a suggested framework; items should be added or removed depending on the complexity of your site.

Before launch (in the staging environment):

1. All templates have been reviewed on desktop and mobile.
2. A test submission has been made from every form and its counterpart has been seen in the CRM.
3. Automated emails (thank you message, internal notification) are working.
4. The analytics code is present on all pages and appears in the real-time report.
5. Conversion goals and ad tags have been updated for the new URLs.
6. The redirect map is ready and has been tested at least for high traffic pages.
7. The 404 page has been designed and contains useful links.
8. Page titles and meta descriptions have been checked.
9. Page speed has been measured and compared with the old site.
10. A backup has been taken and a rollback plan has been written.

At the moment of launch:

11. The noindex tag and staging robots rules have been removed.
12. Redirects have been activated.
13. HTTPS and the certificate have been verified.
14. The XML sitemap has been updated and submitted to the search console.
15. The homepage, the five highest traffic pages and all conversion pages have been checked one by one on the live site.

The first week after launch:

16. Crawl errors and indexing status are being monitored in the search console.
17. 404 records are being checked daily and missing redirects are being added.
18. Sessions, page views and conversion counts in analytics are being compared with the previous period.
19. Feedback has been collected from the sales team: do the links they share work?
20. It has been verified that form submissions continue to reach the CRM.

The first three months after launch:

21. Organic traffic and ranking changes are being monitored on a page basis.
22. User behavior data (heatmaps, session recording) has been collected and reviewed.
23. A test plan has been prepared for pages with low conversion performance.

The last group is not the closing of the project but its continuation. The basic premise of the CRO approach is that conversion optimization is not a one-off operation and that regular data analysis and testing are necessary because user behavior and competition keep changing. The new site should be a better starting point for this cycle; not its end point.

How should you interpret a post-launch traffic drop?

Fluctuation in traffic after a redesign is normal. The real issue is being able to tell what kind of fluctuation it is. The hypothetical scenario below is meant to illustrate the interpretation logic.

Say that three weeks after launch, organic sessions dropped from 12,000 to 9,600 compared with the previous three weeks. A 20 percent decline. Before panicking, the questions to ask are these:

Which pages is the drop on? If the entire drop comes from the 30 blog posts deliberately deleted, this is an expected outcome and a cost that has already been accepted. If the drop is on the main product pages whose URLs were preserved, you should look for a technical problem.

Is the comparison period fair? Seasonality is strong in B2B. Comparing August with October is misleading. Where possible, look at the same period of the previous year as well.

Has indexing been completed? If URLs have changed, it takes time for search engines to crawl the new structure. Week three is not yet a period for a final assessment.

Is the measurement the same? If the analytics setup has changed on the new site, the numbers may be measuring different things. Settings such as bot filtering, excluding internal traffic and session definition may have been set up from scratch.

A verdict of “the redesign reduced traffic” given before these four questions are answered often leads to the wrong action. The right first action is to produce the page-level breakdown of the drop and see whether that breakdown matches the decisions in the inventory.

In the same way, the cause of a drop in conversions may not be the design. A field on the form may have become mandatory, there may be a loss in the data flow to the CRM, or the thank you page may not be counted as a conversion. Design should not be blamed before technical verification is done.

Common mistakes

This section is not a collected summary of the risks indirectly touched on in the previous sections; these are behavior patterns that deserve to be discussed separately.

Starting with design. In projects where design begins before the inventory and information architecture are done, the design is usually done a second time. Because once the page structure becomes clear, it turns out the templates are not sufficient.

Leaving content to the last week. Content production is the slowest part of projects and the one with the most dependencies. Getting the product specialist’s input, obtaining legal approval and asking a reference customer for permission take weeks. Setting up the content calendar at the start of the project and tying it to a regular rhythm makes this work manageable; the observation that what usually disrupts the rhythm in content production is not new information but a lack of planning discipline applies here too (B2B Content Calendar).

Shutting down the old site immediately. Being able to access a copy of the old site (in a non-public form) for at least a few weeks after launch is valuable for finding a piece of content that has gone missing.

Treating measurement setup as the last step of development. Analytics, measurement and CRM integration are not tasks to be handled on launch day with a “let’s add this too”. These are functions that need to be tested.

Not defining success. If what will be looked at when the project is finished is not written down at the start, the evaluation is made according to everyone’s own expectations. As well as what the metric is, when it will be measured should also be written down. In a redesign carried out because of technical debt, looking at page speed and publishing speed three months later makes sense; looking at conversion rate is usually too early.

Changing everything at the same time. If design, content, URL structure, CMS and hosting all change at once, it becomes difficult to find the cause when a problem appears. Where possible, separating the platform migration from the design refresh preserves your diagnostic ability. This is not always possible, but when it is, it provides a serious advantage.

Where should you start?

If you do not yet have a scope document, the order could be as follows:

First, write the rationale for the redesign on a single page: which problem, which evidence, what we will look at after the project. Then produce the content inventory; this step alone shows you the real size of the project and usually reveals a picture different from the first estimate. When the inventory is done, write down what is in scope and what is out of scope, identify the decision maker, and build the timeline stage by stage.

Once these three steps are complete, the conversation you have with an agency or an internal team changes qualitatively. Instead of the sentence “we want to redesign our site”, you sit down at the table with a brief that includes how many pages will be migrated, how many templates are needed, which integrations must be carried over and how success will be measured. This brief directly affects both the quality of the proposals and the result you get at the end of the project.

Frequently Asked Questions

How long does a corporate website redesign project take?

Giving a general duration would be misleading, because what determines the timeline is not so much the number of pages as the number of templates, content production capacity, the number of languages and integration complexity. The soundest way to estimate the duration is to handle the stages separately: inventory and scope, information architecture, design, content, development, migration and post-launch monitoring. Identify up front which of these stages will be your bottleneck. In most B2B companies that bottleneck is content production, not design.

Should we change our URLs during the redesign?

Not unless you have to. A new design does not require a URL change. Change a URL only if the information architecture has genuinely changed, if the current structure is meaningless, or if pages are being merged. For every URL you change, set up a permanent (301) redirect, do not create redirect chains, and test the redirects before launch. Specifically not touching the pages with the highest traffic and the most external links is the easiest risk reduction decision available to you.

Can the project start without producing a content inventory?

Technically it can, but that means committing to a budget and a timeline without knowing the real size of the project. Without the inventory, you do not know which pages will be migrated, which will be rewritten and how many redirects will be needed. You also have no reference point for interpreting the traffic change after launch. The inventory is the project’s cheapest insurance.

What should we do if traffic drops after launch?

First produce the page-level breakdown of the drop. If the drop comes from pages that were deliberately deleted, this is an expected outcome. If it comes from important pages whose URLs were preserved, look for a technical problem: a noindex tag may have been left in place, a redirect may be missing, or the analytics setup may be measuring differently. Also check whether the comparison period is seasonally fair. If the URL structure changed, indexing takes time to settle; the first few weeks are too early for a final assessment.

If our conversion rate is low, will a new site solve this problem?

Not always. The source of a conversion problem may be the design, but it may equally be the offer itself, the wrong target audience, the length of the form or the clarity of the message. Before deciding on a redesign, looking at analytics data, user behavior and, where possible, user feedback helps you make sure you are solving the right problem. Also, conversion improvement is not a one-off project but a continuous cycle of testing and measurement; a new site can be the start of this cycle, but it cannot replace it.

How do we speed up the decision process in the project?

Designate a single decision maker and announce this person in writing from the start. Position the other stakeholders as contributors; tell them in advance at which stage and in which format you will collect their input. Limit the number of design revision rounds and collect feedback in one place rather than across scattered channels. In corporate projects, the place where the timeline slips most is not production but waiting for approvals.

Note: All numerical examples, tables and scenarios in this article are explicitly hypothetical teaching examples. They are not based on a real customer project, a measured result or an industry average. Work with your own data for the scope, timeline and risk profile of your own project.