The 30-second answer: write the pitch you give in person, as text, with five to eight dated projects and a way to reach you
A portfolio llms.txt is your name as the H1, one sentence saying what you do, for whom, and where, a short paragraph on how to hire you and what you are taking on as of a stated date, and a list of selected work with one line per project: what, for whom, when, your role, result. Services, credentials, and contact follow as short sections. Older work goes under Optional. Nothing in the file should say something your pages do not.
Then fix the pages the same way, because the file is read by a minority of agents: put your name and role in the page title, write a text caption under every piece of work, date things, and keep the résumé facts in HTML as well as in the PDF.
What an assistant is actually asked about a person
The questions a potential client puts to an assistant about you are few and repetitive. Write the file to answer them in this order:
- Who is this and what do they do? Name, discipline, specialisation. “Brand designer for early-stage software companies” beats “multidisciplinary creative”.
- Have they done work like mine? Named projects with the industry, the deliverable, and the year. This is where the gallery fails: an assistant cannot see that the third thumbnail is a fintech rebrand.
- Can I hire them, and how? Whether you are taking work, in what form (project, retainer, hourly), from where, and the way to get in touch.
- Should I trust them? Years, named clients you may name, tools, a credential or two, and where else you exist: a GitHub profile, a talk, a published piece.
Everything else, your philosophy, your process diagram, the photo of your desk, is for the human who has already decided to look closer. It does not go in the file.
Why portfolio sites fail a plain fetch
The agents that read your site fetch the HTML as served and do not run a browser. The Googlebot comparison explains the difference. Portfolio templates are built on exactly the features that fetch badly:
| Pattern | What a fetch sees | Fix on the page |
|---|---|---|
| Hero image with your tagline in the image | An <img> with maybe an alt attribute | Put the tagline in an <h1> as text |
| Gallery of thumbnails, details on click | A list of image URLs, no project names | A text caption per item: client, deliverable, year |
| Work loaded by JavaScript from a CMS | An empty container | Server-render the list, or add a static work page |
| Résumé as PDF only | A link; the contents are often skipped | Repeat the key facts in HTML on the about page |
| Contact form with no address | A form the agent cannot submit | Add a mailto link or a public email as text |
| Page title is just your name | No discipline, no location | Title: Name, role, city |
The structure
The format is the standard one: an H1, a blockquote summary, free paragraphs, then H2 sections of links. The how-to guide covers the rules; what follows is how to fill them for a person rather than a product.
- H1: your name and role. “Mei Tanaka, brand and UI designer”. The name a client would search for, spelled the way you spell it elsewhere.
- Blockquote: one sentence. What you do, for whom, where you are based, and whether you work remotely. This is the sentence an assistant will quote verbatim, so make it the one you want quoted.
- A paragraph on hiring. As of a stated date: what you are taking on, in what form, typical project length, and how to reach you. Date it, because this is the line that goes stale.
- H2 Selected work. Five to eight links, each with one line: what, for whom, year, your role, result. Link to the case study page, not to an image.
- H2 Services, H2 About. Two or three links each. About covers years, tools, credentials, and the profiles that corroborate you.
- H2 Contact. One link to the contact page and the email as text.
- H2 Optional. Older work, talks, writing, a long CV. Readers may skip this section, which is the point; the Optional article explains the rule.
Keep the whole file to roughly forty lines. A reader with a budget of a few thousand tokens will take the H1, the blockquote, and the first section in full and skim the rest, so the order above is also the order of importance. If you find yourself writing a third paragraph of prose, it belongs on the about page; if the work list passes ten entries, the later ones belong under Optional. Shorter is not a stylistic preference here, it is what gets read.
A complete example
# Mei Tanaka, brand and UI designer > Independent brand and product designer for early-stage software > companies, based in Osaka and working remotely with teams in Japan, > Europe, and North America since 2017. As of October 2026 I am taking two projects per quarter, usually 4 to 8 weeks each: a brand identity, a marketing site, or a product UI pass. I do not do illustration or motion. Email hello@example.com or use the contact page below. ## Selected work - [Fieldnote rebrand (2026)](https://example.com/work/fieldnote): identity, website, and pitch deck for a Series A agtech company; sole designer. - [Lumen app UI (2025)](https://example.com/work/lumen): onboarding and dashboard redesign for a B2B analytics tool; activation rose from 31% to 44% in the quarter after launch. - [Kōen Coffee packaging (2025)](https://example.com/work/koen): packaging and label system for a roaster with 40 SKUs. - [Harbor docs site (2024)](https://example.com/work/harbor): design system and documentation site for an open-source project. - [Tessera brand (2023)](https://example.com/work/tessera): naming and identity for a fintech startup, with a developer-led team. ## Services - [Brand identity](https://example.com/services/brand): logo, type, colour, and a usage guide; 4 to 6 weeks. - [Marketing sites](https://example.com/services/sites): design and front-end build in Astro or Next.js. - [Product UI](https://example.com/services/ui): audits and redesigns of existing apps, working inside your design system. ## About - [About Mei](https://example.com/about): nine years in product design, previously at two Tokyo startups; Figma, Illustrator, and enough CSS to ship. - [GitHub](https://github.com/example): front-end for the sites above. - [Talks and writing](https://example.com/writing): conference talks and essays on design for developer tools. ## Contact - [Contact](https://example.com/contact): email hello@example.com; replies within two working days. ## Optional - [All work since 2017](https://example.com/work): the full archive, including student and agency projects. - [CV (PDF)](https://example.com/cv.pdf)
Two things to notice. Every line a client would quote carries a year, a role, or a number, and nothing in the file is a claim the linked page does not make. The activation figure is there because the case study states it; if the case study did not, the line would say what the deliverable was and stop.
The facts that go stale, and what is private
A product site worries about prices; a portfolio worries about availability, location, and rates. The rule is the same as in the pricing article: date any sentence that can change, keep it in one place, and update the file when the page changes. “As of October 2026” in front of the hiring paragraph lets a reader discount it in March; a bare “currently available” is wrong the week after you sign a retainer.
The file is public and cached by its readers. Put in it only what is already on a public page: no phone number unless it is on the site, no home address, no clients under NDA, no rates you would rather quote by email. A pseudonymous site stays pseudonymous in the file.
What the file will not do
It will not get you into search results. Google has said Search does not use llms.txt, and OpenAI’s crawler documentation does not mention it; the Google article has the statements. What it does serve is the agent a person points at your site, which for a freelancer is a common case: a client pastes your URL into an assistant and asks what you do and whether you fit. So do both:
- Page title with name, role, and city, on the home page and the about page.
- Text captions under every piece of work, with the client, the deliverable, and the year, in the HTML, not in the image.
- Person structured data on the about page with name, job title, and your other profiles, matching what the page says.
- The résumé facts in HTML, not only in the PDF.
Checking the result
Validate the file for format, then test it the way a client would: paste your URL into an assistant and ask it to describe you, what you have done, and how to hire you. If the answer matches the blockquote and the work list, the file is doing its job. If it quotes an old project or an outdated availability line, you have found the page that disagrees with the file.
Validate your llms.txt
Paste your URL. The validator fetches /llms.txt, checks the H1, summary, sections, and link format against the spec, and samples your links to confirm they resolve.
Validate →FAQ
Does a one-person site really need llms.txt?
Need is too strong; it is the cheapest fix for a specific problem. Portfolio sites are built to be looked at, and an assistant asked about you reads text. If your home page is a hero image, a gallery, and a contact button, a fetch returns almost nothing to quote. A twenty-line llms.txt is the plain-text version of your pitch, and it takes half an hour.
Will this get me into ChatGPT or Google results?
No. Google has said Search does not use llms.txt, and OpenAI's crawler documentation does not mention it. The file is read by coding agents, documentation tools, and assistants a person points at your URL, such as a client who pastes your site and asks what you do. For search visibility, the pages themselves carry the weight: your name in the title, text captions on the work, and dates.
What should I leave out?
Anything you would not put on a public about page: a phone number, a home address, client names under NDA, and rates you would rather quote. The file is as public as any other URL on your site and is cached by whatever reads it. Also leave out anything that changes weekly, such as availability, unless you date it and update it.
How many projects should I list?
Five to eight, one line each: what it was, for whom, when, your role, and one result if you have one. The reader has a budget of a few thousand tokens and will skim. Older or smaller work goes in the Optional section, which readers may skip, or stays on the work page itself.
Should I link to my PDF resume?
Link to it, but do not rely on it. Many fetchers read HTML and Markdown and ignore or truncate PDFs. Put the three facts a résumé exists for, years of experience, tools, and the kind of work you take, in the file as text, and keep the PDF as a download for humans.
Do I also need Person structured data?
It helps a different reader. Person schema on your about page gives search engines your name, job title, and profile links in a machine-readable form, and Google's rule is that it must match the visible text. It is not a substitute for llms.txt, and llms.txt is not a substitute for it. Both should agree with the page a human sees.
Next steps
- → How to write llms.txt by hand (the format rules this example follows)
- → llms.txt examples: 8 real files, annotated (what larger sites publish, for comparison)
- → 12 common llms.txt mistakes (and how to fix each)
- → All Learn articles