Do we need to rebuild our website for AI visibility?

Expanded answer

Rebuilds feel decisive, but they are the most expensive way to fix problems that are usually cheaper to fix in place. If crawlers are blocked, redirects are broken, or priority pages answer nothing clearly, a technical sprint plus a content and entity upgrade solves it on the current site — often within the existing design.

The calculus changes when the constraint is the platform itself. The signals: the CMS cannot model structured content (page types live as free-form pages, not collections with fields); every standard page needs a developer, so publishing capacity is near zero; the frontend renders key content only through JavaScript; templates cannot carry clean metadata and schema; or the architecture is so tangled that fixing it costs more than rebuilding it. When several of these hold at once, migration or rebuild stops being a redesign whim and becomes the rational path.

Either way the sequence is the same: audit first, quantify what the current stack can and cannot support, and let that decide — not the age of the design.

What to check

• Can the current site pass a technical sprint — access, indexation, canonicals — without platform changes.
• Can the CMS model your page roles as structured collections with fields.
• Can marketing ship a standard page without a developer.
• Is key content readable in the raw HTML, not only after scripts run.
• Can templates carry per-page metadata and structured data cleanly.

Common mistakes

• Rebuilding because the design feels old while the real blockers are technical or content-level.
• Endlessly patching a platform that cannot model structured content.
• Migrating without a redirect plan and losing the history a rebuild was meant to protect.
• Deciding by opinion instead of an audit.