DEV Community: Lin Xi

A Checkout Button Is Not a Payment Flow

Lin Xi — Mon, 28 Sep 2026 04:54:47 +0000

A pricing page can feel finished when its Buy button opens checkout. The harder question is what tells the product to deliver what was sold.

Four handoffs

Separate the offer, checkout session, payment confirmation, and fulfillment. A flow is broken if the offer says monthly but checkout charges annually, or if payment succeeds while the account stays on a free plan.

Verify payment on the server

Do not mark an order paid because a buyer reached the return page. A browser redirect is a page visit, not a payment record. For Stripe, verify the provider event and use webhooks for fulfillment. The handler must be safe when the same notification arrives more than once.

Test the awkward paths

Cancel checkout: return safely, with no paid message and no access.
Delayed confirmation: show pending, not premature success.
Duplicate notification: keep one order and one entitlement.
Declined payment: explain the failure and allow a safe retry.

Run these cases in a sandbox. Complete a payment, close the browser before the return page loads, then cancel, decline, and replay the notification. Check the buyer message, order state, and actual entitlement each time.

Sources: https://docs.stripe.com/checkout/fulfillment?payment-ui=stripe-hosted and https://docs.stripe.com/testing

Disclosure: This article was drafted with AI assistance and reviewed for technical accuracy by the author.

The URL Migration Checklist I Wish Every Redesign Had

Lin Xi — Wed, 23 Sep 2026 11:25:23 +0000

A redesign can be flawless on the new homepage and still break links people saved months ago. Before launch, treat the old URL inventory as an engineering input.

Build the route-audit sheet

Start with the old sitemap and CMS. Add URLs from Search Console, analytics, old newsletters, bookmarks, and external links. Track four fields: old URL, destination URL, decision, and owner.

Old path	Decision	Expected result
/pricing	Keep	/pricing
/product-v1	Permanent redirect	/product, if it answers the same need
/expired-offer	Remove	Intentional 404 or 410

These are fictional examples, not We0 routes or a client migration. The decision diagram is a compact way to explain the three outcomes: keep, redirect to an equivalent page, or remove without a misleading homepage catch-all.

Google's site-move guidance recommends mapping old URLs to new ones and warns against irrelevant redirects.

Validate the HTTP behavior

For a permanent move, use a server-side 301 or 308. A 302 is a temporary signal. Avoid chains where a direct redirect to the final equivalent URL is possible.

For each high-priority row, validate both the initial response and the final destination:

curl -I https://example.com/product-v1
curl -IL https://example.com/product-v1

The first request shows the initial status and Location header. The second follows the chain. Then load the final page in a browser and inspect its canonical URL. For removed paths, confirm the 404 or 410 is intentional.

On the new-site side, We0.ai puts content, SEO settings, and publishing in one workflow. It can reduce handoffs while building replacement pages, but it cannot choose the right destination for an old URL; the route map still needs an owner.

Fix the links you control

Update navigation, in-content links, canonical URLs, and the sitemap to use final addresses. If the move spans localized URLs, check their relationships too. A redirect can rescue an old bookmark; it should not be the permanent route used by your own site.

After launch, test three old URLs from a fresh browser window. Ask where each one ends, whether the final page loads, whether its canonical points to the new URL, and whether internal links and the sitemap already use that address. Repeat for URLs from old emails and external articles.

Google recommends submitting an updated sitemap and keeping permanent redirects in place for a long period, generally at least a year. Start with twenty old URLs you would hate to lose and give each a defensible destination.

Disclosure

I work with We0.ai. AI assistance was used to prepare this draft; I reviewed the sources and final text.

Before You Watch Traffic, Define the Events Behind User Behavior

Lin Xi — Tue, 22 Sep 2026 05:35:31 +0000

After an AI-built website goes live, the analytics dashboard is often the first page the team opens. Visits, traffic sources, bounce rate, and time on page are useful—but they describe what happened without always explaining why.

A page view does not tell you whether someone reached the feature section, opened pricing, started a form, submitted it, or clicked a button by mistake. Before collecting hundreds of anonymous clicks, define a few events that can support an actual decision.

A visit is an entry point, not an explanation

One visitor can leave after the hero, read a feature list, open pricing, start a form, submit it, or return later from another source. If every behavior becomes only a page view, the dashboard still leaves the team guessing.

An event is useful when it supports a question:

Did people reach the section that explains the product?
Which page or message moved them to the next step?
Where did they abandon a form?
Which source brought visitors who continued learning?
Did a content page lead to a meaningful next action?

Start with five events

For a product website or a small SaaS, these five event families are a better starting point than dozens of anonymous click events:

Event	What it records	Question it supports	What it does not prove
`view_key_section`	A visitor reaches a feature, pricing, or case-study section	Which content enters the reading path?	Seeing a section does not mean agreement
`click_primary_cta`	A visitor clicks the main next-step button	Which page and message move people forward?	A click does not equal intent
`start_form`	A visitor begins completing a form	Is the entry point clear enough to begin?	Starting does not mean completing
`submit_form`	A form submission with success or failure state	Which visitors complete the action?	A submission does not equal a sale
`use_demo_or_signup`	A visitor tries a demo or starts registration	Does the page move interest into experience?	A signup does not equal retention

The important column is not the event name. It is the question behind it.

Name events so they still make sense later

Tracking systems become messy when names stop carrying meaning. button_click, click_1, and new_event may be acceptable during launch week, but nobody remembers what they represent a few weeks later.

