Why We Rebuilt Feisworld for AI Brand Visibility

The migration that taught me a website is not just a place to publish. It is a memory system.

The first signs were small. A cleanup report. A weird URL. An old image wrapper that should not have been in public data anymore. A service page that still described a version of Feisworld we had already outgrown.

None of these things broke the site. That was the tricky part. They were not dramatic. They were the kind of issues you can live with for years because the homepage still loads, the blog still works, and readers do not know what is happening underneath.

But once we started looking closely, the list kept growing. Old Optimole image wrappers were showing up in public data. Legacy author URLs still existed. Some schema decisions made sense only because a plugin had emitted them years earlier. Together, they showed us that the site was carrying too much history in places nobody could easily see.

I have worked with Fei since 2016, across podcast edits, documentary cuts, YouTube production, blog updates, partner content, and the quiet decisions that never get their own headline. I knew the work was there. I also knew the site was starting to ask readers to connect too much of it by themselves.

So here is the plain answer: AI brand visibility is how clearly your brand appears when people use search engines and AI tools to research, compare, and choose. We rebuilt Feisworld Media because the site needed to explain 15+ years of work more clearly.

Feisworld did not lack proof. The Feisworld Podcast has more than 400 episodes. The YouTube channel has more than 1,000 videos and 5M+ lifetime views. The blog has 900+ published articles. Fei co-created a documentary that streams on Amazon Prime Video. She writes for CNET, Lifehacker, and PCMag. Our partner work includes Adobe, ElevenLabs, Riverside, Synthesia, Descript, Ecamm, and Vercel’s v0.

The problem was that the proof had become too spread out. Some of it was old. Some of it was plugin-dependent. Some of it was hard for a reader, a search engine, or an AI tool to connect.

This is where I want to start the migration series, before the architecture diagrams and plugin replacement stories. We moved away from a traditional WordPress site into a headless WordPress, Next.js, Turso, Vercel, and Ops-based publishing system, but the bigger question came first.

Fei and I often come back to the same phrase for the company: High on Content. Longevity over urgency. Craft over algorithm chasing. First-person experience over generic advice. This migration forced us to apply that idea to the site itself.

What Is an AI-Ready Website?

To me, an AI-ready website is honest and easy to read, for people first and machines second. It should tell the same story through its pages, links, schema, media, and archive.

Some people call this GEO, AEO, LLMO, AI search optimization, or AI visibility. I do not love adding acronyms unless they help, but inside Feisworld we often describe the larger strategy as Contextual Footprint Optimization. The idea is to build enough accurate, cross-platform context that a brand becomes easier for humans, search engines, and AI systems to understand.

The everyday question I kept coming back to was simple. If someone reads our site, or if a model retrieves it, do they come away with an accurate picture of who Feisworld is now?

That meant the blog, podcast, YouTube channel, author pages, partner pages, About pages, schema, redirects, and internal links had to support the same basic story.

Google’s own guidance for generative AI features still points people back to familiar fundamentals. That includes helpful content, technical clarity, crawlability, page experience, useful images and video, and content made for people. The official guide is here: Google Search Central’s guide to optimizing for generative AI features.

That matched what we were seeing in practice. AI search made the old work more visible, including the messy parts.

When the Redesign Became an AI Search Visibility Problem

We had been here before.

Years ago, we moved from Squarespace to WordPress. That migration made sense at the time. Squarespace was becoming too slow and too limiting for what we needed, especially as the content archive grew. WordPress gave us more control, more plugin options, and a better publishing workflow.

That move worked in many ways. The site looked better. It performed better. We were able to publish more seriously.

But the old content curation was mixed. Some legacy blocks stayed ugly. Some posts had formatting that only made sense inside the old system. A few things were semi-broken even after hours of manual cleanup. Anyone who has migrated a content-heavy site probably knows this feeling. You fix the urgent things, you ship, and then the leftover edges live with you for years.

This time, the standard was different. “Does the page load?” was only the first question. We also had to ask whether old posts still represented Feisworld correctly. Did author data match the About pages? Did old URLs redirect to the right place? Did the schema describe facts a person could actually see on the page?

Those questions changed the project. What started as a site migration became an editorial audit, a technical rebuild, a content curation pass, and a brand positioning project.

Why AI Brand Visibility Changed the Standard

In our updated guide, How to Build a Brand in 2026, we talk about AI brand visibility as part of brand building. The short version is simple: people still search Google, read blogs, and watch YouTube. They also ask ChatGPT, Gemini, Claude, Perplexity, and Google AI features to summarize, compare, and recommend.

If the material about your brand is unclear, those tools have less to work with.

If your brand is described one way on your About page, another way on old service pages, another way in schema, and another way in partner content, the confusion is not cosmetic. It can affect how people understand you. It can also affect how search systems classify you. And it can affect whether AI tools describe the current version of your brand.

I am careful with this topic because nobody can guarantee AI mentions. We do not guarantee that for Feisworld, and we would not promise that to a partner. AI answers change. Search results change. Models behave differently. Even prompt wording can change the response.

What we can improve is the material those systems may use.

