Merging Subsidiary Websites into a Group Website: What Should Happen to Old Domains and Product Pages?

When merging multiple websites, first confirm whether customer tasks served by the old websites can still be completed on the new one. Then decide which domains to retire and which to retain. Sharing a group name or admin system does not establish that all products, languages and contact routes should be merged. Nor should every old product URL be sent to the group homepage.

Integration can begin when the business can explain each website’s operating entity and supply relationships, identify people who can confirm product information, control the required old domain and website configuration permissions, and assign maintenance responsibility for the migrated pages. If these conditions are not yet met, navigation and brand entry points can be unified first while old websites remain connected.

When retaining independent websites is more suitable

Assess each subsidiary’s customers, products and service model separately. Integration can be considered when customer groups and information tasks are similar, one team maintains them continuously, and the new website can clearly explain the products and receiving organization. If websites only look similar while product configurations, regional supply and inquiry processes differ substantially, one website may make decisions harder.

Reasons to retain an independent website include:

• A brand still serves a particular customer group independently, and its old name is an important way to identify its products.
• A local team maintains different languages, supply coverage and inquiry handling that the group cannot yet support.
• The old website serves after-sales or customer information tasks for which the new website has neither corresponding functionality nor an owner.
• Information identities, publication scope or relationships between products remain unconfirmed, so merging would create inaccurate statements.

Retention does not mean leaving duplication unmanaged. Specify how group navigation leads to each website, which team updates which content, and who supplies the adopted version of shared materials. Base the decision on whether customers can complete their tasks, not on minimizing domain counts.

A page-by-page destination matrix must record both URLs and business entities

Export pages, downloadable materials and important external entry points separately from each old website. Do not first combine them into a list containing only paths: different domains may both have /products/item while referring to different products. Sitemaps, access records, links frequently shared by business staff and sales materials can together fill gaps in the inventory.

For each item, record at least the old domain and full URL, original website entity, product or material identity, language and market conditions, the customer’s original task, proposed new page, retention or migration method, confirmer and verification result. Leave unconfirmed destinations pending instead of filling every blank with the homepage.

For example, suppose websites A and B have similarly named products. Website A’s old materials still serve existing equipment, while website B’s page describes a different configuration. Do not merge their URLs into one page based on matching titles. Have the product owner confirm the relationship, then decide whether to keep them separate, explain their version relationship or genuinely combine the content.

A complete matrix lets the next participant find the original entity, new destination and confirmation basis from the record. Use the website redesign migration checklist to inventory materials for one website; a multi-site project also needs domain and operating-entity identities.

Give old entry points one of four explainable destinations

Keep them available. The independent website continues serving the business, with usable pages and an identified maintainer. Do not decide to retain it while simultaneously forcing all its URLs to the group website.

Migrate to corresponding pages. The new website genuinely continues to explain the same entity and task: old product pages map to new product pages, and old materials map to applicable material entry points. For permanent moves, the technical team can use server-side permanent redirects. Google’s redirect documentation explains the purpose of these signals.

Consolidate into a new page that fully supports the original tasks. Several old pages can share one new destination if its content actually covers their related tasks. Google warns that bulk redirects to an unrelated homepage may be treated as soft 404s. A shared destination is justified only after related content has genuinely been consolidated. Website migration guidance

Remove without a replacement page. When content has been deliberately withdrawn and no related replacement exists, the technical team should confirm an appropriate 404 or 410 response and check messaging at old entry points and related internal links. Unconfirmed products must not be placed in this category without authorization. “Materials are not yet complete” and “the business has stopped” are different states.

Plan cutover by old website rather than treating all domains as one task

The cutover plan should specify which old website enters the new structure first, which remain temporarily, who freezes the adopted version before switching, and how new products and inquiry records are handled during the transition. If a first batch is used for verification, avoid continuously updating the same product in two locations without an identified current version.

Google’s Change of Address tool guidance recommends caution when several websites move to one location at the same time; consider moving them individually and waiting for the changes to settle. An authorized person should check the tool’s prerequisites and scope. The Change of Address tool is not used for path changes within one domain or switches between www and non-www.

Migrating old websites one by one is different from splitting one website into many small launches. Plan batches around website size, technical conditions and business risks. “In batches” is not a fixed rule for every website. Each batch needs clear start and completion conditions and a person responsible if it fails.

Test from the old domain through to the correct recipient

Testers should open actual old entry points in the matrix and check the final page’s product identity, language, material version and contact entity. Also try a parameterized link, an old downloadable file, and a common entry point from email or printed materials. These cannot be found by checking the new menu alone.

The technical team should separately check that domain variants, certificates, redirect targets, internal links, canonical URLs and sitemaps use the confirmed addresses. Use the verification and monitoring steps after a domain change for ongoing configuration matters. After cutover, monitor errors and search changes separately for each old website so group totals do not hide a subsidiary’s problems.

If JVDS Design Studio is commissioned to participate in website redesign and content migration, domain scope, page mapping, factual confirmation and migration acceptance can be included in the agreement between both parties, with implementation tasks confirmed individually.

Completion means old entry points in the selected scope have reasonable destinations, materials correspond to the receiving entity, unmigrated parts still have maintainers, and exceptions can be traced to a particular old website and page. This demonstrates that business paths and configurations have been checked. Search systems still need time and observation to process the migration; it does not justify promising stable rankings.

Frequently asked questions

If two subsidiaries have products with the same name, can they be merged directly into one page?

First confirm product identity, configuration, material version and receiving entity. Matching names do not mean the same entity. Merge only when the new page can accurately support the related tasks.

Once the group website launches, can we stop maintaining old domains?

Old domains still require management if they support redirects or retained services. Check migration records, frequently used external entry points and maintenance agreements before deciding how to retire them. Do not disable them merely because the new website is live.