From SEO to GEO: How I Built an AI-Native Multilingual Website Architecture Through AI Collaboration - Build Log

Introduction: An AI Solopreneur’s Ambition for a Global Audience

When I decided to build “Brian Jhang’s Edge,” my personal brand website, my goal was clear from day one: this had to be an AI-native platform built for a global market.

But reality is harsh. I’m one person. I have no team, no external funding, and certainly no infinite amount of time. To build a truly global website that could serve users across different languages, the traditional approach would require:

A professional multilingual Content Management System (CMS)
A translation team or expensive translation services
A front-end engineer to handle complex routing logic
An SEO expert to optimize each language version

These were all resources I lacked as an “AI Solopreneur.”

But AI changed everything.

During the development of this multilingual architecture, I came to a profound realization: the true power of AI isn’t just about simplifying tasks; it’s about being a “Capability Amplifier.” By collaborating deeply with Claude Code, I single-handedly accomplished a complex architectural challenge that would have previously required a small team.

This article is not just a technical case study; it’s a deep reflection on how individual creators in the AI era can break through their limitations.

Chapter 1: WHY - Why Traditional Multilingual Isn’t Enough: The Leap from SEO to GEO

The Limitations of Traditional Multilingual Approaches

When I first started planning the multilingual feature, the initial thought that came to mind was: “Find an i18n package, translate the content, and done.”

This is the most intuitive and common approach. The market is filled with countless multilingual solutions:

Astro’s built-in i18n routing
Mature translation frameworks like i18next and react-intl
Even paid translation management platforms

But when I paused to think about the core positioning of the “Brian Jhang’s Edge” brand, I realized: a standard translated website is insufficient under the “AI-native” brand philosophy.

Why?

Because the traditional multilingual mindset is, in essence, still an “SEO mindset”:

SEO Mindset: Conforming to the rules of search engines to achieve better rankings in search results.

The core of this mindset is “passive adaptation”:

Optimizing meta tags for Google to understand the content
Creating a sitemap to make indexing easier for crawlers
Using canonical tags to avoid duplicate content penalties

These are all important, of course, but they are all about “playing by the rules.”

GEO: A New Paradigm Designed for the AI Era

What I wanted was an architecture that could “proactively empower”—one that could not only be understood by search engines but also be understood, generated, and recommended by AI systems.

This is what I call the GEO (Generative Engine Optimization) mindset:

GEO Mindset: Providing structured signals to AI generative engines, enabling AI to understand, reason about, and generate answers based on your content.

Dimension	SEO Mindset	GEO Mindset
Goal	To be understood and ranked by search engines	To be understood, reasoned with, and generated by AI
Means	Meta tags, Keywords	Structured data, Semantic signals
Interaction	Passively adapting to crawler rules	Proactively providing AI-usable signals
Outcome	Ranking in search results	Being cited, recommended, and generated by AI

Applied to a multilingual architecture, this means:

Clear Language Signals: Not just a lang attribute, but also bidirectional hreflang links, so AI clearly understands the relationship between different language versions.
Structured Content Hierarchy: Language → Topic → Category → Article, allowing AI to infer the organizational logic of the content.
Intelligent Fallback Mechanism: When a language version doesn’t exist, it shouldn’t be a 404. Instead, it should provide the original language version with a language notice, ensuring the best experience for both users and AI.

This isn’t just a difference in technical implementation; it’s a paradigm shift in thinking.

Once I had this goal clearly defined, the next question was: How can one person achieve such an architecture?

Chapter 2: HOW - How AI Became My Technical Co-founder

This was the most exciting part of the entire process: how I collaborated deeply with AI to find the optimal solution.

Round 1 Brainstorming: AI Proposes the Theoretically Optimal Solution

I first presented this challenge to Gemini (my primary research-oriented AI collaborator):

“I need to build a multilingual website architecture that can:

Use English URLs for English articles and Chinese URLs for Chinese articles.

Intelligently fall back to the original language when a specific language version doesn’t exist.

Be SEO-friendly and avoid duplicate content issues.

Have a clean and maintainable architecture.”

Gemini provided a “textbook” solution: the 301 Redirect approach.

The logic was elegant:

User visits /en/ai/tools/article-name
  ↓
  Check: Does the English version exist?
  ↓
  No → 301 redirect to /ai/tools/article-name (Chinese version)
  ↓
  Front-end displays a language notice banner

The advantages of this solution:

✅ Perfect for SEO: A 301 tells search engines, “this URL has permanently moved to another URL.”
✅ Great User Experience: The browser redirects automatically and seamlessly.
✅ Web Standards Compliant: Standard use of HTTP status codes.

Gemini even provided the specific Astro middleware implementation code.

My first reaction was: “This is perfect! Let’s do it!”

Round 2 Stress Test: AI Plays Red Team, Highlighting Practical Challenges

But I didn’t start coding immediately. As an experienced developer, I know there’s often a huge gap between “theoretically optimal” and “practically feasible.”

So, I took this solution to Claude Code (my implementation-oriented AI collaborator) for a “stress test.”

Claude Code’s response brought me back to reality:

“The 301 solution is ideal in a dynamic server environment (SSR), but your site uses output: 'static' for static generation. This means:

You can’t execute 301 redirects at build time: Static sites have no server-side logic.

Vercel’s Edge Middleware could handle it: But it would add latency to every request.

Scalability Issues: If you have 1000 articles in the future, with 100 having English versions, you’d need 900 redirect rules.

Maintenance Cost: You’d have to update the redirect configuration every time you add a new article.”

This was a classic “AI Red Team” analysis: not dismissing the solution, but pointing out the hidden technical debt and long-term risks.

Round 3 Solution Convergence: Human-Machine Collaboration to Find the Golden Mean

Faced with differing opinions from two AIs, the role of the decision-maker fell back to me.

This is the essence of “AI as a Capability Amplifier”: AI provides expert analysis, but the final trade-offs and decisions must be made by a human.

My thought process went like this:

Current Stage: The site is just starting out, content volume is small, and the performance advantage of static generation (Lighthouse 100 score) is a core competitive edge.
Future Scalability: If the site really grows to 1000+ articles, I’ll have the resources to migrate to SSR then.
User Experience: Even without a 301, I can achieve 90% of the desired effect with a combination of canonical, noindex, and a language notice banner.
Technical Debt: Choosing a “modified static fallback” solution keeps the technical debt manageable.

In the end, I adopted an elegant combination of Canonical + Noindex + Smart Fallback:

---
// Intelligently determine if it's a fallback page
const isFallbackPage = contentLang !== currentInterfaceLang;

// Construct the correct Canonical URL
const canonicalUrl = isFallbackPage
  ? `https://brianjhang.com/${originalSlug}`  // Points to the original language version
  : currentUrl;  // The true language version points to itself
---

<!-- SEO Meta Tags: The Smart Fallback Solution -->
<link rel="canonical" href={canonicalUrl} slot="head" />

{isFallbackPage ? (
  <>
    {/* Fallback Page: No index, points to the original version */}
    <meta name="robots" content="noindex, follow" slot="head" />
    <link rel="alternate" hreflang="zh-Hant" href={chineseUrl} slot="head" />
  </>
) : (
  <>
    {/* True Language Page: Bidirectional hreflang */}
    <link rel="alternate" hreflang="en" href={englishUrl} slot="head" />
    <link rel="alternate" hreflang="zh-Hant" href={chineseUrl} slot="head" />
    <link rel="alternate" hreflang="x-default" href={englishUrl} slot="head" />
  </>
)}

The beauty of this solution is:

✅ No server-side logic required: Purely static generation.
✅ SEO-friendly: noindex prevents duplicate content, and canonical points to the authoritative version.
✅ User-experience first: A notice banner is displayed when the language doesn’t match.
✅ Manageable technical debt: Managed through configuration files, easy to maintain.

Chapter 3: WHAT - The Final AI-Native Architecture and Its Results

Core Architecture: Unified Slug Format + Smart Fallback

After multiple rounds of discussion with my two AI collaborators, I established a clear multilingual architecture:

1. Unified Slug Format: Language → Topic → Category → Article

# Chinese Article
slug: "ai/tools/astroedge-complete-guide"
# Generated URL: /ai/tools/astroedge-complete-guide/

# English Article
slug: "en/ai/tools/astroedge-complete-guide"
# Generated URL: /en/ai/tools/astroedge-complete-guide/

The design of this format follows the GEO mindset:

Clear Hierarchy: AI can infer “this is a tools-category article under the AI topic.”
Explicit Language Signal: The en/ prefix is the most intuitive language identifier.
Easy to Extend: Adding other languages in the future (like Japanese ja/) simply follows the same pattern.

2. Astro Configuration: Enabling i18n Routing

