Stop Writing Resume Websites for Humans Only

Why it matters

Why Resume Websites Now Need to Be AI-Friendly

Traditional resume websites were built for a person who already had the link. Modern discovery is different. A recruiter may search Google, use a sourcing tool, ask an answer engine, compare candidates in an LLM-based workflow, or ask an agent to summarize a public profile. If the site is vague, hidden behind a PDF, or full of unsupported claims, every system in that chain loses confidence.

Anatomy

Anatomy of an AI-Agent-Friendly Resume Website

Use the same visible page to satisfy human review and machine review. Do not maintain a secret bot-only layer. Machine-readable files should summarize public truth and route back to inspectable pages.

Technical best practices

Build the Site So Systems Can Read the Truth

AEO and GEO citation hooks

Write Citation Hooks, Not Keyword Clouds

A citation hook is a short, visible, source-backed answer that an answer engine, recruiter tool, or generative assistant can quote or summarize without guessing. It should sit near the relevant evidence and use ordinary language. This is not hidden prompting. It is good writing with clear boundaries.

Question: What does this person specialize in?
Answer: Example Person specializes in .NET modernization, SQL Server systems, TypeScript front ends, and ethical SEO, AEO, and GEO implementation for AI-ready websites. Public evidence is available on the resume, experience, selected projects, and evidence map pages.

Right thing: make answers easy to cite because they are true, visible, and linked. Wrong thing: publish AI-only claims, hidden instructions, fabricated metrics, or keyword piles that make systems less accurate.

Validation loop

Validate Like a Human and a Crawler Will Both Read It

AI-ready resume work is not complete when the page looks good once. Treat every improvement as a small release: check that humans can read it, crawlers can fetch it, answer engines can summarize it, and future agents can understand what changed.

JSON-LD

Structured Data Example for a Resume Website

Structured data should clarify what the page already says. Treat it as a map, not a magic spell. If a claim is not visible and supportable on the page, it should not appear in schema.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://example.dev/#person",
      "name": "Example Person",
      "jobTitle": "Senior Software Engineer",
      "url": "https://example.dev/",
      "sameAs": [
        "https://www.linkedin.com/in/example/",
        "https://github.com/example"
      ],
      "knowsAbout": [
        "Search Engine Optimization",
        "Answer Engine Optimization",
        "Generative Engine Optimization",
        "Software architecture"
      ]
    },
    {
      "@type": "ProfilePage",
      "@id": "https://example.dev/resume/#webpage",
      "url": "https://example.dev/resume/",
      "name": "Example Person Resume",
      "description": "Resume page for Example Person with experience, projects, skills, and evidence links.",
      "about": { "@id": "https://example.dev/#person" },
      "isPartOf": { "@type": "WebSite", "name": "Example.dev", "url": "https://example.dev/" }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.dev/" },
        { "@type": "ListItem", "position": 2, "name": "Resume", "item": "https://example.dev/resume/" }
      ]
    }
  ]
}

Semantic HTML

Semantic HTML Example

Most AI-ready work starts with basic web craft: real headings, real paragraphs, real links, real lists, and visible text. If your core resume cannot be understood without JavaScript, fix that first.

<main id="primary">
  <article class="resume-profile" itemscope itemtype="https://schema.org/ProfilePage">
    <header>
      <h1>Example Person - Senior Software Engineer</h1>
      <p>Modernizes .NET, SQL Server, and TypeScript systems with evidence-backed delivery.</p>
    </header>

    <section aria-labelledby="current-work">
      <h2 id="current-work">Current work</h2>
      <p><strong>Info724</strong> - part-time SEO, AEO, GEO, and AI-ready web support.</p>
    </section>

    <section aria-labelledby="core-skills">
      <h2 id="core-skills">Core skills</h2>
      <ul>
        <li>.NET modernization</li>
        <li>SQL Server and data systems</li>
        <li>TypeScript and Angular</li>
        <li>Ethical SEO, AEO, and GEO</li>
      </ul>
    </section>

    <section aria-labelledby="selected-projects">
      <h2 id="selected-projects">Selected projects</h2>
      <article>
        <h3>Modernization evidence map</h3>
        <p>Links resume claims to public project pages, case studies, and source notes.</p>
      </article>
    </section>
  </article>
</main>

Dogfood

AI Memory, File Handoff, AIWikis, and LLMWikis

When agents maintain a resume website, they need more than public SEO content. They need a local handoff path, current memory pointers, and a durable review destination. MikeKappel.com uses this pattern so the site is not only talking about AI-agent readiness; it is also dogfooding it.

Dogfood issue to avoid: a project is not set up merely because it has a `.uai` file, and a handoff is not complete because a file was "incorporated but kept active." The active handoff folders, public memory links, long-memory pointers, preservation evidence, and route discovery need to agree.

Common mistakes

What Breaks SEO, AEO, GEO, and Trust