Direct answer: Decide who speaks to whom before choosing domains and pages. A single group site, subdirectory, subdomain or separate site depends on brand, customer and operating boundaries. Acceptance covers domains/URLs, content ownership, CMS permissions, inquiry routing, analytics/consent, migration and rollback—not just assembling several factory pages.
This guide is for general managers, brand/marketing, plant leads, export/sales, IT, legal and website vendors at Changzhou group manufacturers. It covers how to plan, launch and accept multi-plant/multi-brand sites. Information is current to 30 October 2026. It is public search documentation, platform rules and project method, not a ranking, traffic or inquiry promise; the architecture, domains, contracts and technical plan are confirmed case by case.
Define brand/customer/operating boundaries before domains. One page serves one primary intent. Put content owners, CMS permissions, inquiry ownership and analytics definitions into acceptance. Migrate with 301 + canonical + sitemap, not "resubmit and hope".
Many Changzhou manufacturing groups have a group brand, plants, product brands, export sites and distributors at the same time. Putting everything into one site can make the group introduction complete but hide the right plant from the buyer; giving every plant/brand its own site can create duplicate content, scattered domains and unclear inquiry ownership. The core of a multi-plant/multi-brand site is not "more"—it is boundaries and evidence.
When do you need a group site rather than one big website?
Start with brand, customer and operating boundaries. A shared audience fits one group site; unified operations fit a subdirectory; independent brands/businesses may justify a subdomain or separate site, but each adds content and domain cost.
Draw an "object—audience—operations" table: group, plant, product brand, export market, distributor—who they speak to, who owns content, who receives inquiries. If audience and sales paths overlap heavily, a group site with plant/brand subdirectories is usually easier to maintain; if positioning, customers, domain assets or teams are independent, a subdomain/separate site may fit. There is no universally "best" architecture, only clear boundaries.
| Architecture | Fits | Cost/risk | Acceptance focus |
|---|---|---|---|
| Group site + plant/brand subdirectories | Shared customers, unified brand, central operations | Content blurs; plant/brand identity weaker | Directory/navigation/content ownership |
| Group site + subdomains | Plant/brand has an independent product line or team | Authority/operations split; duplicate content | canonical/cross-links/permissions |
| Separate domains/sites | Independent positioning, customers, domain assets | Higher cost; group relationship must be clear | Entity/brand/cross-links/contracts |
| Multilingual subdirectories/subdomains | Export/overseas markets | Translation/localisation/compliance cost | hreflang/local content |
The architecture comparison is editorial; the choice depends on brand, customers, team, budget, domain assets and contracts. No architecture is promised to bring rankings or inquiries.
How should domains, URLs and SEO be divided?
One primary intent maps to one primary URL. Subdirectories, subdomains and separate domains need clear rules, canonical and cross-links. Use hreflang for language/region versions, not to force multi-brand/multi-plant pages together.
Multi-site projects easily create multiple URLs for the same product/plant page. Define URL rules first: group page, plant page, product line, application/industry, news/case. Use stable prefixes for subdirectories (e.g. `/plants/`, `/brands/`) and keep plant/brand names out of query parameters. Use canonical for duplicates/variants, but canonical is not a substitute for 301; migrate old URLs with one-to-one 301. Use hreflang for language/region versions; multiple brands/plants in the same language market do not need hreflang.
| Issue | Rule | Evidence | Common mistake |
|---|---|---|---|
| Primary URL | One intent per main page; plant/brand pages do not copy the group page | URL list, keyword map | Same content on multiple domains |
| Subdirectory/subdomain | Stable, readable, migratable; no plant names in parameters | URL spec, sitemap | A new parameter set per plant |
| canonical | Duplicates/variants point to the main version; self-reference correct | Source, crawl test | Wrong canonical/all to home |
| 301 | Old URL to new URL one-to-one; keep long enough | Redirect map, curl log | All to home/multi-hop |
| hreflang | Language/region versions annotate each other; x-default | hreflang table, source | hreflang for multiple brands |
| sitemap/robots | Only canonical versions; do not block CSS/JS/important pages | sitemap, robots | Old/test sites indexed |
URL/SEO rules reference Google URL structure, canonical, hreflang and Baidu's site-migration guide; crawling/indexing/ranking are not promised.
How should content ownership and CMS permissions be divided?
Group, brand and plant each need a content owner, approver, publishing permission and shared-component rules. CMS roles use least privilege: the group owns brand/navigation/legal, plants own products/cases/local information.
Multi-site failure is often not technology but "anyone can change anything". Group brand pages, plant pages, product pages, cases/certificates, recruitment and news each need an owner and approver; shared navigation, footer, brand colours and legal/privacy text are centralised, while plants/brands edit only their products, capacity, cases and local contacts. CMS roles separate editor, reviewer, publisher and admin; revoke outsourced/former/distributor accounts promptly.
| Content | Owner | Approval/permission | Evidence |
|---|---|---|---|
| Group brand/navigation | Group brand/marketing | Group review; plants read-only | Brand guide, permission table |
| Plant profile/capacity | Plant lead/marketing | Group brand + legal spot check | Plant confirmation, version |
| Product/specs | Product/engineering | Product manager review | Spec table, version |
| Cases/certificates | Sales/quality | Customer authorisation/legal | Authorisation, certificate |
| News/events | Group/brand marketing | Brand review | Publish record |
| Recruitment/local contact | HR/plant | Group HR/IT | Job/contact list |
| Privacy/legal | Legal/compliance | Group central | Policy version, consent record |
RACI/permissions are editorial; specific owners, approvals and account permissions depend on the organisation, contracts and systems.
How should inquiries, CRM and analytics be divided?
Route inquiries by plant/brand/country/product; form fields and CRM owner must distinguish the source. Track events/UTM in GA4/Baidu Tongji; do not mix group, plant and distributor inquiries into one "lead count".
Multi-plant/brand sites often send every inquiry to the group inbox, where nobody owns it. Forms should distinguish group partnership/plant quote/brand enquiry/distributor/after-sales, and route by plant/brand/country/product, recording source page, UTM, language and product in CRM. Analytics should separate properties/events/channels, with cookie/consent by region; do not use one total inquiry number to hide a plant/brand with no leads.
| Item | What to do | Evidence | Common failure |
|---|---|---|---|
| Form fields | Group/plant/brand/distributor/after-sales; product/country/quantity | Field table, test submission | Only one "message" box |
| Routing | By plant/brand/country/product; backup owner | Routing table, SLA | Everything to group inbox |
| CRM | Source page/UTM/language/product; deduplicate | CRM fields, sample | Name/phone only |
| Analytics | GA4/Baidu Tongji by property/event; key events | Event table, debug | Pageviews only |
| Consent | Cookie/form consent by region; revocable | Consent record, policy | Pre-ticked boxes |
| Attribution | Group/plant/brand lead quality and deals separately | Reports, CRM | One total lead target |
The inquiry/analytics checklist is editorial; fields, routing, CRM, consent and attribution depend on systems, regions and contracts. No lead or deal volume is promised.
How should migration/launch be accepted?
Inventory old URLs/content/backlinks, then do one-to-one 301 mapping, canonical, sitemap, form/analytics tests and rollback. A visual-only redesign still affects crawling; domain/directory changes follow the migration process.
Launching a multi-plant/multi-brand site often involves new directories, subdomains, separate domains and old-site migration at the same time. Inventory old URLs, traffic entry points, backlinks, forms and analytics, then map 301; new pages self-canonical, sitemap includes canonical versions only, robots does not block important resources; test forms/CRM/analytics/consent before launch. Baidu's migration tool is for domain/directory changes, not content/style-only redesigns; keep 301 relationships for at least three months, until the new site stabilises.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| URL inventory | Old URLs/entries/backlinks/forms listed | Crawler/log/backlink list | Complete inventory/delay |
| 301 mapping | One-to-one, single hop, none to home | Map, curl | Fix/rerun |
| canonical | New pages self-canonical; variants to main | Source/crawl | Fix template |
| sitemap/robots | Canonical only; CSS/JS not blocked | sitemap, robots | Rebuild/fix |
| Forms/CRM | Test submission reaches the right plant/brand; notification works | Test ticket, screenshot | Fix routing/retest |
| Analytics/consent | Key events, UTM, consent records work | Debug, reports | Fix code/policy |
| Rollback | Old site/directory can roll back; DNS/TTL controlled | Rollback drill | Delay launch |
The migration/launch checklist is editorial; 301/canonical/hreflang/sitemap rules depend on search documentation, platform tools and the technical plan; indexing, ranking and traffic are not promised.
How should the work be sequenced over 90 days?
Weeks 1–2 define objects and boundaries; weeks 3–4 IA/URL and content owners/permissions; weeks 5–6 templates/forms/analytics; weeks 7–8 migration testing; weeks 9–12 phased launch and review. Do not design the homepage before deciding plant/brand splits.
A multi-plant/multi-brand site suits phased launch: pilot one plant/brand to validate templates, permissions, inquiry routing and analytics; then replicate to other plants/brands; finally the group home and cross-links. Each batch needs a content freeze, 301 map, testing and rollback; do not switch every site/domain at once.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Inventory group/plant/brand/market/domains/old sites/inquiries | Object table, boundaries, risks | Group/IT |
| Weeks 3–4 | Decide architecture, URLs, navigation, content owners and permissions | IA, URL spec, RACI | Brand/IT |
| Weeks 5–6 | Build templates/shared components/forms/CRM/analytics/consent | Prototype, fields, events | IT/marketing |
| Weeks 7–8 | Pilot plant/brand content, 301 mapping, testing | Pilot site, test record | Plant/marketing |
| Weeks 9–10 | Phased launch; monitor crawling/forms/analytics/errors | Launch log, monitoring | IT/marketing |
| Weeks 11–12 | Review; fix content/permissions/cross-links; next iteration | Review, iteration plan | Group/brand |
The 90-day plan is an editorial suggestion; architecture, content, migration and launch timing depend on the company, vendors and business window.
Acceptance checklist
Accept eight items: objects/boundaries, domains/URLs, canonical/hreflang, content ownership/permissions, inquiries/CRM, analytics/consent, migration/rollback and cross-links. Each needs an owner and evidence; tick before launch.
The checklist can be shared by group brand, plants, export/sales, IT, legal and vendors. The pass standard is not "the pages look consistent"; it is that every plant/brand can find its customers, content has an owner, inquiries have a recipient, data can be separated and old URLs can roll back.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Objects/boundaries | Group/plant/brand/market audiences, content and sales boundaries clear | Object table, RACI | Add boundaries/narrow scope |
| Domains/URLs | Primary URL unique; subdirectory/subdomain rules stable | URL spec, sitemap | Change rules/redirect |
| canonical/hreflang | Self/main version correct; language/region annotations correct | Source, crawl | Fix template |
| Content/permissions | Owner/approval/CMS roles/account removal clear | Permission table, logs | Revoke/fix process |
| Inquiries/CRM | Route by plant/brand/country/product; backup owner | Test ticket, CRM | Fix routing/train |
| Analytics/consent | Key events/UTM/consent work; reports by object | Event table, reports | Fix code/policy |
| Migration/rollback | 301 one-to-one; rollback drill passes | Map, drill | Delay/fix |
| Cross-links/brand | Group/plant/brand links clear; no entity/promise confusion | Link table, brand guide | Add links/fix copy |
The acceptance checklist is editorial; domain/URL/permission/migration/analytics requirements depend on the organisation, contracts, search documentation and platform tools.
Who should read this, who should not, and what decision does it support?
It fits Changzhou group manufacturers with multiple plants/brands/export sites. It does not fit a single-brand/single-site company, a team without independent operations, or a project unwilling to govern content and permissions.
Who should read: group general managers, brand/marketing, plant leads, export/sales, IT, legal and website vendors; companies building a group site, multi-brand site, plant subsite, export site or old-site migration; teams deciding "one site or many, subdirectory or subdomain, who owns content/inquiries". Who should not: a single brand/plant with one operating team; projects without content owners/permissions/migration budget; teams wanting multi-site to "cover keywords" or copy city pages. Decisions supported: architecture, domain/URL rules, content/permissions, inquiries/CRM/analytics, migration/rollback, a 90-day plan and launch acceptance.
Lingyi Information is a website and enterprise AI project services company, not a domain registrar, search engine or law firm. This article does not replace domain/contract/legal advice and does not promise indexing, ranking, traffic or inquiries. Changzhou projects are confirmed case by case for remote or on-site work; Lingyi is one candidate, not a local office/team.
FAQ
Should a group site use subdirectories or subdomains?
Look at brand/customer/operations. Shared customers, unified brand and central operations usually make subdirectories easier; independent product lines, teams or domain assets may justify subdomains/separate sites. Neither guarantees rankings; content, links, technology and operations are the variables.
Should multiple brands have separate domains?
If positioning, customers, sales teams or domain assets are independent, separate domains/sites may be reasonable, but you take on multiple content, SEO, analytics, contract and operations costs. Make the group relationship, cross-links and brand authorisation clear so users do not think they are different companies.
Will multiple plant pages duplicate or compete?
Yes, if every plant page copies the group profile/specs and only changes the city. Plant pages should show their own lines, process, capacity, certificates, cases and contacts; handle shared content with canonical/cross-links, not by copying one page to multiple domains. Do not use multi-site to mass-produce city×service templates.
Who owns the inquiry?
Route by plant/brand/country/product; forms and CRM record source page/UTM/language/product. A group inbox can be the entry point, but needs routing rules, backup owners, SLAs and dispute handling. Do not put every inquiry in one inbox or use total leads to hide a plant/brand with none.
How do we migrate an old site without losing traffic?
Inventory old URLs/entries/backlinks/forms, do one-to-one 301 mapping, canonical, sitemap, form/analytics tests and rollback; follow Baidu's migration tool/Google site-move guidance for domain/directory changes and keep 301s long enough. Do not send all old pages to the home page, and do not treat "resubmission" as a guarantee of indexing/ranking.
Do multilingual/multi-region sites need hreflang?
Yes, for language/region versions—not for multiple brands/plants. Each language/region version needs corresponding content and cross-links, with x-default for the default version. hreflang is not a ranking tool; content/localisation/technical quality still matter.
Bottom line
For a Changzhou group manufacturer's multi-plant/multi-brand site, define brand/customer/operating boundaries first, then choose one site/subdirectory/subdomain/separate site. One intent per primary URL; accept content owners, CMS permissions, inquiry routing, analytics/consent and 301 rollback. Multi-site is not keyword coverage—it helps each plant/brand find its own customers.
Method and limits
This article is public search documentation, platform rules and project method, not a ranking/traffic/inquiry promise or legal advice for any company, domain, brand, site or contract. It uses no unpublished client sites, domains or contracts. Architecture, tables and the 90-day plan are editorial suggestions; domains/URLs/permissions/migration/analytics/contracts depend on the company, search documentation, platform tools and legal counsel.
Sources
Information is current to 30 October 2026; each official/primary page governs its own rules and version.
- Google Search Central, URL structure: developers.google.com. Readable URLs, parameters, subdirectory/subdomain and multi-region structure.
- Google Search Central, Consolidate duplicate URLs (canonical): developers.google.com. Canonical usage and limits.
- Google Search Central, Localized versions (hreflang): developers.google.com. Language/region versions and x-default.
- Baidu Search Resource Platform, "Website redesign" FAQ: ziyuan.baidu.com. 301, the migration tool, old/new URLs and keeping redirects.
- Schema.org, Organization: schema.org. Structured-data fields for group/brand/plant entities; no display or ranking guarantee.