A simple convention is enough: action + object + optional outcome.

click_pricing_cta
start_signup
submit_contact_form_success
submit_contact_form_error
open_feature_demo

Keep page, user type, traffic source, experiment version, and content ID as parameters instead of creating a new event for every variation.

Instrument success and failure states

A form submission is not one state. A useful implementation distinguishes success, validation error, cancellation, timeout, and duplicate submission when those states change the next decision. The same principle applies to demos and signups.

The goal is not the largest tracking plan. It is a short loop: an action becomes an event, the event supports a question, and the question leads to a page, content, or release decision.

A small event plan for today

Pick one important page instead of tracking the entire site at once.
Write the five most important user actions from entry to next step.
Name each event with an action, object, and outcome where needed.
Write one question beside every event.
Record success, failure, cancellation, and duplicate-submission states when they matter.
Assign an owner and a review date so the tracking plan does not become abandoned code.
In each review, write what the data supports and what it still cannot prove.

Traffic is worth watching. But if you want to understand why people continue, stop, submit, or leave, start with the actions and design the data around them.

An AI-Built Website Can Look Polished and Still Say the Wrong Thing

Lin Xi — Mon, 21 Sep 2026 04:02:32 +0000

One of the easiest ways for an AI-built website to become misleading is also one of the least dramatic: it looks finished.

The headline reads smoothly. The feature list is complete. The FAQ sounds confident. Add a polished image and the page can look more mature than many websites written entirely by hand.

Then a reader asks a simple question: Is that feature available today? Where did that number come from? Does â€œmultilingualâ€ include the CMS and metadata, or only the visible text? Is the same product described consistently across the homepage, pricing page, and search snippet?

Once a website is used in search, sales, support, and advertising, a small content error becomes a trust problem.

Not every sentence needs the same kind of evidence

I find it useful to put website copy into four buckets before editing it:

Content type	Example	Best evidence	Review rhythm
Fact	Supported integrations, languages, payment methods, release date	Product docs, settings, formal announcement	Review when the product changes
Number	Price, quota, speed, user count, success rate	Pricing page, system records, reproducible test	Review at every relevant version change
Judgment	â€œGood for small teams,â€ â€œeasier to maintainâ€	Explicit conditions and comparison scope	Review as positioning changes
Promise	â€œImproves visibility,â€ â€œreduces repetitive workâ€	Mechanism, limits, and verifiable evidence	Never turn an aspiration into a guarantee

The most dangerous errors are often not obvious falsehoods. They are judgments written as facts, or possibilities written as promises.

Image: An original diagram created for this article. It is not a We0 product screenshot, does not use third-party stock art, and turns the source-owner-review-date idea into an operational workflow.

â€œPlausibleâ€ is the hardest kind of error to catch

If an AI invents a company founding year, someone may correct it quickly. If it describes a beta feature as â€œsupported,â€ the problem may stay hidden until a customer relies on it.

The harder cases are statements that are not clearly false but invite the wrong interpretation:

â€œSupports multilingual websites.â€ Does that mean translated page text, or does it also include CMS content, metadata, and language relationships?
â€œIncludes analytics.â€ Does that mean a basic event hook, or a complete attribution and reporting system?
â€œSupports AI search optimization.â€ Does that mean the team can configure page fields, or does it imply that an AI system will definitely cite the page?

These sentences need more than a grammar check. They need a boundary check.

Ask: If a customer made a decision based on this sentence, could we explain exactly where it applies and where it stops?

A CMS answers â€œwho can edit,â€ not automatically â€œwho is rightâ€

We0â€™s public CMS page presents backend CRUD, a rich-text editor, image upload, and file upload as content-management capabilities. For a website that changes over time, giving content a proper editing home is important. It should not remain buried in page code forever.

Image: We0.ai public product-page material. It describes the CMS capabilities visible on the page and does not prove content accuracy, customer usage, or publishing outcomes. Screenshot asset captured September 11, 2026; page checked September 21, 2026. Source: https://we0.ai/cms-backend.

But a CMS only creates a better place to make changes. It does not tell you whether the change is correct.

That still requires a source, an owner, a review state, a last-updated date, and some way to understand what changed. A pricing field with no responsible owner will still go stale inside a well-designed editor.

SEO and GEO are not keyword stuffing with a nicer name

Titles, descriptions, Open Graph fields, canonical URLs, language mappings, and structured page information can help systems understand and share a page. They cannot replace trustworthy substance.

Googleâ€™s public guidance emphasizes helpful, reliable, people-first content. For a website team, that becomes a plain operational rule: answer a real question, make important claims explainable, and do not inflate unsupported statements just to make a page more visible.

We0â€™s public SEO/GEO page shows language-specific SEO configuration, page-level metadata, canonical and language mapping, Open Graph/Twitter data, and a search-friendly page structure. These are foundations for expressing and distributing content. They are not a button that guarantees ranking or AI citation.

Image: We0.ai public product-page material. It describes the SEO/GEO configuration direction shown on the page and does not prove rankings, indexing, AI citations, or traffic outcomes. Screenshot asset captured September 11, 2026; page checked September 21, 2026. Source: https://we0.ai/seo-geo-optimization.

Add three fields to every important claim

If I were reviewing an AI-generated website today, I would not start by rewriting every paragraph. I would add three fields to the most important claims:

