There's a moment in nearly every shōnen where the hero has to introduce themselves before the fight. Name, school, technique. That isn't politeness: it's the information from which the opponent — and the audience — decides whether you deserve attention.
Your portfolio plays that role. With one difference: in 2026, whoever discovers you is often not human.
A client searches for "Mobile Money developer Cameroon". They no longer scan ten results. They ask an assistant, which reads, summarises and recommends two or three names. If your site isn't readable by that machine, you don't exist in the answer.
The invisible portfolio
The typical developer portfolio is a client-rendered React app. Open the served HTML and you find this:
<div id="root"></div>
<script src="/assets/index-a1b2c3.js"></script>
That's it. Zero content. The text appears after the JavaScript runs.
Google does execute JavaScript, but with a limited rendering budget and a delay that can stretch to several days. Many other crawlers don't execute it at all. And above all: the bots behind answer engines — the ones feeding assistants — overwhelmingly favour served HTML.
The test takes one command:
curl -s https://your-site.com | grep -c "a word from your content"
If that prints 0, your content doesn't exist for a good share of your readers.
What I changed on this site
Server rendering, non-negotiable
This portfolio runs on TanStack Start with server-side rendering. The served HTML contains all the text: career history, case studies, articles. JavaScript adds interactivity; it does not create the content.
That isn't an aesthetic preference. It's the condition for being read at all.
Content in the repository rather than the database
Less obvious decision: the career timeline and case studies live in the repository, in TypeScript, rather than in a database.
The immediate reason was resilience — an outage emptied the site for nine days. But the SEO benefit is real: the content is present at build time, depends on no network call, and cannot disappear silently while a crawler is passing through.
The criterion I now apply: if content changes less often than you deploy, it belongs in the repository.
Structured data, to be understood and not merely read
HTML says what. Schema.org says what it is. This site declares:
Person— identity, skills, education, social linksProfessionalService— the practice, areas served, service catalogueItemList— projects and articles, with their orderFAQPage— the questions actually asked during pre-salesBreadcrumbList— the navigation hierarchy
FAQPage is the highest-return one. The questions clients ask me — how long a Mobile Money integration takes, taking over an existing project, working remotely — are exactly the questions people ask an assistant. Answering them in structured markup means handing the machine the answer in the format it expects.
llms.txt, the index for agents
This is the newest and least known part. The llms.txt convention proposes a file at the root, in markdown, introducing the site to language models: a short pitch, then annotated links.
The mistake would be to put four hard-coded links in it. Mine is generated from the real content: every project and every article appears with its description. And I added /llms-full.txt, which holds all the case studies in a single text file — for agents that prefer one source over a page-by-page crawl.
robots.txt explicitly allows answer-engine bots. Many sites block them out of defensive reflex. For a professional showcase that's backwards: being cited by an assistant is worth as much as a click.
What actually matters, and no technique replaces
Here's where I have to be honest, because none of the above is worth anything without it.
Before the rebuild, my site displayed project descriptions like:
"Development of responsive web and mobile interfaces with Next.js and React Native."
It's true. It's also interchangeable with ten thousand other profiles. No engine, no model, no human can derive from it a reason to pick me.
The entries now say:
"Mobile app for learning the highway code and a white-label multi-tenant back office for driving schools, built offline-first with Mobile Money payment."
Same length. Incomparable density. It contains a domain, a technical constraint, a distribution model, a payment method — that many handles for a real search.
Technical SEO amplifies content; it does not create it. A perfectly optimised site that says nothing specific stays invisible, just faster.
On length, since the question always comes up
"How many words to get indexed?" There's no official threshold. But there is an observable reality: a three-hundred-word article has no room to treat a subject, therefore nothing to quote, therefore no reason to be surfaced.
What works, from what I observe:
- One subject, treated fully. A text that completely answers one question beats a skim across five.
- Explicit structure. Headings that are questions or statements, not isolated keywords. Models extract by section.
- Verifiable specifics. Numbers, commands, real error messages, code excerpts. That's what separates a text of experience from a text of synthesis — and what gets quoted.
- Internal links. An article pointing to the project it discusses creates a mesh crawlers follow.
The current problem, for all of us
SEO is changing in nature. For twenty years the goal was the click. It's becoming the citation.
That shifts the cursor:
- Keywords matter less than the ability to answer a question.
- Rank position matters less than being the source that gets retained.
- Measured traffic falls while real influence rises — someone can recommend you to a client without you ever seeing a visit.
That last point is unsettling. Our measurement tools are designed for a world where attention converts into visits. A good share of the value becomes invisible in analytics.
My pragmatic answer: I no longer try to maximise traffic. I try to be the best available source on the few subjects I actually master — Mobile Money, offline-first, products for African markets. On those subjects, there is little serious content written by someone who has done the work.
It's a deliberate niche strategy. It only works if the content is true.
What I'd suggest you check tonight
curl -s your-site | grep "your content"→ if zero, start there.- Are your project descriptions interchangeable with anyone else's? Rewrite them with the domain, the constraint, the result.
- Does an
llms.txtexist? Thirty minutes of work. - Does your
robots.txtblock assistant bots without you having decided that? - Do you have
PersonandFAQPagemarkup?
In that order. The first point conditions all the others.
This site is described on its own project page, and you can read its llms.txt. If your site doesn't surface although your work deserves it, write to me.