That is why we paid attention to the whole body of work:

• Our About page and Feisworld Media page.
• Fei’s author profile and my author profile.
• The podcast archive and guest history.
• YouTube content and partner pages.
• Schema markup and metadata.
• Redirects from old services and old URLs.
• Images, video embeds, and old WordPress formatting.
• The llms.txt file as a curated orientation page, not a magic ranking file.

Research outside Feisworld points in the same direction. Ahrefs studied AI visibility factors across 75,000 brands and found strong correlations around YouTube mentions and broader branded mentions. Correlation is not causation, and I do not want to oversell it. But it supports what we already believe from practice: your website, videos, articles, transcripts, and partner content should not be treated as separate islands. You can read the Ahrefs research here: Top Brand Visibility Factors in ChatGPT, AI Mode, and AI Overviews.

This is also why the Adobe and Semrush news caught my attention. I want to name the context clearly: Fei is an Adobe Global Ambassador, and Feisworld has written extensively about Adobe tools. I am mentioning the acquisition here because it is directly relevant to AI visibility, not because every creator or small business needs Adobe or Semrush.

Adobe completed its acquisition of Semrush in April 2026. In the announcement, Adobe framed brand visibility across search, generative engine optimization, and agentic search as an important business problem. We wrote about that here: Adobe Acquires Semrush. You can also read Adobe’s official announcement here: Adobe completes Semrush acquisition.

The point for smaller teams is not the enterprise software. The point is that discovery is changing. Brand visibility now includes being understood across many surfaces.

The Old Site Was Not Broken. That Was the Problem

WordPress helped Feisworld publish for years. It gave us Gutenberg, a familiar editorial interface, media management, authoring tools, categories, tags, and a large ecosystem. The problem was the amount of history around it.

Over time, the site had collected plugin decisions, image wrappers, SEO settings, affiliate link rules, shortcodes, old blocks, old service pages, old redirects, and old assumptions. Some choices were useful at the time. Some stayed because they still worked well enough. Some were hard to inspect because they lived inside plugin settings.

That is normal for a long-running website. You solve the problem in front of you. Then three years later, the solution becomes part of the next problem.

Here are a few examples.

Images: We had years of WordPress uploads, Optimole URLs, external image references, and old formatting. Some images were fine. Others needed cleanup. We also wanted the live site to be less dependent on hitting WordPress media every time.

SEO settings: Rank Math had helped us for years, but we wanted schema, redirects, 404 monitoring, sitemaps, and metadata to be part of a more deliberate system. We did not want every SEO decision hidden inside plugin settings.

Affiliate links: Tools like ThirstyAffiliates helped a lot when affiliate links were mostly manual. But our affiliate work is more data-driven now. Many partner platforms expose APIs or other integration points. We wanted our own system to import, map, monitor, and maintain links inside the Ops dashboard.

Old content: Feisworld has posts from many different seasons of the company. Some are still strong. Some are historically important. Some needed formatting cleanup. Some needed to be redirected, merged, or simply understood in context.

Entity clarity: Feisworld, Feisworld Media, Fei Wu, my role, the podcast, the documentary, the YouTube channel, and our partner work all needed clearer relationships. This matters for humans first. It also matters for search and AI systems.

The old site had many small pieces of friction. With AI search, those small pieces felt less acceptable.

How Feisworld moved from plugin-owned public decisions to a human-approved publication system.

The System We Built: Headless WordPress, Next.js, Turso, Vercel, and Ops

Once we stopped thinking of the rebuild as a theme change, the system became easier to explain. The new Feisworld site is a publishing system with several jobs separated cleanly.

At a high level, it works like this:

• WordPress remains the CMS for writing. Fei and the team can keep using a familiar editorial interface.
• Ops becomes the review layer. We use it for curation, redirects, affiliate links, monitoring, content decisions, and checks that do not belong inside a writing interface.
• Turso stores the approved content state. Instead of pulling everything live from WordPress for every page, we keep a cleaner, reviewed version of the content that the frontend can trust.
• Next.js renders the public site. It controls the frontend, routing, schema, author pages, sitemaps, metadata, and user experience.
• Vercel hosts and deploys the site. It gives us previews, fast deployments, image optimization, performance tooling, and a modern deployment workflow.
• Cloudflare supports the domain and legacy routing layer. That helped us keep the migration controlled.

We could have kept a traditional WordPress frontend and cleaned up the theme. We could have pulled live from WordPress GraphQL on every page. We could have moved everything into Markdown. We could have moved to another CMS. We looked at those options seriously.

The reason we chose this setup is that it gave us editorial comfort, frontend control, and future portability at the same time. I did not want to solve one migration by creating the next trap.

Fei did not need a system that made publishing harder. We also did not want a system where every public page depended on WordPress being perfect at the exact moment a reader arrived.

Vercel has a useful article about the logic of headless WordPress with Next.js and Vercel, especially the idea of keeping the strength of WordPress while improving security, performance, and resilience. You can read it here: Secure, headless WordPress with Next.js and Vercel.