Source: What supports this sentence â€” a product document, a pricing page, a system record, or someoneâ€™s opinion?
Owner: Who will know when it changes, and who is allowed to update it?
Review date: When was it last checked, and what kind of product change should trigger another review?

This quickly reveals the weak spots. Some claims have no source. Some have a source but no owner. Some were accurate when written and have not been reviewed since.

That is more useful than asking only whether the copy â€œsounds human.â€

AI is a strong drafting partner, not an independent witness

AI is useful for turning source material into page copy, adapting a fact into different tones, finding repetition, suggesting FAQs, writing summaries, and preparing a multilingual draft.

But when a page represents a real product, the final responsibility cannot belong to â€œwhat the model thought was probably true.â€ Important claims should return to source material, or be labeled clearly as a viewpoint, assumption, or future plan.

This matters even more when an AI website becomes part of an SEO, GEO, content, or growth workflow. Search may bring the first visit. Whether the visitor continues to trust the site depends on whether the page survives a follow-up question.

A quick content-trust check

Pick five sentences from the homepage, pricing page, feature page, and FAQ.
Label each one as a fact, number, judgment, or promise.
Add a primary source to facts and numbers.
Add conditions to judgments instead of presenting them as universal truths.
Add limits to promises instead of presenting a goal as a guarantee.
Record an owner and a review date.
Compare the Chinese page, English page, social preview, and search description for contradictions.

AI can give a website content quickly. Trust does not appear merely because the page was generated quickly.

A durable website workflow should be able to answer three questions: Where did this sentence come from? Who owns it? When will someone check it again?

Before an AI-Built Website Goes Live, “Login” Is Not a Permission Model

Lin Xi — Sun, 20 Sep 2026 04:22:32 +0000

When an AI-built website reaches its first usable version, teams usually check the visual details first: spacing, colors, mobile layout, and whether the buttons look right.

Authentication often comes later.

Then a more difficult question appears: who can see what, who can edit it, who can publish it, and who is allowed to change the people who have access?

Those are not four versions of the same login button. They are different responsibilities. If they remain vague, AI can help a team build faster while also spreading an unclear access model across more pages.

Authentication tells you who someone is. Authorization tells you what they can do.

A website may have visitors, members, editors, administrators, billing owners, and customer-side managers. They may all sign in successfully. They should not all see the same data or perform the same actions.

Before drawing a login screen, write down the actions that matter:

Action	Question it answers	Typical role	Common gap
View	Who can see this page, record, or workspace?	Visitor, member, customer	The list is hidden, but the detail URL still works
Edit	Who can change content, settings, or member information?	Editor, project member	The button is hidden, but the API accepts the request
Publish	Who can make a change public?	Content owner, administrator	Editing and publishing are treated as one permission
Manage	Who can invite people, change roles, handle billing, or delete data?	Admin, owner	Nobody is clearly responsible for the most sensitive actions

The table is not the design. It is a way to make the disagreements visible before they become code.

Image: Startup Stock Photos via Pexels. It illustrates the act of documenting requirements; it is not a We0 product screenshot or a customer project. Source: https://www.pexels.com/photo/person-writing-on-paper-using-yellow-and-black-pen-7103/.

Hiding a button is not access control

One of the most common mistakes is treating a hidden button as a permission check.

Suppose a regular member cannot see the “Delete project” button. That improves the interface, but it does not prove that the delete action is protected. If the member can call the underlying endpoint directly, the control is only hidden, not enforced.

Frontend visibility helps users understand what is available. Server-side authorization is what protects the boundary. The system needs to check not only whether someone is signed in, but whether that person is allowed to perform this action on this specific resource.

Role names do not solve this by themselves. Can an editor edit every project or only projects they belong to? Can an admin access billing information? Can a member of Organization A read a record owned by Organization B? If the answers are not written down, adding more roles will not make the model clearer.

AI can generate role labels faster than it can define responsibility

An AI builder can produce a login page, a registration flow, a dashboard menu, and role names such as admin, member, and viewer very quickly.

The difficult part is the boundary around those names:

Who owns the resource: a person, a team, a customer, or an organization?
Does an action affect a page, a field, an export, or a public release?
What happens to content when a member is removed?
Can an expired invitation link still be used?
If a user belongs to two teams, which permission set applies?

If the requirements do not answer these questions, the AI will fill in a plausible default. The page may look complete while ownership and accountability remain undefined.

Treat authentication, content, and delivery as one chain

We0’s public features page presents landing pages, authentication, AI capabilities, payments, CMS, analytics, multilingual support, and launch delivery as part of one broader website system. That is useful context, but it also makes one boundary clear: authentication is one capability, not a substitute for the whole access and operations model.

Image: We0.ai public product-page material. It describes the capability categories shown on the page and does not prove customer usage, security outcomes, or launch results. Screenshot asset captured September 11, 2026; page checked September 20, 2026. Source: https://we0.ai/zh/features.

Permissions also need to connect to content, admin operations, and publishing.

An editor may be allowed to change an article but not a price. A member may view a workspace but not export all its data. An operator may submit a release but not change the domain or payment configuration.

Using one broad admin role can feel efficient in an early prototype. Later it often becomes a mixture of expanded access, unclear responsibility, and difficult reviews.

Test what happens after login

Before launch, test a few real situations instead of stopping at “can a user register?”

What does a new member see immediately after accepting an invitation?
What happens when a read-only member opens an edit URL directly?
After an editor changes content, who sees the draft and who can publish it?
When a member is removed, what happens to old links, sessions, and content?
If two organizations have projects with the same name, can their data be mixed?
What happens when an unauthenticated visitor opens a deep link to a private page?

