> Content index: https://devbio.me/blogs/llms.txt > Canonical page: https://devbio.me/blogs/machine-readable-developer-profile --- title: Machine-Readable Developer Profile: 2026 Guide description: What actually makes a developer profile machine-readable in 2026: JSON, vCard, PDF, QR, and llms.txt, plus the real AI-citation data behind the hype. keywords: machine-readable developer profile, JSON Resume, llms.txt for developers, AI-readable developer bio, structured data personal website published: 2026-08-06 updated: 2026-08-21 url: https://devbio.me/blogs/machine-readable-developer-profile word_count: 4648 --- # The Machine-Readable Developer Profile: What Actually Works in 2026 > What actually makes a developer profile machine-readable in 2026: JSON, vCard, PDF, QR, and llms.txt, plus the real AI-citation data behind the hype. Canonical: https://devbio.me/blogs/machine-readable-developer-profile Published: 2026-08-06 ## Related Pages - [How to Write a Developer Bio (With 2026 Examples)](https://devbio.me/blogs/developer-bio-components) - [Developer Personal Brand Guide: The 4-Layer Playbook for 2026](https://devbio.me/blogs/developer-personal-brand-guide) - [Developer Profile Social Preview Image: The 2026 Fix](https://devbio.me/blogs/developer-profile-social-preview) - [JSON Resume Explained: What It Is and How to Use It in 2026](https://devbio.me/blogs/json-resume-format-guide) - [Underline in Markdown: What Actually Works](https://devbio.me/blogs/underline-in-markdown) - [WebFinger for Developers: Make Your Bio Mastodon-Ready](https://devbio.me/blogs/webfinger-for-developers) - [Developer Digital Business Card in 2026: Replace Paper Cards with One Link](https://devbio.me/blogs/developer-digital-business-card) - [Developer QR Code Business Card: The 2026 Setup Guide](https://devbio.me/blogs/qr-code-business-card-developers) - [ATS-Ready Developer Resume: From GitHub Profile to PDF](https://devbio.me/blogs/developer-resume-ats-github) - [Custom Domain Developer Bio: The 10-Minute Setup](https://devbio.me/blogs/custom-domain-developer-bio) - [llms.txt Developer Profile: Let AI Tools Discover You in 2026](https://devbio.me/blogs/llms-txt-developer-profile) ![black flat screen computer monitor](https://images.unsplash.com/photo-1610563166150-b34df4f3bcd6?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTM1MDJ8MHwxfHNlYXJjaHwzfHxkZXZlbG9wZXIlMjB0ZXJtaW5hbCUyMGRhcmslMjBjb2RlJTIwQUklMjByb2JvdCUyMHNjcmVlbnxlbnwwfDB8fHwxNzg1OTc4NjkxfDA&ixlib=rb-4.1.0&q=80&w=1080) *Photo by [Radowan Nakif Rehan](https://unsplash.com/@radowanrehan?utm_source=quillly&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=quillly&utm_medium=referral)* Most advice about making your site "AI-readable" boils down to one move: add an llms.txt file and wait to get cited. As of August 2026, the actual data on that is a lot messier than the hype suggests, and most of it was published in the last three months. **A machine-readable developer profile is one that a non-human reader, an ATS parser, a contact app, a coding agent, an AI search tool, can extract accurate information from without a human translating it first.** For most developers that means six overlapping formats: an HTML page, a JSON export, a vCard, a PDF resume, a QR code, and an llms.txt file. Some of these formats are decades-old standards. One of them is eighteen months old and still contested by the company that runs the web's biggest search engine. This guide covers all six, what each one is actually good for, and the honest 2026 evidence on which of them move the needle for AI discovery and which are closer to a cargo cult. It also covers what's replacing static machine-readability entirely: a browser-level standard called WebMCP that shipped in Chrome this year. ## What Is a Machine-Readable Developer Profile? (2026 Definition) **A machine-readable developer profile is one where a program, not a person, can pull structured facts out of it reliably: your name, stack, current projects, and contact details, without a human translating the layout or scraping garbled text from a rendered screenshot first.** Your GitHub README doesn't qualify. It's a human document on GitHub's domain, formatted for a person scrolling. Your portfolio's hero section, with a headline, a subhead, and a call-to-action button, doesn't qualify either. A parser sees a wall of unlabeled `
` tags. Structure for a human eye is not the same as structure for a program. This distinction predates AI by decades. ATS software has been parsing (or failing to parse) resumes since the 1990s. RSS readers have been consuming feeds since 1999. vCard has been the standard for portable contact data since 1996. What's new in 2026 is the number of automated readers hitting a machine-readable developer profile in a single week: an ATS during a job application, a QR scanner at a meetup, a coding agent checking your library's API, and increasingly, an AI search tool or an agentic browser trying to answer "who builds X." ## The Six-Format Profile: A Framework for Machine-Readable Identity Every machine-readable claim about a personal site collapses into one of six formats that together define what this guide calls the machine-readable developer profile. Most guides on this topic cover exactly one of them, usually llms.txt, in isolation. Treating them as a single stack is more useful, because each format has a different reader, a different level of standardization, and a different amount of real-world evidence behind it. | Format | Primary reader | Standard since | Evidence it works | | --- | --- | --- | --- | | HTML + structured data | Humans, search crawlers | Ongoing (schema.org, 2011) | Strong for search, weak-to-mixed for AI citation | | JSON export (bio.json, resume.json) | Scripts, importers, other tools | JSON Resume: 2014 | Strong for portability, no citation claim | | h-card / microformats2 | IndieWeb readers, webmention senders | microformats2: 2010 | Niche but stable, non-AI use case | | vCard (.vcf) | Contact apps, phones | RFC 2426 (1998), RFC 6350 (2011) | Universal device support, non-AI use case | | PDF resume | ATS software, recruiters | N/A (format convention) | Very strong, directly gates interviews | | llms.txt | AI agents, LLMs (claimed) | llms.txt spec: Sept 2024 | Contested, see below | ![Flowchart showing one developer profile branching into six machine-readable formats: HTML, JSON, h-card, vCard, PDF, and llms.txt](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/5defe310b80f1a72db84044ca18248ecec52339d.webp) Notice the pattern: four of these six formats are old, boring, and proven. Two of them, JSON exports built specifically for AI tools and llms.txt, are new enough that the evidence is still being written. That split matters for how much time you should spend on each one, which the rest of this guide covers format by format. If you want the full breakdown of what belongs in the human-readable layer specifically, [the developer bio components guide](https://devbio.me/blogs/developer-bio-components) covers every section worth including before you worry about any of the machine formats. For how this fits into a broader professional presence, [the 4-layer developer personal brand framework](https://devbio.me/blogs/developer-personal-brand-guide) covers the human side this guide's six formats support. ## Format 1: The Human Page (and Why It's Also a Machine Format) Your HTML page is the format everyone already has, and most developers stop there. It's also, quietly, a machine format, because search crawlers and increasingly AI crawlers parse it directly. Structured data on a personal website starts with the lever most developers skip: `Person` schema.org JSON-LD embedded in the page head. This is a block of structured data, invisible to visitors, that states your name, job title, affiliations, and social profiles in a format search engines and some AI tools can parse without guessing. It's been part of the schema.org vocabulary since 2011 and costs nothing to add if your platform generates it automatically. The second lever is your Open Graph image, the card that renders when your link gets pasted into Slack, X, or a recruiting tool. This isn't machine-readable in the parsing sense, but it's the first thing both a human and a link-preview bot render, and a broken or generic OG image undermines every other format on this list before anyone reads a word. [The 2026 fix for developer profile social previews](https://devbio.me/blogs/developer-profile-social-preview) covers the specific pitfalls: cached previews, wrong aspect ratios, and platforms that ignore your meta tags entirely. DevBio generates both the Person schema and a live OG image, showing your current GitHub stars, MRR, and commit count baked directly into the card, automatically from your profile data. No template to maintain, no separate schema.org markup to write by hand. ## Format 2: JSON Exports and the IndieWeb h-card A JSON export is your profile data as plain, structured data instead of rendered HTML. Two things fall under this umbrella, and they solve different problems. **resume.json (the JSON Resume standard).** An open schema, stable at version 1.0.0 since 2014, for representing a resume as JSON instead of a Word document: `basics`, `work`, `education`, `skills`, `projects` as top-level keys. It's older than most currently-hyped AI standards and still works, which is the whole argument for boring, stable formats. [The full JSON Resume guide](https://devbio.me/blogs/json-resume-format-guide) covers the schema field by field and how to convert one into a live profile instead of a static render. **bio.json / me.json.** A platform-specific export of your full profile, not just resume fields, projects, links, skills, in a shape any script can consume. Where JSON Resume targets resume renderers specifically, a bio.json targets anything: a personal dashboard, a job-board importer, an AI agent that wants your data without touching your HTML at all. Sitting next to both is a much older, much quieter standard worth knowing about: the **h-card**, part of the [microformats2](http://microformats.org/wiki/h-card) vocabulary that's been stable since 2010. Instead of a separate file, an h-card marks up your *existing* HTML with plain classes, `p-name`, `u-photo`, `u-url`, so IndieWeb tools, feed readers, and [webmention](https://www.w3.org/TR/webmention/) senders (a W3C Recommendation for decentralized, cross-site mentions and replies) can read your identity directly from the page you already have. No new file, no new endpoint, just semantic classes on markup you're already shipping. The same semantics-over-presentation logic shows up in plain Markdown. [There's no underline in Markdown](https://devbio.me/blogs/underline-in-markdown) at all, and on GitHub the tag that survives sanitization is the semantic one (``, meaning inserted text) rather than the purely decorative one. Machine readers reward markup that says what something *is*, not what it should look like — at every layer, down to a single underlined word. The IndieWeb angle pairs naturally with WebFinger, the protocol that makes your bio discoverable to Mastodon and the wider Fediverse. [The WebFinger for developers guide](https://devbio.me/blogs/webfinger-for-developers) covers that side of the open-web stack in detail. Between h-card and WebFinger, a developer profile can plug into fifteen-plus years of open, decentralized web standards, entirely separate from, and older than, anything AI-specific. ![Diagram showing three JSON and markup formats for a developer profile: resume.json for renderers, bio.json for any script, and h-card classes marking up existing HTML for the IndieWeb](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/c1d9d538fc72383b947cc6839c33815d95c475f5.webp) ## Format 3: vCard, the Format Behind "Scan to Save My Contact" A vCard is a plain-text contact file, defined by RFC 2426 (version 3.0, 1998) and RFC 6350 (version 4.0, 2011), saved with a `.vcf` extension. When a phone camera scans a QR code encoding vCard data, the OS recognizes the format instantly and offers a native "add contact" action. No app install, no manually typing a name that autocorrect mangles, no missed digit in a phone number read off a screen at a conference. Version 3.0 remains the safer default for broad compatibility across iPhone, Android, and desktop mail clients; version 4.0 adds structure but has patchier device support. If you're building your own, target 3.0 unless you've tested 4.0 across every device your audience actually uses. This is the oldest, most boring format on this list, and also the one with the least ambiguity about whether it works. Every smartphone made in the last decade supports it natively. [The developer digital business card guide](https://devbio.me/blogs/developer-digital-business-card) and the [QR code business card setup guide](https://devbio.me/blogs/qr-code-business-card-developers) both cover this format in practice, from generating the .vcf to pairing it with a QR code for an in-person handoff. ![Card showing the scan-to-save-contact flow: a QR code encoding a vCard, scanned by a phone camera, resulting in a native add-contact prompt](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/fa92463119858f253c8a5c24f3ce10f7f7e63d4b.webp) ## Format 4: The ATS-Ready PDF Resume A PDF resume is the format every developer already maintains, and the one most likely to fail machine-readability without anyone noticing. The distinction that matters: an **image PDF** (a rendered screenshot of a layout, common from Canva or HTML-to-canvas exporters) looks fine to your eyes and returns garbage or nothing when an ATS parser tries to extract the text. A **text PDF** (compiled from LaTeX, Word, or Google Docs with a single-column layout) extracts cleanly every time. This format gates real outcomes in a way none of the AI-facing formats currently do. Roughly 99% of Fortune 500 companies run applications through an ATS before a human sees them, and formatting failures, tables, multi-column layouts, embedded graphics, are a documented cause of parse failure, not the content itself. [The full ATS-ready resume walkthrough](https://devbio.me/blogs/developer-resume-ats-github) covers the exact 30-second test to check your own PDF and the six sections that belong on it. [If your resume is still a hand-edited Word doc, a live profile that compiles the PDF for you](https://devbio.me){cta=resume-pdf} closes the gap between "I updated my bio" and "my resume reflects it" without a second editing pass. ## Format 5: QR Codes, the Bridge Between Physical and Machine-Readable A QR code isn't a data format by itself, it's a container. What makes it machine-readable is what's encoded inside: a URL, a vCard, or (less commonly) a full text payload. For a developer profile, the useful pattern is a QR code that encodes either your profile URL directly or a vCard for instant contact-saving, placed on a badge, a slide, a business card, or a laptop sticker. The failure mode worth naming: a QR code that links to a platform's generic profile URL with a tracking-heavy query string looks unprofessional and breaks on reshare, since anyone who screenshots or forwards it loses the working link. A clean, direct URL, ideally on a [custom domain](https://devbio.me/blogs/custom-domain-developer-bio), survives every hop. ## Format 6: llms.txt, the Newest and Most Contested Format llms.txt is a plain-text markdown file at your domain root, proposed by Jeremy Howard of Answer.AI in September 2024. The reasoning, in Howard's own words from the spec: "Large language models increasingly rely on website information, but face a critical limitation: context windows are too small to handle most websites in their entirety." The file gives an H1 identity, a blockquote summary, and H2-headed sections an AI tool can parse in seconds instead of fighting through navigation and JavaScript. By mid-2025, over 600 sites had adopted it, Anthropic, Stripe, Vercel, Cursor, Cloudflare among them, almost entirely developer-tool companies whose users run AI coding agents against their docs. That context matters when weighing llms.txt for developers specifically: the proven adopters are tool vendors with large doc sites, not individuals with a one-page bio. [The full llms.txt setup guide for developer profiles](https://devbio.me/blogs/llms-txt-developer-profile) covers the exact template and how to write a blockquote summary AI tools are more likely to lift. That adoption number is where most coverage of llms.txt stops. It shouldn't. ## Does Any of This Actually Get You Cited by AI? The Honest 2026 Data Here's what the most rigorous evidence available in 2026 actually shows, not what the GEO/AEO industry has been selling since 2024. **Ahrefs ran a controlled test, not a correlation study.** Published in May 2026, the study tracked 1,885 pages that added schema markup against roughly 4,000 matched control pages that didn't. The result: AI Mode citations moved +2.4%, ChatGPT +2.2%, both statistically indistinguishable from zero, and Google AI Overviews citations moved -4.6%, a statistically significant decline. Ryan Law, who reviewed the study, put it plainly: "there's no evidence that llms.txt improves AI retrieval, boosts traffic, or enhances model accuracy." ![Bar chart showing Ahrefs May 2026 controlled study results: percent change in AI citations after adding schema markup, by platform](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/cc57cd50cc27e428e69f8989e6d53532df22da0c.webp) **Google has said, on the record, that it doesn't use llms.txt.** Google's John Mueller has stated publicly that no AI system currently uses the file, comparing it to the deprecated keywords meta tag, and noting server logs simply don't show AI bots requesting it. Google's Gary Illyes reportedly confirmed the same position at a Search Central Live event: no support, no plans to add it. **A separate correlational finding complicates the picture rather than resolving it.** Across a broader six-million-URL analysis, pages already cited by AI tools were roughly three times more likely to carry JSON-LD schema (53% versus 18% for non-cited pages), but the researchers explicitly disclaim causation: sites that bother with schema tend to be larger, more established, and better-maintained generally, which is likely the real driver of citation, not the markup itself. None of this means skip the format. It means be honest about why you're adding it to an AI-readable developer bio. The case for llms.txt in 2026 isn't "you'll get cited more." It's that Chrome's own Lighthouse tool, under a new "agentic browsing" audit category shipped in 2026, now flags a missing llms.txt as a signal agents may spend more time understanding your site's structure, an infrastructure hygiene argument, not a growth-hacking one. It costs nothing to add and nothing has been shown to make it actively hurt you outside that one AI Overviews data point. Add it as table stakes, not as a citation strategy. DevBio generates a spec-compliant llms.txt automatically from the same profile data that powers your bio and resume, so it's one less file to remember to update when your stack or your numbers change. [The setup guide](https://devbio.me/blogs/llms-txt-developer-profile) covers the exact blockquote structure that makes the file worth having even under this more skeptical read. ## What's Next: WebMCP and Agentic Browsers **WebMCP is a browser-level standard, announced by Google and Microsoft at Google I/O 2026, that lets a site expose structured "tool contracts" through a** `**navigator.modelContext**` **API so an AI agent can perform an action on a page directly, instead of scraping it.** It shipped in Chrome Canary in February 2026 and reached stable channel shortly after. While llms.txt argues over whether AI reads static files, the ground has already started shifting toward something more direct. Google engineer André Cipriani Bandarra described the goal plainly: "WebMCP aims to provide a standard way for exposing structured tools, ensuring AI agents can perform actions on your site with increased speed, reliability, and precision." ![Timeline showing the progression from llms.txt as a passive file an AI agent reads, to WebMCP as an active tool contract an AI agent can call directly](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/c75c4ad0f094f1b1d947b21882c4d9d43a85541e.webp) The practical shift for a developer profile: today, an AI agent can read your llms.txt or your bio.json. Under WebMCP, a future agent could invoke a defined action, "get this developer's latest project list," "check their current availability," directly, without parsing anything. Static machine-readable files are the current baseline. Structured, callable actions are the direction things are heading. This context matters for another reason. Agentic browsers are no longer niche. OpenAI folded its standalone Atlas browser into ChatGPT's desktop app and Chrome extension in 2026, and Perplexity's Comet browser has moved into enterprise deployment with policy-based installs. A browser agent visiting a personal site on a user's behalf, and needing to extract accurate information from it, is now a mainstream product surface, not a hypothetical. That's the strongest forward-looking argument for keeping your profile machine-readable even while the citation evidence for any single format stays unsettled: the readers keep multiplying, and the format they'll expect keeps evolving. ## Machine-Readable Coverage: DevBio vs. Hand-Rolled vs. Link-in-Bio Tools Coverage across all six formats is rare precisely because most of them require separate tooling: a vCard generator, a resume-to-LaTeX pipeline, a schema.org markup library, and a manually-maintained llms.txt, stitched together by hand. | Format | Hand-rolled portfolio | Generic link-in-bio tool | DevBio profile | | --- | --- | --- | --- | | HTML + Person schema | Add manually | No | Built-in | | JSON export (bio.json) | Build it yourself | No | Built-in | | h-card / microformats2 | Add manually | No | Not automatic (add classes yourself) | | vCard (.vcf) | Build it yourself | Rare, paid tier | Built-in | | ATS PDF resume | Separate document, separate tool | No | Auto-compiled from live profile | | QR code | Third-party generator | Sometimes, paid tier | Built-in | | llms.txt | Write and maintain by hand | No | Auto-generated, stays in sync | ![Bar chart comparing how many of the six machine-readable formats each profile type covers by default: hand-rolled portfolio, generic link-in-bio tool, and DevBio](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/d9572e1965631a69c9302636a6b6fa9c12e57c7c.webp) The pattern holds across every format except one: microformats2 classing is markup-level, not data-level, so even a platform that ships everything else may not add h-card classes automatically. That's a reasonable gap since it's the lowest-stakes, lowest-evidence format on this list, but worth checking if the open-web/IndieWeb angle matters to you specifically. [See what a fully machine-readable profile looks like](https://devbio.me){cta=coverage-table} against your current setup, one format at a time. ## The Machine-Readable Profile Audit: A 12-Point Checklist Run this against your own profile before you assume any of these formats are actually in place. Most developers pass two or fewer of these twelve checks on a first attempt. ![Bar chart showing that a typical unaudited developer profile passes only 2 of 12 machine-readability checks before running this checklist](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/0de9d79d485b7f41622c8956d3cb1a648dfaa5a9.webp) **Human + structured data layer:** - [ ] Your page includes `Person` schema.org JSON-LD in the page head (view source and search for `"@type": "Person"`) - [ ] Your Open Graph image renders correctly when pasted into Slack, X, and LinkedIn - [ ] Your profile is reachable on a clean URL, ideally a custom domain, not a deep platform path **Data export layer:** - [ ] You have a resume.json or equivalent JSON export of your skills, work history, and projects - [ ] If you care about the IndieWeb, your page markup includes h-card classes (`p-name`, `u-photo`, `u-url`) - [ ] Your data export updates when your profile does, not only on the day you first created it **Contact and hiring layer:** - [ ] You have a vCard (.vcf) available, ideally reachable via a QR code - [ ] Your resume PDF passes the 30-second copy-paste test: select a paragraph, copy it, paste into plain text, and confirm it reads cleanly - [ ] Your resume PDF and your live profile show the same numbers, not a stale snapshot from months ago **AI discovery layer:** - [ ] You have an llms.txt file at your domain root with a specific, factual blockquote summary - [ ] Your llms.txt links out to your resume and your key project URLs - [ ] You understand this layer is table stakes, not a guaranteed citation lever, and haven't over-invested time in it relative to the other five ## Before and After: One Profile, Two Machine Readers Here's what the gap looks like in practice, for a real category of situation rather than a single hypothetical name. **Developer: a backend engineer with 4 years experience, one side project generating modest revenue, applying to 15 companies in a single week.** ### Before Personal site built in 2023: a hero section, an about paragraph, a projects grid, all rendered client-side with no schema markup. Resume: a two-column Canva export that looks sharp on screen. No vCard. No llms.txt. GitHub link buried in a footer. What happens: 3 of 15 ATS systems fail to parse the resume cleanly because of the column layout, dropping those applications to the bottom of the ranking before a human ever opens them. The personal site, JavaScript-rendered with no structured data, contributes nothing to how any search or AI tool describes this developer. At a meetup, sharing contact info means spelling an email address out loud. ### After (same profile, six formats covered) Same work history, same side project, configured once. The bio page carries Person schema and a live OG image. A resume.json exists and feeds a single-column, LaTeX-compiled PDF that passes the copy-paste test cleanly across all 15 applications. A QR code on a laptop sticker encodes a vCard, so a meetup contact exchange takes four seconds. An llms.txt file states the stack, the project, and current revenue in one specific blockquote, not because it's guaranteed to get cited, but because it costs nothing and Chrome's own tooling now checks for it. The outcome isn't guaranteed by adding structure alone, hiring is still a human decision. But zero applications get lost to a parsing failure that had nothing to do with the candidate's actual skill, and every format any reader touches, ATS, phone, browser, agent, gets accurate information instead of a best guess. ![Before and after comparison card: before shows a resume that fails ATS parsing and no vCard or schema, after shows all six machine-readable formats covered](https://quillly.com/serve/v1/019e3623-8b91-738d-ae30-42d5bcd996a0/images/98be83998c8579443341eb01a45753009b1d1ec9.webp) ## Frequently Asked Questions **What is a machine-readable developer profile?** It's a profile where a non-human reader, an ATS parser, a contact app, a search crawler, or an AI tool, can extract accurate structured data without a human translating a visual layout first. In practice this means covering six formats: an HTML page with schema.org markup, a JSON export, an h-card, a vCard, an ATS-ready PDF resume, and an llms.txt file. **Is llms.txt actually used by ChatGPT, Google, or Perplexity?** The evidence is mixed and leans skeptical as of 2026. Google's John Mueller and Gary Illyes have both stated no AI system currently uses it for retrieval, and a controlled Ahrefs study from May 2026 found adding schema markup moved AI citations by a statistically insignificant amount, with a measurable decline in Google AI Overviews specifically. Chrome's Lighthouse tool does audit for the file under an "agentic browsing" category, treating it as baseline infrastructure hygiene rather than a proven citation lever. **What's the difference between llms.txt and a JSON Resume?** llms.txt is a single markdown file meant for AI tools reading your entire site's identity and content map at once. JSON Resume (resume.json) is a structured data schema specifically for work history, education, and skills, meant to be rendered into a webpage, PDF, or theme by any compatible tool. They solve different problems and can both exist on the same profile. **Do I need a vCard (.vcf) file on my developer bio?** If you ever exchange contact information in person, at a meetup, a conference, or a job fair, yes. A QR code encoding a vCard lets anyone's phone save your contact details natively in about four seconds, with zero typos and no app required. It's the oldest, most universally-supported format on this list. **Does structured data (schema.org) actually help you get cited by AI?** The most rigorous available evidence, a controlled May 2026 Ahrefs study, found no statistically significant lift in AI citations from adding schema markup, and a small measurable decline specifically in Google AI Overviews. A separate correlational finding shows AI-cited pages carry schema markup about three times more often than uncited pages, but the researchers attribute that to cited sites generally being larger and more established, not the markup causing the citation. **What is an h-card and do I need one?** An h-card is a microformats2 standard, stable since 2010, for marking up your existing HTML with plain classes so IndieWeb tools, feed readers, and webmention senders can read your identity directly from the page. It's a niche, non-AI use case with no new file required, worth adding only if you're plugged into the IndieWeb or Fediverse ecosystem specifically. **What is WebMCP and how is it different from llms.txt?** WebMCP, announced by Google and Microsoft at Google I/O 2026, is a browser-level standard that lets a site expose structured, callable actions to an AI agent through a `navigator.modelContext` API, rather than a static file the agent has to parse. llms.txt is passive, a document an agent reads. WebMCP is active, a set of actions an agent can invoke directly. It's the likely next step beyond static machine-readable files. **How do I check if my developer profile is machine-readable?** Run the 12-point checklist in this guide against your own profile: verify Person schema in your page source, confirm your OG image renders correctly, check that your resume PDF passes a 30-second copy-paste test, and confirm you have a vCard and an llms.txt file at minimum. Most developers pass zero to two of the twelve checks on a first pass. ## The Machine-Readable Developer Profile: The Bottom Line Machine-readability for a developer profile isn't one file. It's six formats, four of them decades-old and proven, one of them contested even by the search company most invested in AI, and one of them, WebMCP, barely out of preview. The honest 2026 read: cover the boring formats first. A single-column PDF that actually parses, a vCard behind a QR code, and Person schema in your page head will change real outcomes, interviews, contact exchanges, search visibility, more reliably than anything AI-specific on this list. Add llms.txt because it's free and increasingly treated as baseline hygiene, not because a specific citation count is coming. Your code already proves you can build. [Put it in every format a machine might need to read it, not just the one a human sees first — devbio.me](https://devbio.me){cta=signup}.