Back to Hub

SEO Checklist: Sitemap, Schema, and llms.txt | NitroIDE

Most indie SEO advice is a list of things to write: more posts, better titles, target this keyword. That advice is not wrong, exactly. It is just the second half of the job, and it assumes the first half already happened — that search engines and AI assistants can actually find, understand, and trust your pages.

I run NitroIDE, a browser IDE on a static host with no server, no build step, and no plugin system. There is no SEO plugin to install. Everything machine-readable on the site is a file I wrote by hand or a script I maintain. That constraint turned out to be useful: it forced me to learn which three files actually matter, what each one is for, and how each one silently breaks.

Here is the checklist, in the order I would do it again.

1. The sitemap: prove every page exists

A sitemap is a list of your URLs, with a last-modified date for each, handed to search engines in a format they can crawl without guessing. It does not make a bad page rank. It makes a good page findable — especially on a site where new pages arrive one at a time and internal linking is thin.

The checklist for a sitemap:

• Every page goes in, no exceptions. This is a rule I set for myself after redirect stubs got left out once: if a page exists and you want it found, it is in the sitemap. A sitemap that quietly omits pages is worse than no sitemap, because you stop checking.
• Lastmod must be real. A lastmod date that never changes teaches crawlers to ignore your dates. Mine come from git history: the last commit that touched each page sets its lastmod. That is automated, so it cannot drift from reality the way a hand-edited date can.
• Submit it, then check the report. A sitemap sitting in your repo root that nobody submitted is a wish, not a signal. Submit it in Search Console and read the coverage report: pages discovered, pages indexed, and — the useful part — the pages excluded and why.
• Regenerate it when you publish. My publishing flow refreshes the sitemap with every new blog post. A sitemap that is stale on publish day is a sitemap that tells crawlers the new page does not exist yet.

The mistake that silently voids a sitemap is staleness, not syntax. Syntax errors show up loudly in the report. A sitemap that is valid but three months old just quietly stops describing your site.

2. Schema: tell machines what the page IS

If the sitemap says “these pages exist,” schema says “and here is what each one is.” JSON-LD is the format: a block of structured data in the page that names the thing — a software product, a blog post, a FAQ — in a vocabulary search engines already understand.

For an indie site, three types cover almost everything:

• SoftwareApplication for the product itself: name, description, operating system, offers (free, in my case), and version. This is the one that lets a search result describe your tool as a tool, not as a generic webpage.
• BlogPosting for articles: headline, author, date published, and date modified. The date-modified field matters more than people think — it is how a corrected, updated article signals that it is current rather than old.
• FAQPage for pages that genuinely answer questions: a list of question-and-answer pairs, each complete in itself. Only use it where the page actually contains those answers visibly. Schema that describes content the page does not show is the fastest way to lose trust in all your schema.

Three rules for schema that I wish someone had given me earlier:

• Validate before shipping, not after indexing. A structured-data testing tool will catch a missing comma or a wrong type in seconds. Waiting for Search Console to report it costs you a crawl cycle.
• Match the visible page. Every fact in the schema should be findable by a human reading the page. If the schema claims a price, a rating, or a feature the page never mentions, that is not optimization — it is a mismatch waiting to be flagged.
• Keep it boring. Schema is not the place for creativity. Use the standard types, the standard property names, and nothing clever. The whole point is that a machine on the other end already knows what these words mean.

The mistake that silently voids schema is the same as the sitemap's, in a different costume: schema that describes last month's page. When you change a price, a version, or a headline, the schema changes in the same commit, or it becomes a lie told in a format machines trust.

3. llms.txt: the file for readers that are not browsers

Sitemaps and schema are for search engines. llms.txt is for a newer reader: AI assistants that want to understand your site without crawling every page and reconstructing the picture from fragments. It is a short, plain-text file at your site root that says what the site is, what its important pages are, and where to find them.

I added one recently, and it taught me something the other two files did not: a summary file is a second source of truth. A reader on Peerlist put it better than I did — llms.txt is like a contract summary versus the document itself. Useful, but only while it matches the document. The moment the site changes and the summary does not, the summary is not just stale, it is actively misleading the exact readers you wrote it for.

So the checklist for llms.txt is short and strict:

• Keep it short. It is a map, not a mirror. Link to the real pages; do not paste their content in.
• Update it with the site. When a new section ships or an old page goes away, the file changes in the same round of work. Treat it like the sitemap: maintained by the publishing flow, not by memory.
• Say what the site is in one paragraph. The first lines are the whole pitch to a reader that will never see your homepage design. If those lines are vague, the rest of the file does not rescue them.

The mistake that silently voids llms.txt is neglect. Unlike a broken sitemap, which Search Console reports, a stale llms.txt produces no error. It just keeps answering questions about a site that no longer exists.

The whole checklist, on one screen

1. Sitemap: every page in, lastmod from a real source, submitted, refreshed on publish.
2. Schema: SoftwareApplication for the product, BlogPosting for articles, FAQPage only where the page really answers questions — validated, matching the visible page, using standard types.
3. llms.txt: short, linked (not pasted), updated with the site, with a one-paragraph description that actually says what the site is.
4. After shipping, verify all three: Search Console coverage for the sitemap, a structured-data test for the schema, and a plain read of llms.txt to check it still describes the site you have.

None of this replaces writing something worth finding. But it is the difference between a good page that search engines and AI assistants can describe accurately, and a good page they have to guess at. Indie hackers do not have a marketing team to do the guessing for them. These three files are the team.

Try it

I build NitroIDE — a browser-based IDE where your code never leaves your machine: nitroide.com

⭐ If you enjoyed this, star NitroIDE on GitHub: github.com/nitroideofficial/nitroide

Frequently asked questions

What three files does an indie site need for SEO?

A sitemap that proves every page exists, JSON-LD schema that says what each page is, and a short llms.txt that maps the site for AI readers. Together they cover findability, understanding, and trust.

How should sitemap lastmod dates be set?

From a real source, such as git history: the last commit that touched each page sets its lastmod. A hand-edited date that never changes teaches crawlers to ignore your dates.

When should FAQPage schema be used?

Only where the page genuinely answers questions visibly. Schema that describes content the page does not show is a mismatch waiting to be flagged.

Why does a stale llms.txt matter?

Unlike a broken sitemap, a stale llms.txt produces no error. It just keeps answering questions about a site that no longer exists, misleading exactly the readers it was written for.