These scenarios are closer to launch risk than the visual design of the sign-in page.

We0’s public full-stack code-generation page groups page structure, authentication, payments, admin capabilities, multilingual support, SEO, and deployment as a broader engineering foundation. For an AI website workflow, that systems view is useful. It also creates a responsibility for the team: every generated capability still needs a clear owner and a clear boundary.

Image: We0.ai public product-page material. It illustrates the capabilities described on the page; it is not a security audit, code-quality assessment, or proof of a successful deployment. Screenshot asset captured September 11, 2026; page checked September 20, 2026. Source: https://we0.ai/full-stack-code-generation.

Draw one role-by-action table before launch

You do not need ten roles on day one. Choose three realistic users, list their actions, and look for conflicts.

A workable starting point might be:

Visitor: can view public pages, but cannot access private data.
Member: can work inside the spaces they belong to.
Administrator: can manage members, roles, and key settings, with important actions recorded for review.

Add editors, billing owners, or customer administrators only when the product actually needs those distinctions.

The earlier the team defines access, the easier it is for an AI builder to generate a structure that can keep evolving. When access remains vague, AI simply spreads the ambiguity across more screens.

The AI Built the Happy Path. What Happens When the Form Fails?

Lin Xi — Fri, 18 Sep 2026 07:57:55 +0000

A generated page is not a finished interaction

AI builders can produce a convincing first version quickly. The homepage is there, navigation works, and a form may accept a value and return a result. But “it exists” is not the same as “it is ready to hand to a user.”

Real users submit incomplete email addresses, click twice when the network is slow, open dashboards with no data, and reach pages they cannot access. The quality of an AI-generated website shows up in those moments.

Four states to test before launch

State	What to verify	Common failure
Loading	The user sees that work started and duplicate actions are blocked	A second click sends another request
Empty	The user understands why there is no data and what to do next	A blank panel looks broken
Error	The message is human-readable and offers recovery	Raw API text or an unexplained status code
Success	The result is confirmed and easy to find	A toast disappears before the user understands it

Forms expose the gap quickly

A form crosses input, validation, network activity, permissions, server logic, and confirmation. Client-side validation can catch an invalid email before a request is sent, but it is not a security measure. The server still needs to validate submitted data.

For a practical reference, see MDN’s guide to client-side form validation. Pair it with the OWASP Input Validation Cheat Sheet.

A useful pre-launch pass tries an empty value, a malformed value, an unusually long value, a double click, a slow connection, a rejected request, and a response with no usable data. The goal is not a huge test suite on day one. The goal is to make the states visible before a user discovers them for you.

Empty is a product decision

Error states get attention because they look broken. Empty states often get ignored because they look unfinished. A new dashboard with no records should explain the condition and offer a next step, not leave the user staring at a blank table.

The same decision appears in search results, comments, orders, notifications, analytics, and CMS collections. An AI system can generate a convincing card list when records exist. It may not know what the product should say before the first record exists.

Generated is not delivered

An AI-generated page is one output of a workflow. A delivered website must remain editable, testable, and maintainable after the first output. Product, design, engineering, and operations each own part of the failure experience.

One useful review question is: What states does this page have right now? Make the answer explicit before asking for another visual refinement. A public AI website workflow such as We0.ai is only one example; the same review applies to any builder.

A small pre-launch checklist

Does every important request show a loading state?
What does a first-time user see with no data?
What does a user see without permission?
Are client-side and server-side validation both present?
Does a failed submission preserve useful input?
Does a successful action lead to a visible result?
Can a non-technical user understand the error message?

If the answers are unclear, the site may be generated, but it is not ready to be handed off.

I work with We0.ai, an AI website workflow product, and mention it here only as a product example. This article does not claim customer results or platform acceptance.

What edge state does your launch checklist catch most often?

AI Can Generate Every Page. Who Owns the Website Structure?

Lin Xi — Wed, 16 Sep 2026 05:39:09 +0000

AI website builders make it easy to create another page. The harder problem starts when a small team has a homepage, pricing page, feature page, use-case page, case studies, a blog, and a help center, but nobody can explain where a new visitor should start.

Two navigation labels mean almost the same thing. The feature page repeats the homepage. Articles do not lead back to the product pages they describe. The site gets bigger while its logic gets harder to see.

Generating a page is not the same as designing a website structure.

A page map is a working tool

A page map is a shared route map: what the main entry points are, what question each page answers, and where a reader should go next.

Home
├── Product
│   ├── Features
│   ├── Capability detail
│   └── Pricing
├── Use cases
│   ├── SaaS teams
│   └── Content teams
├── Case studies
├── Articles
└── Help center

Diagram: Program evaluation portal sitemap draft1 by Jmorgan (WMF), via Wikimedia Commons, CC BY-SA 3.0. It illustrates hierarchy and relationships; it is not a map of We0’s website.

The shape matters less than the reason behind each level. Product is an entry point. Features establishes scope. Capability pages answer narrower questions. Pricing supports a decision.

Google’s SEO Starter Guide makes a similar point: organize a site logically, use descriptive URLs, and create relevant links whose text helps people understand the destination. These choices help both search engines and the people maintaining the site.

Ask what a page is responsible for

Before asking an AI tool to create another page, write down four answers:

Question	Write down	If the answer is unclear
Who is this for?	One role or situation	Do not generate yet
Why did they arrive?	One question or decision	Check for an existing page
What happens next?	Read, compare, sign up, ask, or leave	Add a real handoff
How is it different?	A new topic, proof point, or stage	Merge before creating

This catches attractive but unnecessary pages. If a new page does not answer a new reader question, it is probably a renamed copy of something that already exists.

A useful product example is We0.ai, where the public capability page puts product brief, scope framing, and direction alignment before build details. The lesson is broader than one tool: clarify what the site is for before filling in more screens.

Make the map useful after launch

When page responsibilities are clear, later work becomes easier to review. Writers know which type of page an article should support. SEO reviews can find topics with no entry point and pages that compete with each other. Design and engineering handoffs can focus on page responsibility, not only visual polish.

Try this small audit before generating anything else:

List the five most important links in the homepage navigation.
Write one sentence describing the audience and job of each destination.
Find two pages that repeat each other under different names.
Give every high-value page a clear parent entry and a next action.
Only then decide whether a new page is needed.

If three pages explain the same thing, the next task is probably to merge, rename, and reconnect them.

This article was drafted with AI assistance and reviewed by the author for accuracy. Disclosure: the author works with We0.ai.

Which page would you map first on your current site?

A Multilingual Website Is a Relationship Problem, Not Just a Translation Task

Lin Xi — Tue, 15 Sep 2026 04:51:11 +0000

Multilingual websites often begin with a reasonable sentence: “Let’s ship the English version first, and clean up the rest later.”

The page gets duplicated. The copy is translated. An “English” item appears in the navigation. It looks finished until the next week, when the Chinese page changes its headline, the English page has no owner, and the language switcher sends people back to the homepage instead of the equivalent page. Search results start showing the wrong language. Someone finds an older translation in the CMS and nobody knows which version is current.

The problem is usually not translation quality. It is that the relationships between language versions were never designed.

Photo by Andrea Piacquadio via Pexels. This image illustrates the ongoing work of reviewing and organizing content; it is not a We0 product or customer project screenshot.

One page, several relationships

Before choosing a translation tool, separate “language version” into four relationships.

The first is the address relationship. A Chinese product page and its English counterpart should have predictable URLs, such as /zh/product and /en/product, or clearly defined subdomains. Google’s international-site documentation recommends fully qualified URLs for alternate pages. A readable URL is also easier for a team to debug.

The second is the content relationship. The English page is not a mirrored text file. It is the same page intent expressed for another language and, often, another market. Prices, feature names, legal text, and support paths may need localization rather than literal substitution.

The third is the search relationship. Google recommends hreflang annotations to identify language and regional alternatives. Each version should reference itself and the other versions, and the references should be reciprocal. If the Chinese page points to English but the English page never points back, Google may ignore the annotations. hreflang is not a language-detection switch either; Google still determines page language algorithmically.

The fourth is the editing relationship. Who owns the source content? Which fields must be rewritten? Can one language publish first? What should a visitor see while a translation is waiting for review? These decisions belong with the page object, not only in a chat thread.

Check	Minimum decision	Common failure	Acceptance question
URL	A language path or subdomain rule	Random translated URLs	Can one version map deterministically to another?
Page intent	Title, primary CTA, core facts	Literal translation without context	Do both versions answer the same user question?
`hreflang`	Valid language codes and reciprocal references	One-way links or invalid region codes	Does every version list itself and its alternates?
Canonical	The canonical URL for the current page	Every language canonicalizes to Chinese	Will localized pages be treated as duplicates?
State	Draft, review, published, retired	Translation automatically goes live	Can an unreviewed version stay out of production?
Switcher	A link to the equivalent content object	Every switch goes to the homepage	Does the user stay in the same content context?

This public We0 page shows multi-style website design, brand tone, content priorities, business goals, and composable blocks. It does not demonstrate that any language version has been published.

`hreflang` is not a lonely line of code

Google documents three equivalent implementation methods: HTML in the <head>, HTTP response headers, or an XML sitemap. Pick one. Maintaining all three usually creates more opportunities for drift than value.

With HTML, a minimal setup looks like this:

<link rel="alternate" hreflang="zh-Hans" href="https://example.com/zh/product" />
<link rel="alternate" hreflang="en" href="https://example.com/en/product" />
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Three concepts are easy to mix up. hreflang says which language or region an alternate serves. canonical says which URL is the preferred address for the current content. A language switcher serves the person reading the page. They work together, but none replaces the others.

x-default is useful for a language selector or a fallback page when no language matches. Language codes must follow the supported ISO formats; a country code by itself is not a language. Most importantly, the same alternate set should appear on each version, with reciprocal references, rather than existing only on the default-language page.

SEO cannot be a release-night task

Teams often treat translation as a content job and SEO as a final pre-launch check. The body copy is ready, but the title, description, Open Graph data, canonical, and sitemap still belong to the default language.

For each language version, review:

Whether the title and description match real search phrasing in that language.
Whether the canonical points to the current language’s canonical URL.
Whether hreflang references are reciprocal, complete, and valid.
Whether the switcher links to the equivalent content object, not a generic homepage.
Whether untranslated or unreviewed content has an explicit publishing state.
Whether structured data, image alt text, and social cards are localized too.

Google also notes that a page whose main content is not translated, even if its template is localized, may be treated as a duplicate. That is a simple warning with a useful implication: language versions need a meaningful content distinction and a reliable technical connection.

