That AI Guy

Blog / May 10, 2026 / Founder essay

Why a single page site was the wrong move for lead generation

By Joseph W. Anady. This site was a single page, hand coded, Awwwards style build for most of 2026. It got torn apart and rebuilt as a multi page property. The reasons were technical, commercial, and simple.

The single page site looked great. Google could not tell what it ranked for. Answer engines barely cited it. Conversion was fine, but search demand was not converting, because the site was not visible for the queries that mattered.

For most of 2026, thataiguy.org was a single page hand coded site. The kind of site that wins design awards. Heavy hero animation, scroll choreography, eight major sections strung together with anchor links. It was a portfolio piece in itself.

It also was not earning what it should from search. Search Console showed a pattern that is easy to misread. Plenty of impressions for the brand. A few impressions for "that ai guy" plus assorted long tail queries. But virtually nothing for the eight big query categories the studio actually served at the time: tax firm AI, real estate AI, medical AI, insurance AI, hospitality AI, ecommerce AI, construction AI, combat sports AI. Plus pricing tiers, plus AI capabilities, plus the tier by tier engine optimization framework. That was at least 28 distinct query categories a single page property was trying to rank one URL for.

Why a single page is not enough

Google does rank single page sites. It indexes them. It surfaces them for branded queries. What it does not do well is route a specific intent query to a specific section of a 7000 word page. When someone searches for "AI for tax firms," Google wants to serve a page about AI for tax firms. A single page covering eight industries plus six AI capabilities plus a full SEO tier framework does not match intent cleanly enough to win against a competitor running one dedicated page per topic.

Answer engines have an even harder time. ChatGPT, Perplexity, Claude, and AI Overviews extract concise answers. A 7000 word page with eight sections of related but distinct content is hard to extract from cleanly. The engines might cite the page for a generic query like "AI consulting," but they will rarely cite it for "best AI workflow automation for insurance agency." A studio with a dedicated page for each industry plus capability gets cited; a studio with one giant page does not.

What we changed

The rebuild created roughly 70 new URLs. Eight industry pages. Six AI capability pages. Pricing tier pages plus retainer pages. Pillar pages. An engine optimization tier by tier framework. Comparison pages. A handful of standalone pages: infrastructure, process, FAQ, the founder bio, MEGAMIND, case studies, and this blog.

Each new page targeted one or two query intents. Each page carried full schema for its content type. Each page had its own answer engine surface: a short answer near the top, an FAQ block where FAQs actually existed, speakable schema on the parts worth reading aloud. Each page had its own breadcrumb plus a clear internal link path back to the home page and related sections. The home page itself shrank from 7000 words to roughly 2000, with each former section becoming a teaser plus a link to the deep page.

What we kept

The home page kept its visual identity. The hand coded approach stayed. The custom cursor still tracked the pointer, the intro animation still ran, the page still felt like an Awwwards entry. It just did its job differently. Where before the home page tried to be the only page, it started routing visitors to the page that matched their intent instead.

The schema graph stayed consistent. The Organization, Person, and WebSite entities kept stable IDs across every page. New pages referenced those IDs rather than redefining them. That kept the entity graph clean and let answer engines understand that the studio behind the new pricing pages was the same studio behind the new AI capability pages.

The pattern is replicable

If you run a small business with a beautiful one page site that is not earning what it should, the same pattern applies. The fix is not "rebuild on a page builder" or "switch platforms." The fix is recognizing that one page can only carry one or two intents cleanly, and breaking out the rest of your service catalog into pages that match the queries your customers actually run.

A solo coach with eight workshop topics needs eight pages plus a home page. A clinic with six providers and three specialties needs nine plus pages. A tax firm with five seasonal services needs five plus pages. The math is the same. Every distinct query intent earns a page. The home page becomes the front door, not the only room in the house.

What changed next

At the time this went live, the plan was a follow up thirty days out with the actual measurement: search impressions per query category before and after, answer engine citations spotted, conversion rate change. The rebuild itself was done in one afternoon by one engineer, using the studio's own tooling and a well structured plan.

If you want the same play run on your own property, start with an assessment and an engagement scoped to what you actually need. If you would rather do it yourself, the tier by tier engine optimization framework is documented at engine optimization. None of this is gatekept. It ships faster in practice than it does in theory.

Update, July 2026

This site went through another redesign since this post published. The multi page architecture held. What changed is the subject matter itself, from small business AI tools to private AI federations that organizations own and run on their own hardware, with the same commitment to no per token metering and no rented intelligence.

One page for one intent. The home page is the front door, not the only room. If your service catalog has more than three distinct intents, more than three pages should serve them.