// astro.config.mjs
export default defineConfig({
  site: 'https://brianjhang.com',
  i18n: {
    defaultLocale: "zh",
    locales: ["zh", "en"],
    routing: {
      prefixDefaultLocale: false  // No prefix for Chinese
    }
  },
  output: 'static',  // Static generation for maximum performance
});

3. Dynamic Route Handlers: Strict Language Separation

Chinese Routes (src/pages/ai/[...slug].astro):

export async function getStaticPaths() {
  const aiPosts = await getCollection('ai');

  // Only generate Chinese routes for Chinese articles
  const chinesePosts = aiPosts.filter(post => {
    const isEnglish = post.data.lang === 'en' ||
                     post.slug.startsWith('en/');
    return !isEnglish;
  });

  return chinesePosts.map((post) => {
    // Remove 'ai/' prefix to generate the route parameter
    let slugParam = post.slug.replace('ai/', '');

    return {
      params: { slug: slugParam },
      props: post,
    };
  });
}

English Routes (src/pages/en/ai/[...slug].astro):

export async function getStaticPaths() {
  const allAIPosts = await getCollection("ai");

  // Smart post selection: English first, Chinese as fallback
  const getSmartPostSelection = (posts) => {
    const postMap = new Map();
    const englishPosts = [];
    const chinesePosts = [];

    posts.forEach(post => {
      const language = post.slug.startsWith('en/') ? 'en' : 'zh-tw';
      if (language === 'en') {
        englishPosts.push(post);
      } else {
        chinesePosts.push(post);
      }
    });

    // First, process Chinese articles as fallbacks
    chinesePosts.forEach(post => {
      let baseSlug = post.slug.replace('ai/', '');
      postMap.set(baseSlug, post);
    });

    // English articles override Chinese ones (higher priority)
    englishPosts.forEach(post => {
      let baseSlug = post.slug.replace('en/ai/', '');
      postMap.set(baseSlug, post);
    });

    return Array.from(postMap.values());
  };

  const smartPosts = getSmartPostSelection(allAIPosts);

  return smartPosts.map(post => {
    let slugParam = post.slug
      .replace('en/ai/', '')
      .replace('ai/', '');

    return {
      params: { slug: slugParam },
      props: { post }
    };
  });
}

The genius of this code lies in the getSmartPostSelection function:

It uses a Map data structure to ensure each base slug corresponds to only one article (preventing duplicates).
It’s a two-stage process: first, add Chinese articles as fallbacks, then override them with English articles.
The result: The English interface prioritizes showing English articles, and when an English version doesn’t exist, it automatically falls back to the Chinese version.

4. SEO Meta Tags: Dynamic Logic + Dual Strategy

---
// Determine if it's a fallback page
const contentLang = post.data.lang ||
  (post.slug.startsWith('en/') ? 'en' : 'zh-TW');
const isFallbackPage = contentLang !== 'en';

// Construct URLs
const currentUrl = `https://brianjhang.com/en/ai/${Astro.params.slug}`;
const canonicalUrl = isFallbackPage
  ? `https://brianjhang.com/${post.slug}`
  : currentUrl;

const chineseUrl = `https://brianjhang.com/${post.slug.replace(/^en\//, '')}`;
const englishUrl = contentLang === 'en' ? currentUrl : null;
---

<!-- Canonical -->
<link rel="canonical" href={canonicalUrl} slot="head" />

{isFallbackPage ? (
  <>
    <!-- Fallback Page Strategy -->
    <meta name="robots" content="noindex, follow" slot="head" />
    <link rel="alternate" hreflang="zh-Hant" href={chineseUrl} slot="head" />
  </>
) : (
  <>
    <!-- True English Page Strategy -->
    <link rel="alternate" hreflang="en" href={englishUrl} slot="head" />
    <link rel="alternate" hreflang="zh-Hant" href={chineseUrl} slot="head" />
    <link rel="alternate" hreflang="x-default" href={englishUrl} slot="head" />
  </>
)}

Technical Breakdown:

isFallbackPage Logic: Compares the content language with the current interface language.
Fallback Pages:
- noindex: Tells search engines not to index this page (avoids duplicate content).
- canonical points to the original Chinese version: Tells search engines where the authoritative version is.
- Only provides the zh-Hant hreflang.
True English Pages:
- canonical points to itself.
- Provides bidirectional hreflang (English ↔ Chinese).
- x-default points to the English version (as the default for international users).

When a user sees a Chinese article on the English interface (triggering a fallback), they will see this banner:

<!-- LanguageNotice.astro -->
<div class="language-notice-banner">
  <div class="notice-content">
    <span class="notice-icon">📢</span>
    <div class="notice-text">
      <h4>This article is currently only available in Chinese.</h4>
      <p>You are now viewing the original version.</p>
    </div>
  </div>

  <div class="notice-actions">
    <button onclick="translatePage()" class="btn-translate">
      🌐 Translate to English
    </button>
    <a href="/en" class="btn-back">
      ← Back to English Content
    </a>
    <button onclick="dismissNotice()" class="btn-dismiss">×</button>
  </div>
</div>

<script>
  function translatePage() {
    const currentUrl = window.location.href.split('?')[0];
    const googleTranslateUrl =
      `https://translate.google.com/translate?sl=auto&tl=en&u=${encodeURIComponent(currentUrl)}`;
    window.open(googleTranslateUrl, '_blank');
  }
</script>

Design Thinking:

Clear Information: Tells the user, “This article is currently only available in Chinese.”
Provide Solutions:
- Option 1: Use Google Translate to automatically translate (opens in a new tab).
- Option 2: Return to the English content list.
Respect User Choice: Provides a dismiss button and remembers the user’s choice (using sessionStorage).

Technical Achievements: The Data Speaks for Itself

After implementing this architecture, I achieved the following results:

Metric	Data
Total Pages Generated	77
Duplicate Pages	0
Build Time	~13 seconds
Lighthouse Performance	100/100
SEO Errors	0
Language Display Confusion	0

SEO Checklist:

✅ Every page has the correct canonical URL.
✅ Fallback pages use noindex to avoid duplicate content.
✅ Bidirectional hreflang tells search engines the language relationship.
✅ Structured data (Schema.org) is complete.
✅ URL structure is clean and semantic.

Conclusion: An Amplifier, Not a Replacement - The Future Workflow for AI Solopreneurs

Core Thesis: AI is a “Capability Amplifier” for Individual Entrepreneurs

After building this multilingual architecture, my most profound insight is this:

AI is not here to replace me; it’s here to amplify my capabilities.

In this process:

Gemini played the role of “Researcher”: providing the theoretically optimal solution and implementation ideas.
Claude Code played the role of “Engineer”: pointing out practical challenges and providing feasible solutions.
I played the role of “Decision-Maker”: weighing the pros and cons to make the final choice.

This is not a simple linear process of “ask AI → get an answer → execute.”

It’s an iterative cycle of “pose a problem → AI analysis → stress test → human decision → implementation and verification.”

A Replicable Workflow

Distilling this experience into a replicable methodology:

Phase 1: Establish a Global Vision

Clarify the goal: Not just multilingual, but AI-native.
Define principles: GEO mindset over SEO mindset.
Set constraints: Static generation, performance-first, maintainability-first.

Phase 2: Collaborate with AI to Overcome Challenges

Round 1: Seek the theoretically optimal solution from a research-oriented AI (Gemini).
Round 2: Conduct a stress test with an implementation-oriented AI (Claude Code).
Round 3: The human makes the trade-off decision to find the current optimal solution.

Phase 3: Build a Lean Product

Implement the core architecture.
Verify technical metrics (Build, SEO, Performance).
Document the decision-making process (this article is an example).

Looking Ahead: The Foundation is Laid, Ready for Launch

The multilingual architecture of Brian Jhang’s Edge is now complete.

The significance of this architecture is not just a technical success; it’s a validation of my capabilities as an “AI Solopreneur”:

✅ It proves that one person can build a complex system that used to require a team.
✅ It validates the importance of the GEO mindset in the AI era.
✅ It establishes a replicable AI collaboration workflow.

Next, I will apply the same model to open the next chapter: building AI products that generate revenue.

The foundation is solid. The ship is ready to set sail.

Let’s witness together how far an AI solopreneur can go.

🔗 Related Resources

Project GitHub - Full source code and technical details
Astro i18n Official Docs

💡 Key Takeaways

AI is a “Capability Amplifier,” not a “Task Replacer.”
GEO Mindset > SEO Mindset (in the AI era).
Theoretically Optimal ≠ Practically Feasible (the importance of pragmatic decisions).
Manageable Technical Debt > Over-engineering (the lean startup principle).

📢 Build in Public This article is part of my “Build in Public” series. If you’re interested in entrepreneurship, technical development, and personal branding in the AI era, feel free to follow my updates.

Let’s explore the infinite possibilities of AI × Startups × Crypto together.

🤖 This article was written by Brian Jhang, documenting a real collaboration process with Claude Code and Gemini.