This public We0 page illustrates page-level SEO/GEO configuration and language mapping. It is not evidence of rankings, indexing, or AI citations.

We0.ai presents multi-style design, page structure, and SEO/GEO configuration as parts of one website workflow. For a team adding a second language, the practical value of this kind of workspace is context: pages, content, and publishing configuration can stay connected. It does not remove the need for a person to confirm facts, localization choices, and review boundaries.

Draw one language map today

Do not start with the whole site. Pick one business-critical page, such as a product or pricing page, and write down:

the default-language URL and the second-language URL;
each version’s title, description, and primary CTA;
the canonical URL for each page;
the reciprocal hreflang references;
where the language switcher lands;
who owns translation, review, and publication.

If the map cannot be drawn, pause the bulk translation. A small first release is fine. A set of language pages with unclear relationships is not.

Translation changes the language. Relationship design is what turns the result into a maintainable website.

Disclosure: The author works with We0.ai. We0 appears as one product example in the workflow discussion; no ranking, indexing, conversion, or publication outcome is promised.

This article was written with AI assistance and reviewed for factual accuracy by the author.

Before an AI Website, Define the Content Model

Lin Xi — Mon, 14 Sep 2026 04:49:04 +0000

Before an AI Website, Define the Content Model

The fastest way to make an AI-built website difficult to maintain is to treat every sentence as part of the layout.

The first page looks good. Then a price changes, a case study needs a new version, or someone asks for the same FAQ on three pages. The team can see the words, but nobody can say where the source lives. A quick generation has quietly become a content problem.

This is why I prefer to define a small content model before asking an AI builder to generate the polished page. The model does not need to be a large database project. It only needs to make changing facts, reusable stories, relationships, and publishing states visible.

Photo by Thirdman on Pexels. It illustrates the work of organizing content; it is not a We0 product screen or customer project.

A page is not a content model

When a block of copy is written directly into a page, it is easy to ship and hard to change. The same product description gets copied into a hero, a pricing card, and an FAQ. A later edit has to find all three versions. An AI system may even produce slightly different wording for each one, leaving the team unsure which version is authoritative.

A content model asks ordinary questions: What is this piece of information called? Who owns it? Where else can it appear? Does it have a status, a version, or a language?

For a product page, the title, one-line value proposition, price, button label, and FAQ may deserve separate fields. They change at different rates and often have different owners. Keeping them as one large text block makes generation fast while making editing slower every week.

I usually start with three categories:

Facts: price, specifications, availability, service scope, and updated-at dates. These need one source of truth.
Narrative: titles, value propositions, case-study copy, and answers. These need tone and revision control.
Relationships: which product belongs to which category, which FAQ belongs to which feature, and which article points to which landing page. Relationships make reuse possible.

The point is not to build a complicated admin system on day one. The point is to separate content that will change from choices that only describe this particular layout.

Fields before blocks

Many AI website workflows begin with blocks: hero, feature grid, pricing, FAQ. That is a useful order for visual exploration, but not always for ongoing maintenance.

Define the fields first, then decide how those fields should be composed into blocks.

Content object	Minimum fields	Owner	Signal to model it
Product	Name, short description, status, primary CTA	Product or sales	The same product appears on multiple pages
Case study	Customer type, problem, approach, limits, date	Marketing or customer success	Stories need filtering or reuse by industry
FAQ	Question, answer, related feature, updated-at	Support or product	The same question keeps returning
Article	Title, excerpt, author, tags, body, publish state	Content team	Draft, review, and scheduled publishing matter

If an object appears on one page and rarely changes, it can remain page content for now. If it appears in more than one place or is edited every week, it should become a managed field early. That boundary is more useful than asking whether a CMS is fashionable.

This is a public capability description from We0’s English website. It does not show customer data, an approval result, or a publishing outcome.

Once the fields are clear, the AI prompt becomes testable. Instead of “make the case-study section more convincing,” you can say: “Read customer type, problem, approach, and date from the case-study object. Use three columns on desktop, one column on mobile, and hide the date label when it is empty.” The second instruction gives the model a structure to follow and the team something to review.

Relationships and states are where the trouble starts

Relationships and states are easy to skip because they are not visible in a first screenshot.

An article may belong to one product or several. An FAQ may be attached to a feature whose name later changes. A post may move from draft to review, published, and retired. When those states exist only in someone’s memory, an old version remains live after the content has supposedly changed.

Before generating the full site, ask:

If we rename or remove this object, which pages are affected?
If two versions exist, who decides which one is current?
Can an unpublished change be previewed without changing the live page?
If we add another language, which fields can be reused and which need rewriting?

These questions do not force a team to build complex permissions, workflows, or translation systems today. They expose assumptions early, before a temporary decision becomes a permanent page structure.

Stable field names also help when the content must be understood outside the CMS. For public articles, a team can map an object to Schema.org’s Article type and use MDN’s article element reference to check the page semantics. These are not CMS product docs; they are simple ways to keep the content object and the rendered page aligned.

Let AI turn structure into a visible page

Once the objects, fields, and relationships are explicit, AI website generation becomes more useful. It can compose fields into a page, try alternative layouts, fill responsive states, and adjust the presentation when editors find a problem.

We0 AI brings AI Builder, CMS, and later editing into one workspace. The practical benefit is continuity: the page structure and content structure can be revised in the same context. That still requires a person to verify facts, ownership, and publishing boundaries. It does not guarantee search rankings, citations, traffic, or conversions.

