Moving three brand-site release tracks forward on the same day can sound like “AI generated three pages at once.” That is not the method worth keeping; the headline does not replace each site’s own release evidence.
A more accurate account is this: each brand keeps its own facts, while development can run in parallel. Production still moves through its own verification, stop gates and rollback point for each site. AI helps a team see what must be checked, what must stop and what a person must decide.
Start with facts and brand boundaries
Each brand needs its own answers: its name, scope, current capabilities, plans, public entry point and what must remain private. AI can organise scattered material into a list to verify; it must not turn plans, guesses or one product’s status into a fact about the whole brand.
What is shared is not a single brand look. Colour, typography, visual language, voice and business boundary remain specific to each brand; the method for checking them can be shared.
Keep one source of truth for design and content
Page copy, logos, fonts, asset provenance, cross-site links and environment settings need a clear owner. That makes it possible to see the single edit source and which pages, language versions and structured data will be affected.
A single source of truth does not turn three sites into one template. It prevents one brand from presenting conflicting names, capabilities, links or assets across its pages.
Stabilise the page shell and public quality contract first
Headers, footers, mobile navigation, anchors, 404s, responsive layout and accessible behaviour should be stable before pages accumulate content. Mobile is not a scaled-down desktop: reading order, touch targets, focus, horizontal overflow and content hidden by sticky elements all need their own check.
SEO is not a few tags added at the end. Titles, descriptions, canonicals, hreflang, structured data, robots, sitemaps and internal links must agree with the real language version and runtime environment.
Separate privacy, indexing and business entry points
A public site, a signed-in application, an internal platform and a preview environment cannot be one shared entry point. Forms, accounts, uploads and client material each need their own privacy and access boundary; a preview must not be indexed by mistake, and a production page must not carry a preview canonical.
When an asset’s provenance or public permission is unclear, the safer choice is not to use it. This article therefore uses text and the site’s existing layout rather than unapproved screenshots from the three sites.
Give automation and human judgement different jobs
Automation is good at repeatable checks: syntax, builds, broken links, unknown routes, one H1, asset loading, horizontal overflow, navigation state, sensitive-data scanning, and consistency across metadata and schema. These checks make gaps visible sooner.
Human judgement must not be swallowed by automation. Whether a brand expression is accurate, a fact is complete, an asset may be public, a mobile page is genuinely usable, or a change may enter production remains a human responsibility.
Develop in parallel; release production one site at a time
Three sites can prepare facts, pages, tests and release work at the same time. Their domains, index policies, forms, privacy boundaries, application entries and rollback points still differ; evidence for one site cannot clear another.
Each site therefore keeps the same six evidence layers in order: source, build, runtime, public web, browser or device, and status writeback. The next layer begins only after the current layer and current site are confirmed.
- Stop when facts or permission are unclear.
- Stop when privacy, indexing or environment settings conflict.
- Stop when mobile, accessibility or a key entry point fails.
- Stop when the live version cannot be proved or no rollback point exists.
A launch must be provable—and reversible
A successful upload, one HTTP 200, an attractive screenshot or a passing test each answers only one layer. Before release, the build artifact, actual live version, index policy, browser result, known unfinished work and a defined rollback version all need to be traceable.
When something fails, first locate its layer: source, build, runtime, domain, cache, browser or device. Repeated publishing is not diagnosis; explicit versions and stop gates make release recoverable.
Keep observing after release, then write status back at the source
The public web is not the end of every follow-up. Real devices, embedded browsers, search crawling, form paths, caching, legacy-entry migration and analytics can reach different conclusions at different times, and should stay separately recorded.
This method update keeps one unfinished boundary visible: the existing official YANFAMI site remains accessible; the unified-index revision for YANFAMI remains a source candidate, with its deployment and public-web acceptance still pending. A separately deployed WeChat domain-verification file is not a website release. This is not an unreconciled status-record conflict, but a fact that needs its own continued verification. Status records are not decoration; they must change with the evidence on the ground.