Website and mini program integration: four checks to make
Splitting the website and the mini program between two vendors costs more than the gap between quotes. It costs a second content baseline, and every price change gets reconciled by hand from then on.
'Integration' is a vague word on a quote sheet. It can mean a shared visual system, genuinely shared content, or one codebase, and the price can differ two or three times. Break it into tiers before anyone talks money. A Sina News vendor roundup published on 26 October 2026 already listed 'website and mini program content connected', 'one backend, two front ends in sync' and 'source code optional' as standard selling points. What varies is which tier gets delivered.
Three tiers, and where the price gap comes from
Visual consistency. Same logo, palette and type scale, two separate builds, no shared backend. Cheapest. The cost is operational: every launch gets published twice, and specs, campaign dates and contact details drift apart. Teams that change content less than once a month can live with it.
Shared content. One backend, the website renders server-side into HTML, the mini program pulls the same records over an HTTPS API. Best value for most SMBs, and nearly all of the cost sits up front: the content model must be designed before either front end exists, with fields that feed both. The friction is specific. Web rich text has no DOM on the mini program side, so you get the rich-text component and only its supported tags. Images need several renditions per endpoint: AVIF or WebP on the website, size and bandwidth limits on the mini program. Tables usually become cards. Get the model wrong and every new field means a change on both sides. That is the real cost of this tier, and it is design time, not development hours.
Shared code. A cross-platform framework such as Taro or uni-app compiles one codebase to the mini program and to H5. You save duplicate development, but pages from those frameworks are unfriendly to SEO, first paint is often client-rendered, and a crawler gets an empty shell. Even with prerendering, routing and head management feel clumsier than something like Next.js. The usual split is server-side rendering or static generation for the website, native or cross-platform for the mini program, both reading one content API.
One layer gets skipped: backend roles and the publish workflow. Once both front ends share a backend, one bad edit hits two entry points. Editors, reviewers and admins need separate roles, and publish timestamps need unifying.
How to decide, in order: how often content changes, whether you need multiple languages, whether the mini program brings in customers. All three low, tier one. Any one high, tier two. Tier three only when the two page sets overlap heavily and the website is not counting on search traffic.
A reality check: mini program pages are practically invisible in general search, and search inside WeChat runs on other rules. On an integrated project the website carries all the search equity you can accumulate. Budgeting both as equal traffic channels tends to end badly.
Three SEO claims you can test before you sign
Every vendor says they do SEO. Skip the deck and ask for three things you can verify.
Body text in the first-paint HTML. Take a live inner page URL, curl it, count words in the HTML body, compare with the browser. Matching counts mean server-side rendering or static generation. A <div id="root"></div> plus a pile of scripts means first paint is assembled in JavaScript, which needs prerendering on top.
Custom URL rules. The argument usually lands on detail pages: /products/xxx and /product?id=123 behave differently for crawlers, sharing and analytics. Parameter URLs get sliced into duplicate pages by analytics, lose their parameters when shared, and cannot be consolidated with a canonical tag. Ask about trailing slashes and case handling too: if /About and /about both return 200 after launch, you have two copies of one page.
Per-page head configuration. Title, description, canonical tag, hreflang and JSON-LD output by page type, not from one global variable. This is where acceptance usually fails. The template is hardcoded, changing one page means changing code, and the content team never catches up.
All three can be demonstrated on the spot. What cannot be demonstrated is a promise.
Multilingual: subdirectory first, three hard hreflang rules
The first decision is URL structure, not translation.
| Option | Example | Cost | Fits |
|---|---|---|---|
| Subdirectory | example.com/en/ | One codebase, one certificate, one analytics account | Most B2B and brand sites |
| Subdomain | en.example.com | Treated closer to a new site, weaker inheritance, a second ops setup | Country teams running independently |
| Separate domain | example.de | Strong local signal, higher cost and registration requirements | A local entity with long-term plans |
| URL parameter | example.com?lang=en | Analytics shredded, shared links lose the parameter | Not recommended |
Small teams default to subdirectories, not because everyone does it but because there is less to maintain. Before choosing subdomains, ask whether you have a second ops team to run them.
Three hreflang mistakes repeat. The href must be an absolute address, never a relative path. Every page needs the entry pointing at itself; drop the self-reference and the whole set can be ignored. x-default goes on every page or on none, since a half-configured set behaves like no configuration.
One more, in the opposite direction: never auto-redirect by IP or browser language. Googlebot generally crawls from the US without an Accept-Language header, so a JavaScript redirect can mean /en/ and /de/ are never fetched. Give each language its own URL and put a switcher in the header. Pick the default language by your main market, not by where the company is registered.
GEO is not a separate purchase
GEO, generative engine optimization, is sold as a standalone service. Peel it back and the overlap with traditional search is large: pages that can be crawled, body text as semantic HTML, key facts in complete sentences, structured data matching what is visible.
Two differences are real. Crawl policy: major AI crawlers carry their own user agents, GPTBot, ClaudeBot and PerplexityBot among them, and default bot protection on a CDN or WAF often blocks anything that is not Google or Bing. Sites drop off the AI side and nobody notices. Check robots.txt and the WAF rules before launch. Content shape: extractive answers favour one complete answer per question, and numbers with a stated basis and source get quoted more often than hedged wording.
[TO VERIFY: whether mainstream AI crawlers actually read llms.txt today, or whether it remains a community proposal. This decides whether it belongs on the delivery checklist.]
So GEO belongs on the technical SEO list, not in an 'AI optimization package'. Bought on its own it usually becomes a few sponsored posts and a batch of directory submissions.
Source code and accounts decide your exit cost
Withholding source code comes in familiar wrappers: only compiled output; 'licensed source' with core modules encrypted or compiled to binary; cloud hosting without build scripts or deployment docs. None shows up in normal operation. You find out when you change vendors or need a second development round, and the cost then is a rebuild.
What you should hold: repository access and commit history, build and deployment scripts, the environment variable list, and ownership of every third-party account, meaning domain, SSL, object storage, SMS, payments, and the mini program entity plus developer permissions. Log into each one at acceptance and check it off.
The two items most often missed are mini program developer permissions and the entity administrator. If the entity sits under the vendor's name, migrating means re-registering, and historical users and reviews do not come along.
At WANFENG TECHNOLOGY we hand over the full source code and transfer accounts at the acceptance milestone, then keep three months of free maintenance. The arrangement is simple; getting it into the contract instead of a verbal assurance is the hard part.
How to read the quote and the schedule
Ask for the quote split: information architecture and URL planning, content model and API contract, website pages, mini program pages, SEO and GEO technical items, testing and launch, 90 days of monitoring. A quote that cannot be split comes back later as change orders.
Schedules work the same way. If content model design gets two days, assume nobody intends to do the two-front-end sharing properly, and that is the stretch most likely to be redone.
The cheapest test costs nothing. During selection, ask the vendor to curl an inner page and show you the HTML. If that fails, every SEO promise after it is pending.