This public AI Builder capability description illustrates the workflow from structured input to an editable page. It is not evidence of a customer project or business result.

A 20-minute content-model check

Choose the page your team changes most often and write down:

Which words are likely to change next month?
Which pieces appear on more than one page?
Who owns facts, who owns tone, and who approves publication?
Which status, date, and relationship does each object need?
Which facts must not be rewritten when the AI tries a new layout?

Turn those answers into fields before asking the builder to generate the page. The first version may still need work, but the rework will be about layout and expression instead of hunting for the source of every sentence.

AI makes a page appear quickly. The content model decides whether a team can keep changing it.

If you are drafting your own fields, you can review how We0 AI places AI website creation, CMS, and growth work in one workspace, then decide which parts of your site should become reusable objects.

Disclosure: I am affiliated with We0.ai. This article discusses AI website content structure and workflow; We0 is included as a product example. No ranking, indexing, GEO citation, traffic, or business outcome is promised.

AI Website Handoffs: When a Prototype Needs a Real Code Boundary

Lin Xi — Sun, 13 Sep 2026 04:36:15 +0000

A polished AI-generated website can hide an unfinished delivery model. The hard question is not whether a builder can produce a convincing page. It is whether the next person can safely change the real system without reconstructing the original prompt, platform state, and deployment assumptions.

Three kinds of change

Separate visual, content, and system work before deciding where the boundary belongs.

Visual: spacing, colors, layout, and imagery. Keep these in the canvas or component styles while the team is exploring.
Content: pricing, articles, case studies, and localized copy. Give these stable fields, a CMS, or a clear editing path.
System: authentication, data relationships, payments, permissions, and integrations. These need code, environments, tests, and a release path.

The boundary should move when a failure affects real users, orders, or data responsibility. Starting to write code should not turn every copy edit into an engineering ticket, but production behavior needs an explicit owner and a reversible change path.

Test the handoff

Hand the project to someone who was not present for the initial generation. Ask them to update one product field, add a protected page, rotate a secret, change a domain, and roll back a release. If every step depends on an old prompt or the original builder, the system has already accumulated avoidable risk.

Document the minimum before the handoff:

Area	Minimum record	Verification question
Environment	Repository, runtime, configuration	Can the next owner run it locally or in staging?
Data and secrets	Storage, secrets, permissions	Who can read, export, rotate, or delete them?
Auth and payments	Providers, callbacks, test accounts	Who handles an expired credential or failed callback?
Content	Fields, editing path, publishing permissions	Can an operator change content without page code?
Release	Live version, checks, rollback owner	How do we confirm the expected version is public?

The code boundary is about responsibility

AI-assisted projects often lose decisions between requirements, product, design, development, and operations. A useful handoff artifact can stay short: current goal, explicit non-goals, data model, external dependencies, acceptance checks, release path, and the first things the next owner should inspect. The format matters less than preserving which decisions are settled and which are still assumptions.

Full-stack generation is useful when auth, admin work, payments, multilingual structure, SEO, and deployment need a path that can continue. A team can move quickly first, then make the boundary explicit when the project actually needs it instead of rebuilding a polished prototype from scratch.

We0.ai is included here as a workflow example. Its public capability pages describe full-stack generation, multi-agent coordination, and domain delivery. This is not a claim that a product removes the need for architecture, testing, release ownership, rankings, traffic, AI citations, approval, or commercial outcomes.

When a builder is enough

For a one-day campaign page, a value-proposition test, or a visual exploration with no accounts or user data, staying in the builder is reasonable. Once the site owns real accounts, real orders, real content responsibility, or a release rhythm, “we will migrate later” is a risky default.

Ask one deliberately unglamorous question: who will change the real thing three months from now without the original builder’s help? If the answer is unclear, the missing work may be a handoff boundary that lets the project keep working.

Your AI-Generated Website Needs a Content Model

Lin Xi — Sat, 12 Sep 2026 04:00:57 +0000

The page is easy to generate. The durable part is deciding which facts become editable objects, who owns them, and how a change reaches production.

Model facts before adding more pages

Separate facts that change often from layout. Products, case studies, and articles each need clear fields, owners, and review boundaries. If a fact will be edited, reused, or reviewed on its own, it should not live only inside one undifferentiated block of page copy.

Keep page-level metadata next to page intent

Title, description, author, updated date, language, canonical URL, and primary image should be stable page-level fields. This keeps multilingual releases and search snippets aligned with what the page actually says.

Treat publishing as a state transition

A content change should make its affected pages, deployment state, and verification steps visible. The team should know what changed, who approved it, and whether the current version is live.

A practical post-launch test

Ask someone unfamiliar with the project to update one product fact, replace one image, and change a page title. They should be able to find the path and explain which pages are affected without asking a developer.

Tools such as We0.ai can be used as a workflow example.

Disclosure: I work with We0.ai, which appears once as an example of the workflow described here.

The First Prompt Matters More Than the First Page

Lin Xi — Fri, 11 Sep 2026 04:27:39 +0000

The First Prompt Matters More Than the First Page

AI website builders make the first version dramatically faster. They do not make the product decisions for you. The first sentence still determines whether the system builds something that can do a job or simply arranges a page that resembles a website.

Turn the prompt into a small project brief

A useful website input should define four things:

who is coming to the site
why they are coming now
what they should complete there
what this version deliberately will not do

