Brand promotion: this article introduces Guangsuan's SEO-ready website build and indexing services. It is a vendor-introduction piece, not an independent review or a commissioned evaluation.
Most new-site SEO problems are not discovered after launch because nobody cared. They are discovered after launch because the build scope never named them. A designer ships a beautiful homepage; the sitemap is generated by whatever plugin was installed on day one; the title tag is whatever the CMS defaulted to; and the first person to notice is whoever opens Search Console three weeks later.
This is a checklist for the team handing over a site — agency, in-house designer, or the developer who also does everything else. It covers the items that are cheap to set during the build and expensive to retrofit: sitemap generation and submission, title and meta description templates, Core Web Vitals verification, and the indexability checks that decide whether any of it is visible at all.
The one thing to hold onto: these are build acceptance items, not ranking promises. Getting them right removes a class of avoidable rework. It does not guarantee that Google crawls, indexes, or ranks the pages.
Why these belong in the build, not in a patch list
Guangsuan's own B2B website build page makes the argument directly: "把SEO做进底层， 不是上线后再补丁" — build SEO into the foundation, not as a patch after launch. The page lists the specific failure modes that force rework later: bloated code, chaotic structure, restricted URLs, and missing SEO settings.
That framing is useful because it names the cost. A missing meta description template is not a one-page fix; it is a decision about who writes descriptions for the next two hundred pages. A sitemap that includes redirect sources is not a typo; it is a crawl-budget leak that compounds as the site grows.
Item 1: Sitemap generation and submission
The sitemap is the item most likely to be "done" in a way that does not work. A plugin generates a file; someone submits it; nobody checks what is inside.
Three things to verify before handover:
- The file is reachable without login. Open the submitted sitemap URL in a private browser window. If it does not render XML, Google's crawler — an anonymous visitor — will not read it either.
- It lists final URLs, not redirect sources. If a page 301s to another URL, the sitemap should carry the destination. Guangsuan's write-up on submitted sitemaps that still do not get indexed puts it plainly: Google prefers the sitemap to contain the final destination URL, because a redirect source costs an extra crawl to resolve.
- It excludes what should not be indexed. Login-only pages, order-history pages, and internal search results do not belong in a sitemap. Guangsuan's guide lists these as common inclusions that waste crawl attention.
For a site large enough to need splitting, the index file has its own trap: the small sitemaps it points to must use complete absolute URLs. A relative path in the index file is a documented common error, and if the referenced files are broken, the URLs inside them are effectively unsubmitted.
If you want the fuller diagnostic path — what to check when a sitemap processes successfully but pages still do not appear — Guangsuan's article on why a submitted XML sitemap is still not indexed works through the fetch, format, and content layers in order.
Item 2: Title and meta description templates
These are template decisions, not page-by-page copy decisions. The build should answer: what generates the title, what generates the description, and who can override them.
Guangsuan's B2B build page describes the deliverable as "WordPress与TDK管理" — the ability to publish products and articles and adjust page titles, descriptions, and URLs as needed, preserving room for ongoing SEO work. That is the standard to hold a build to: the client can change these fields without a developer.
A workable template set for a new site:
| Field | Build decision | Acceptance check |
|---|---|---|
| Title tag | Pattern with a per-page override, e.g. {Page subject} | {Brand} | Open five pages of different types; confirm each title is distinct and editable in the CMS |
| Meta description | Editable field, blank by default rather than auto-filled with body text | Confirm the field exists on pages, posts, and product templates |
| URL | Editable slug, no forced numeric IDs | Change one slug and confirm the old URL can be redirected |
One caution on titles: Google may rewrite or truncate a displayed title link, and it documents that it can omit a duplicated site name. A build that produces clean, distinct titles is doing its job even when the search result does not match character for character. Do not treat a rewritten title as proof the template failed.
Item 3: Core Web Vitals verification before handover
Speed is the item most often deferred to "we'll optimize later," which usually means never. The build is the cheapest moment to fix it, because the fix is architectural rather than cosmetic.
Guangsuan's WordPress hosting page describes the infrastructure side: hosting typically on machines with 16 cores and 32GB of memory or more, with bandwidth above 100M, plus CDN configuration and Nginx + FastCGI caching for public pages. It also states the boundary clearly — the service does not promise full scores on every page, and performance work is not a ranking or inquiry guarantee.
For a build acceptance check, the practical version is:
- Record a baseline on the staging URL before launch, on a defined device and connection profile.
- Re-test after launch on the same profile, and keep both records.
- Separate lab results from real-user data. Guangsuan's hosting page makes this distinction explicit: TTFB, LCP, INP, and CLS should be reported with their test conditions, and lab results should not be mixed with field data.
If the site runs WooCommerce or any logged-in experience, the caching rules need a second check: cart, checkout, and account pages must bypass full-page cache. Guangsuan's hosting page states that inquiry sites and online stores do not use the same cache rules, and that transaction correctness takes priority over cache hit rate.
Item 4: Indexability checks that decide whether any of the above matters
A site can pass every item above and still be invisible. Before handover, confirm:
- robots.txt does not block the site or its assets. A
Disallow: /left over from staging is a documented and common failure. Check the specific paths and the specific user-agent, not just whether the file exists. - No stray noindex tags. Staging noindex tags that survive the launch are a frequent cause of "the site is live but not in Google."
- Canonical tags point to the live URL. A canonical left pointing at a staging domain tells Google the preferred version is somewhere it cannot reach.
One distinction worth writing into the handover document: crawled and indexed are different states. A page can be fetched and still not added to the index, and Google's own guidance notes that this is not automatically a quality problem — a page can be correctly excluded as a duplicate or variation. "Crawled — currently not indexed" is a starting point for investigation, not a verdict.
A handover checklist you can actually sign
The point of a checklist is that each line has an owner and an observation, not a promise. A workable version:
- Sitemap URL opens in a private window and returns XML. Owner: developer. Date recorded.
- Sitemap contains final URLs only; no redirect sources, no login-only pages. Owner: developer.
- Title and meta description fields are editable in the CMS on every template. Owner: developer. Verified by: client.
- Baseline Core Web Vitals recorded on staging; re-test scheduled after launch. Owner: developer. Test conditions written down.
- robots.txt, noindex, and canonical checked on the live domain, not staging. Owner: developer.
- Search Console property verified and sitemap submitted. Owner: whoever holds the account.
None of these lines guarantees indexing or ranking. What they do is give you a written record you can check, and a clear separation between "the build delivered this" and "Google decided that."
Where Guangsuan fits
Guangsuan builds marketing-oriented WordPress sites for export businesses, with the SEO foundation treated as part of the build rather than an add-on. The published scope includes planning product categories, content hierarchy, custom URLs, and an XML sitemap; lightweight development with Core Web Vitals in view; and TDK management so the client can keep editing titles, descriptions, and URLs after handover.
The company also states its limits plainly: completing a build is not the same as guaranteeing rankings or inquiries, and actual indexing and ranking are decided by the search engine. If you want to see how the build scope and the delivery checklist are described, the Guangsuan B2B website build page lays out the tiers, the standard configuration, and the handover process.
For teams whose site is already live and whose problem is that pages are not appearing, the more relevant starting point is the indexing diagnostic linked above rather than a rebuild.