# personalsit.es: a directory of personal sites where every entry is one YAML file

> personalsit.es is a hand-curated directory of personal websites, built as a static site with Eleventy and published on Netlify. Contributing means adding a single YAML file, using tags from a fixed vocabulary, and waiting for a maintainer to approve the pull request, with screenshots handled as a separate manual request.

**xdesro/personalsit.es** — 📇 A little directory of people's personal sites

- Repository: https://github.com/xdesro/personalsit.es
- Website: https://personalsit.es
- Stars: 975 · Forks: 1,069
- Language: Nunjucks
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/xdesro-personalsit-es

## What the directory is, and who keeps it

personalsit.es is a little directory of people's personal sites. The stated purpose is that personal sites are rad, so the project was built so people can discover each other's sites, gain inspiration, and rally around the cause of the personal site.

It is a curated list rather than an index built by a crawler. Every entry is a file in a Git repository, and every entry passes through a human approval step. That design decision is what makes the directory worth reading and what makes it slow to grow.

The colophon records the history. The project was originally created by Andy Bell and is lately maintained by Henry Desroches and Declan Chidlow. The package manifest names Henry Desroches as the author and Andy Bell as a contributor, and the current homepage is personalsit.es.

The site itself is a static build. The primary language of the repository is Nunjucks, and the build runs on Eleventy, with a .eleventy.js configuration file, an .eleventyignore, _includes and _data directories for markup and site data, an index.md page, a filters directory, and a feeds directory. The package manifest declares the licence as MIT, although the repository's own licence field is left unclassified, so the file in the repository is the reference.

The audience is two-sided. Visitors get a curated list, and site owners get a way to be listed with a description, tags and a feed link.

## Adding a site means one YAML file with three required fields

The contribution flow is documented as a numbered sequence, and it is short because almost everything about the submission is in a single file.

You fork the repository, add a new .yaml file in the sites directory named after the domain, fill in the details, and open a pull request. One such file is sites/bell.bz.yaml, and the contents of that file follow a short structure: a title, a url, a list of tags, and a feed URL pointing at the site's RSS or Atom feed.

The rules for the fields are specific. The required fields are title, url and tags, while feed is optional and points to the site's RSS or Atom feed. Tags must come from the list in sites.schema.json.

That last constraint is the one that changes how you prepare a submission. Tags are not free text. A tag that is not in the schema file will not validate, so the first thing to do before writing the entry is to open sites.schema.json and pick from the vocabulary that is actually there.

After the pull request is opened, it has to be approved by an admin, and only then does the site appear on personalsit.es. The README points to a Bluesky profile for reaching out if you get stuck.

So the workflow is deliberately human in both directions. The maintainers review submissions, and contributors are expected to read the schema and match the documented fields.

## Validation and the tag vocabulary enforced by the schema

Two things in the repository enforce the rules above, and they are worth understanding because they explain why some pull requests fail.

The first is sites.schema.json, the JSON Schema that defines the allowed shape of a site entry and, according to the README, the list that tags must come from. The second is the validation script. The package manifest defines three scripts, and the relevant one is validate, which runs a Node script:

```json
"scripts": {
  "serve": "npx @11ty/eleventy --serve --quiet",
  "build": "npx @11ty/eleventy",
  "validate": "node validateSites.js"
}
```

The dependency list supports the same conclusion from the other direction. The project pulls in ajv and ajv-formats, which are JSON Schema validation libraries, alongside js-yaml for reading YAML files. So the schema is not documentation that a human reads and honours by eye. It is a schema that a validator enforces.

That means you can check your own entry before opening a pull request, and it is worth doing. The validate script exists for exactly that purpose, and it is the difference between a submission that merges cleanly and one that waits for a maintainer to point out a stray tag.

The build and serve scripts round out the picture: build runs the Eleventy build, and serve runs it in watch mode with quiet output for local preview. The other two scripts in the repository root, buildSites.js and validateSites.js, sit alongside those npm entry points and are the JavaScript half of the pipeline.

## Screenshots are a manual request, not part of the build

Screenshots are the part of the pipeline that is deliberately not automated, and the README is upfront about it.

Updating a site's screenshot is described as a fairly manual process, and the route to getting one is to open an issue with a request to update it, and the maintainers will sort it out. There is no instruction to run a script, and no pull request to make.

That is a real operational difference between this directory and one that regenerates thumbnails on every deploy. The thumbnails will go stale, and the only way to refresh one is to ask.