Our version added another layer: Ops and Turso. That layer mattered because we were reviewing posts before the public site trusted them.

For a small site, live CMS data may be fine. For Feisworld, we wanted a curated state between “this exists in WordPress” and “this should appear on the public site exactly this way.” That difference sounds small until you are responsible for hundreds of old posts.

Why We Kept WordPress in a Headless Next.js Migration

Keeping WordPress was practical. Fei and the team already knew how to write there. The archive already lived there. Replacing it would not automatically solve the public-site problems we cared about.

The bigger decision was to separate the jobs. WordPress handles authoring. Next.js handles the public frontend. Vercel handles deployment and performance. Turso holds the approved content state. Ops turns editorial judgment into a workflow.

That separation also keeps the design less technology-dependent than it may look from the outside:

• Keep the writing experience separate from the public frontend.
• Keep approved content state separate from raw source content.
• Keep redirects, affiliate links, monitoring, and curation decisions visible inside Ops.
• Keep the brand record clean enough that another frontend or CMS could take over later.

That last point matters. A migration should not trap you inside the next migration.

How AI Helped Me See More Without Taking Over

I am not going to pretend this project would have happened the same way without AI. It would not have.

AI helped us run curation passes over old content. It spotted repeated problems. It found weird patterns in legacy blocks, image URLs, redirects, schema issues, stale pages, and wording that no longer matched the company. It helped draft code scaffolding, summarize logs, stress-test assumptions, and act as a picky reviewer when we needed another point of view.

One concrete example: we used scripts and AI-assisted review to clean old Optimole wrapper URLs from Turso-owned public data, especially stored JSON-LD enrichment fields. That work is boring, detailed, and easy to get wrong by hand. AI was good at not getting bored. I was still the one checking whether the fix made sense.

That is where AI shines in web development right now. It can help design buttons, lay out responsive pages, compare interface states, scaffold components, and generate test ideas. Tools like v0 were especially useful for design exploration and responsive UI thinking, which connects to our earlier guide on using AI to generate website layouts. We will write a full article about v0 later in the series.

It took more than two months. It involved technical direction, editorial decisions, manual review, adversarial review, deployment checks, SEO checks, performance checks, and a lot of unglamorous cleanup. Some nights, the best use of AI was letting it keep working while I slept, then reviewing the output with a clear head in the morning.

AI made the work faster. The decisions were still ours.

That distinction is important, because a site like Feisworld carries real claims. If we say Fei writes for CNET, Lifehacker, and PCMag, that needs to be true. If we say the podcast has 400+ episodes, that needs to be true. If we connect guest names to old podcast posts, those links need to exist. If schema describes the company, it should match what a person sees on the page.

AI can suggest, check, and compare. It can also make mistakes with great confidence.

Our rule was simple: AI could help us see more, but humans made the final calls.

Where I Refused to Let AI Decide

Voice was one of the easiest places to spot a wrong answer.

Fei’s writing does not sound like a SaaS landing page. Mine does not either, at least not when I am paying attention. The Feisworld voice is practical, warm, and willing to admit what did not work. Fei’s line for the company has always stayed close to the same idea: “The creator economy sells urgency. I’m interested in longevity.”

That became a useful test for this migration. If a proposed paragraph made the project sound shiny but not lived-in, I usually cut it.

I also refused to accept a sentence just because it sounded plausible.

That meant we still needed human review for:

• Final article language.
• Claims about partners, guests, numbers, and publications.
• Redirect decisions.
• Schema and metadata claims.
• Which old pages should remain, redirect, or disappear.
• Which content should be refreshed now versus left alone.
• Whether a technical shortcut was worth the maintenance cost.

This is where AI-assisted work can go wrong quickly. Momentum feels good. Without small checkpoints, you can build a very polished wrong answer. Our workflow was slower than the fantasy version of AI, and still much faster than doing everything manually.

The Tradeoff I Kept Coming Back To

The biggest caveat is maintenance.

When you replace plugins with your own systems, you gain control. You also accept responsibility.

A plugin is not just a feature. It is also a group of developers, documentation, defaults, bug reports, and thousands of users pushing the tool into situations you may never see. That has value.

A custom system is different. It can fit your workflow beautifully, but only if you maintain it. You have to know what it does, why it exists, and what breaks if you change it.

For us, the tradeoff made sense in areas where Feisworld had very specific needs.

Affiliate links are one example. Our current needs go beyond manual link cloaking. We want to pull partner data from affiliate platforms, map links to our own /go/* URLs, monitor broken destinations, update links when programs change, and keep everything aligned with editorial content. That workflow is specific to how Feisworld works with partners.

Content monitoring is another example. We did not only want a score that said “update this post.” We wanted to connect Google Search Console, GA4, Ahrefs, YouTube data, WordPress dates, partner context, and editorial judgment. We wanted to know what was stale, what was declining, what was evergreen but due for a refresh, and what was becoming more important.

That is why we built Ops. Most websites do not need an Ops dashboard. Feisworld did because the generic path was starting to cost us more than the custom one. That is not a universal recommendation. It is an honest admission of our own use case.