“Build a website for an independent coffee brand” is broad. “Build a mobile-first site for nearby office workers who want specialty coffee beans; introduce three products, then guide visitors toward a monthly delivery subscription; do not build a complex membership system in this version” gives the implementation a boundary.

Constraints make the result easier to compare and the next edit easier to choose.

Map intent to an implementable page

Once the audience and primary action are clear, map them to a small page model. Decide which page type owns the action, which content is reusable, and which information is required above the fold. Keep unresolved assumptions visible instead of hiding them inside a prompt.

A good correction is specific: clarify the audience, reduce the scope, or resolve a conflict between references. “Make it more premium” is not a useful technical requirement.

Five checks before calling the first version done

1. Routes and crawl paths

Every important route should return a successful status, be linked internally, and be reachable without relying on a client-only interaction. Check robots.txt, accidental noindex, canonical URLs, and the sitemap before expecting search engines to discover the page.

2. Metadata generated from page intent

Set title tags, meta descriptions, Open Graph fields, and canonical URLs from the same page-level source of truth. The metadata should match the page promise and the query it is intended to answer.

3. CMS fields that support the next edit

If the page will change after launch, model the changing parts as editable content rather than burying them in layout code. Keep product facts, FAQs, dates, and author information structured so a small update does not require rebuilding the whole page.

4. Analytics events tied to meaningful actions

Page views are not enough to evaluate the brief. Define consistent events for actions such as a pricing interaction, signup, contact request, or checkout start. Include the page and content context needed to trace a visit to an outcome.

5. A task record that preserves the decision

When a signal appears, record its source, affected URL, proposed change, owner, and verification step together. This keeps the original product decision connected to the implementation and the measurement.

The prompt keeps working after launch

The generation button looks like a finish line, but the brief starts changing as soon as the site meets real work. Sales learns that customers care more about delivery time than brand story. Mobile users cannot find the purchase action. A page gets impressions but very few clicks.

The useful category is therefore broader than an AI website builder. Building is only the beginning; live editing, CMS content, domains, SEO, GEO visibility, analytics, and the lead or payment flow belong to the same operating question: why did the visitor stop moving forward?

Tools such as We0.ai are exploring this website-workbench model. It does not guarantee rankings, AI citations, traffic, or sales. It reduces how much context a team has to reconstruct before making and verifying the next change.

The first page may still need several rounds of work. At least each round will have somewhere to go.

Disclosure: The author is affiliated with We0.ai. This article discusses AI website building and requirements clarity from a workflow perspective. We0 is included as a product example and no ranking, traffic, GEO citation, or business outcome is promised.

DEV Community: Lin Xi

A Checkout Button Is Not a Payment Flow

Four handoffs

Verify payment on the server

Test the awkward paths

The URL Migration Checklist I Wish Every Redesign Had

Build the route-audit sheet

Validate the HTTP behavior

Fix the links you control

Disclosure

Before You Watch Traffic, Define the Events Behind User Behavior

A visit is an entry point, not an explanation

Start with five events

Name events so they still make sense later

Instrument success and failure states

A small event plan for today

An AI-Built Website Can Look Polished and Still Say the Wrong Thing

Not every sentence needs the same kind of evidence

â€œPlausibleâ€ is the hardest kind of error to catch

A CMS answers â€œwho can edit,â€ not automatically â€œwho is rightâ€

SEO and GEO are not keyword stuffing with a nicer name

Add three fields to every important claim

AI is a strong drafting partner, not an independent witness

A quick content-trust check

Before an AI-Built Website Goes Live, “Login” Is Not a Permission Model

Authentication tells you who someone is. Authorization tells you what they can do.

Hiding a button is not access control

AI can generate role labels faster than it can define responsibility

Treat authentication, content, and delivery as one chain

Test what happens after login

Draw one role-by-action table before launch

The AI Built the Happy Path. What Happens When the Form Fails?

A generated page is not a finished interaction

Four states to test before launch

Forms expose the gap quickly

Empty is a product decision

Generated is not delivered

A small pre-launch checklist

AI Can Generate Every Page. Who Owns the Website Structure?

A page map is a working tool

Ask what a page is responsible for

Make the map useful after launch

A Multilingual Website Is a Relationship Problem, Not Just a Translation Task

One page, several relationships

hreflang is not a lonely line of code

SEO cannot be a release-night task

Draw one language map today

Before an AI Website, Define the Content Model

Before an AI Website, Define the Content Model

A page is not a content model

Fields before blocks

Relationships and states are where the trouble starts

Let AI turn structure into a visible page

A 20-minute content-model check

AI Website Handoffs: When a Prototype Needs a Real Code Boundary

Three kinds of change

Test the handoff

The code boundary is about responsibility

When a builder is enough

Your AI-Generated Website Needs a Content Model

Model facts before adding more pages

Keep page-level metadata next to page intent

Treat publishing as a state transition

A practical post-launch test

The First Prompt Matters More Than the First Page

The First Prompt Matters More Than the First Page

Turn the prompt into a small project brief

Map intent to an implementable page

Five checks before calling the first version done

1. Routes and crawl paths

2. Metadata generated from page intent

3. CMS fields that support the next edit

4. Analytics events tied to meaningful actions

5. A task record that preserves the decision

The prompt keeps working after launch

â€œPlausibleâ€ is the hardest kind of error to catch

A CMS answers â€œwho can edit,â€ not automatically â€œwho is rightâ€

`hreflang` is not a lonely line of code