How I rebuilt nielskaspers.com as an AI landing page

If you want the short answer, I rebuilt nielskaspers.com so the homepage acts like an AI landing page, while deeper pages do the proof, comparison, and conversion work around it.

That was the core decision.

I did not want the site to behave like an online resume with a blog attached. I wanted it to explain who I am, what I build, what I have proof in, and where a curious operator should go next after an AI answer or a branded search.

That sounds obvious. Most personal sites still do not do it.

The current AI-search conversation is useful here because it keeps circling back to the same underlying point. Google still says pages need to be crawlable, indexable, and eligible for snippets to appear in AI features. Its docs on AI features and your website, the AI optimization guide, and crawlable links all point back to structure. The live SEO chatter on July 8 and July 9 sharpened that with newer language: internal links, llms.txt, entity files, and AI audits are all proxies for one broader question. Does the site explain itself clearly to machines and humans?

That is the frame I used for this rebuild.

The job was not just to look good

A lot of personal-site rebuilds optimize for taste first.

I care about taste too, but the main job here was functional clarity.

I wanted the site to answer five questions quickly:

who is Niels Kaspers
what topics does he actually have receipts in
what products and systems prove that work
which pages answer deeper operator questions
where should a reader go next if they care about PM, growth, AI workflows, or product building

That is why I keep using the phrase AI landing page.

I explained the traffic side of that earlier in Your homepage is now an AI landing page, not your citation engine. This report is the implementation layer underneath that thesis. It is about the actual rebuild choices: homepage sections, navigation, entity packaging, supporting routes, and how the page graph helps the site explain itself.

1. I made the homepage an orientation layer, not a proof dump

The homepage does not try to win every query.

It tries to orient the visitor and the crawler fast.

That is why the page now leads with strong identity and role signals, then routes outward into the surfaces that deserve more depth. In the code, the homepage also carries explicit AboutPage and ItemList schema tying the site to my work history, role, and significant links. Those links point to /blog, /products, and /speaking, which is a small choice but an important one. It tells search systems what this domain considers core context.

I also made the homepage section order do real work. It moves through a visible operator story: hero, builds, work styles, timeline, systems, speaking, and then recent writing. That is a different experience from a generic personal site where every section looks equally important.

The point was to give both humans and AI systems a quick map of the territory.

If someone lands on the homepage after hearing my name in ChatGPT, Google AI Mode, Perplexity, or a citation inside another answer, they should understand the domain fast.

If a crawler lands there, it should also be obvious that this site is not just one long biography. It is a structured surface with products, systems, reports, and insight pages that connect to each other.

2. I stopped expecting one page to do every job

This was the biggest architectural shift.

I did not want the homepage to be the citation engine, the product explainer, the PM advice hub, and the conversion page all at once.

So I split the jobs more aggressively:

the homepage handles branded orientation and routing
reports handle sharper evidence-led takes and first-party receipts
insights handle evergreen answer assets and decision pages
systems explain repeatable workflows and operating models
products give real first-party surfaces behind the ideas

That split made the whole site easier to understand.

It also made the newer pieces stronger. How to structure pages for AI citations and real conversions works because it does one job cleanly. Why your product page needs a context layer, not just a feature grid works because it handles a specific product-surface problem. Internal links matter more in AI search than most teams think works because it focuses on routing and proof movement.

Once the homepage stopped trying to carry all of that alone, the whole graph got clearer.

3. I used first-party surfaces to make the site easier to trust

This is where a personal site can beat generic commentary.

I do not need to pretend expertise in the abstract. I can point to actual products, actual workflow systems, and actual shipped pages.

That is why the rebuild pushed product and system surfaces much harder.

On the product side, pages like PDFTry, ScreenshotEdits, and PeerWealthy are not side decorations. They are proof surfaces. They help explain what I build, which categories I understand, and what kinds of tradeoffs I have real receipts in.

On the system side, pages under /systems give the site a reusable operating layer. They let a reader move from a claim in an article to a process page that explains how the work actually happens.

That matters because AI systems do not only reward nice phrasing. They reward pages that feel grounded.

Google's How Search works documentation is still a useful reminder here. Discovery depends on links, sitemaps, and structure. But trust depends on what those discovered pages actually reveal once they are found. A site with products, systems, and first-party reports does a better job of explaining its own authority than a site that only posts broad opinion pieces.

4. I designed routes around operator questions, not only around content types

This is the part I think more sites should steal.

It is not enough to have a blog, a products page, and a systems page. The routes have to help someone move through a real question.

For example:

a PM who wants workflow leverage can land on AI workflows for product managers that actually save time, then move into PM-specific systems and reports
a growth operator can move from How to structure pages for AI citations and real conversions into internal-linking, product-context, and programmatic-SEO reports
a product-curious visitor can go from the homepage into PDFTry or ScreenshotEdits, then back out into the supporting strategy pieces

That is why I think of the site as an answer surface, not just a content archive.

The live X chatter this week about internal links, entity packaging, and AI audits is pointing at the same problem from the outside. Most sites are still not great at helping a machine or a reader understand what the important next page should be.

So I tried to make the routes do more of that work explicitly.

5. I made the homepage broader than the citation assets on purpose

One subtle mistake I see all the time is trying to make the homepage too query-specific.

I think that usually weakens it.

The homepage should be broad enough to catch branded curiosity and AI-driven visits that arrive late in the journey. It should tell the reader what kind of operator they are looking at and what clusters exist on the domain.

The deeper pages should carry the narrower, more citation-friendly jobs.

That is why the site now leans on reports, pages, and systems for the more extractable answers, while the homepage carries a clearer entity layer.

Google's AI optimization guide does not ask for a magical new AI-only page type. It keeps reinforcing that content has to be discoverable, understandable, and useful. The homepage is useful when it orients. The deeper pages are useful when they answer. Those are connected jobs, not the same job.

That distinction also made the rebuild easier to maintain. I do not need to keep rewriting the homepage every time one topic gets hotter. I can let the deeper content carry that specificity while the homepage keeps doing identity and routing work.

6. I treated internal links as proof routing, not cleanup

The July 8 report on internal links already made the broader case, so I will keep this part focused on the rebuild itself.

When I reworked the site, I did not treat internal links as an afterthought. They were part of the architecture from the start.

That means:

reports link into products, systems, and insight pages when the next step is natural
evergreen pages point toward proof-heavy reports instead of staying abstract
product and system surfaces reinforce the same clusters instead of floating alone
the homepage previews create predictable entry points into the newest writing and key surfaces

That is also why I did not feel a need to force extra touchpoint edits for this piece. The existing latest-report surfaces and report listing already make a new report discoverable naturally.

The site graph is supposed to do that work without more manual patching every day.

7. I kept the brand visible enough for citations to become memory

One risk in AI search is earning citations that never really become a brand impression.

This site needed a clearer entity layer so that the ideas do not feel anonymous when extracted out of context.

That is one reason the homepage, biography language, work-history schema, and product surfaces all matter. The site should make it easy for a model or a human to connect the topic to the person and the receipts.

I wanted pages about PM workflows, AI search, programmatic SEO, and operator systems to feel like they belong to one coherent body of work, not like unrelated content experiments.

That is also why I care so much about linking the topic clusters together. A PM page should still reinforce the operator identity. An SEO report should still connect to products and systems. A product story should still point back to a process or growth lesson. That repeated pattern is what helps a site become legible.

What I would keep if I had to rebuild again from zero

If I were starting over, I would keep five rules.

1. Make the homepage answer identity before it answers tactics

The homepage should tell the reader who you are, what you build, and what clusters matter here. It should not try to be a long explainer for one narrow query.

2. Split citation jobs from landing-page jobs

Let deep pages answer the tactical questions. Let the homepage catch the branded or AI-assisted click and route the visitor onward.

3. Use products and systems as authority surfaces

First-party assets are a better proof layer than generic commentary alone.

A site becomes easier to use when the next step answers the next question naturally.

5. Keep the graph coherent enough that new content can slot in without extra rescue work

That is the real compounding benefit. Once the graph is clear, each new report or page has obvious neighbors.

A simple checklist I used during the rebuild

Interactive

AI landing page rebuild check

Use this when the homepage needs to orient visitors and support deeper citation assets.

Completion

0%0/5 done

This is the gap between understanding the article and actually using it.

Use this block as the practical summary, not just the article ending.
If one item feels vague, the article probably needs sharper guidance.
A short checklist beats a long recap when the reader needs to act.

My broader take

I do not think an AI landing page is a special template.

I think it is a site that knows what the homepage is for.

The homepage should orient, clarify the entity, and route the visitor.

The supporting pages should answer, prove, compare, and convert.

Once I rebuilt nielskaspers.com around that split, the site felt much more coherent. New reports had clearer neighbors. Products had a stronger supporting layer. Evergreen pages had better proof routes. And the homepage stopped feeling like it needed to carry every commercial and editorial job alone.

That is the shift I would recommend most builders make.

Do not ask whether your homepage is “optimized for AI.”

Ask whether your site explains itself well enough that AI systems and humans can both understand where the value lives.

If the answer is yes, the homepage usually becomes a better AI landing page as a side effect.