The repository does contain a screenshot-related script, screenshot-new-site.js, and the dependency list includes capture-website, which is a browser screenshot tool. There is also cloudinary as a dependency and an AWS SDK client for S3, which together suggest images are stored in object storage and delivered through an image service rather than committed alongside the site entries.

That is an inference from the dependency list rather than something the README states outright, and the distinction matters. The documented behaviour is the manual request. The tooling implies the capture can be done automatically for new entries, but a contributor should not expect the screenshot to update itself when their site redesigns.

## How the directory is published and where its data lives

The deployment target is Netlify. The repository contains a netlify.toml file and a netlify directory, which is the standard layout for a static site deployed with Netlify's build pipeline.

The content model is a set of YAML files in the sites directory, one per entry, and the rest of the repository is the machinery that turns them into pages. There is an index.md for the front page, a filters directory for output filters, an _includes directory for include files, and a _data directory for shared data. A with-feed.md file and a feeds directory handle the side of the directory that lists entries with RSS or Atom feeds.

The build tooling in the dependency list is worth reading as a whole. @11ty/eleventy is the static site generator, at version 3.1.6 or newer in the declared range, and @11ty/eleventy-plugin-rss adds feed generation. html-minifier-next is included for the production output, and filenamify-url converts a URL into a safe filename, which is how a domain becomes a slug for the entry file.

The result is a directory you can browse and, given the feed support, subscribe to. The engineering choice behind it is that every piece of content is a small file with a defined schema, which is what makes the validation step possible and what makes the whole directory reviewable in a pull request rather than through a moderation queue.

## Contributions policy, and what happens to machine written pull requests

One note in the contribution instructions stands out, and it is worth quoting rather than paraphrasing, because it changes who the project is for as a contributor.

The maintainer writes that they do not really fw LLMs, and that they close glaringly AI-generated pull requests, adding that there are no hard feelings and that it is just a repo about personal websites. The policy is stated as a note, not as a formal rule with a checklist, but the effect on automated contribution is clear.

For a directory like this one the reasoning is not hard to reconstruct. The value of the list is that a human looked at each entry and accepted it. Bulk submissions of machine-written descriptions would undercut the one property that makes the list worth reading, and they would be trivially detectable.

The contribution guidance itself is friendly. Got an idea for an enhancement? Create an issue, or open a pull request. The repository has a CODE_OF_CONDUCT.md file at the root, and issues and pull requests are both linked from the README.

The maintenance picture is that the repository is not archived, the last push was on 2026-10-17, and there are no GitHub releases, which is normal for a directory that is deployed continuously from the default branch rather than versioned as software.

## Conclusion

Adopt personalsit.es as a directory if you want a curated, human-reviewed index of personal sites with RSS feeds and tags you can filter on, and you are willing to run a local validation step before opening a pull request. Skip it if you need automatic submission, screenshots refreshed on every deploy, or a programmatic API, because approval is manual, screenshot updates are a separate request, and the content is YAML files in a Git repository. Before contributing, read sites.schema.json for the tag vocabulary and required fields, and run the validate script so the pull request passes on the first attempt.

## FAQ

### How do I add my personal site to personalsit.es?

Fork the repository, add a .yaml file in the sites directory named after the domain, for instance sites/bell.bz.yaml, fill in title, url and tags, and open a pull request. After an admin approves it, the site appears on personalsit.es.

### What tags can I use in my personalsit.es entry?

Tags must come from the list in sites.schema.json, which is a JSON Schema file in the repository root. Using a tag outside that vocabulary will fail validation, so read the schema before writing your entry.

### Is the feed field required when submitting a site to personalsit.es?

No. The required fields are title, url and tags, while feed is optional and points to the site's RSS or Atom feed. The feed listing is handled through a with-feed.md page and a feeds directory in the repository.

### How do I validate my entry before opening a pull request to personalsit.es?

The package manifest defines a validate script that runs node validateSites.js, using the ajv and ajv-formats JSON Schema libraries to check the YAML entries against sites.schema.json. Running it locally catches tag and field problems before a maintainer does.

### How are screenshots for personalsit.es updated?

The process is manual. You open an issue requesting an update to your screenshot and the maintainers handle it. There is a screenshot-new-site.js script and the capture-website dependency, but the documented route for an owner is to file an issue.

## Sources

- [Issues](https://github.com/xdesro/personalsit.es/issues)
- [Project website](https://personalsit.es)
- [README](https://github.com/xdesro/personalsit.es/blob/main/README.md)
- [xdesro/personalsit.es on GitHub](https://github.com/xdesro/personalsit.es)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/xdesro-personalsit-es