How-to

SEO fields and metadata

Sonta gives every entry a URL-safe identifier, and everything else about SEO is fields you add yourself — a search title, a description, a social image — which your site reads and puts in the page's metadata. There is no hidden SEO feature: model the fields, and let the site use them.

Requirements: a role that can edit the collection's fields, and a site that reads this collection.

If a collection feeds public pages, each entry effectively becomes a page — and pages need titles, descriptions, and stable addresses. Sonta handles one part of this automatically and leaves the rest to you deliberately, because what belongs in a page's metadata is a content decision, not a system one.

What you get automatically

Every entry has a URL-safe identifier derived from its name when created. This is what a page's address is usually built from, and it is fixed once created — which is exactly what you want. An address that changes whenever someone edits a title is an address that breaks every link pointing at it and loses whatever search ranking it had earned.

Practical consequence: name entries thoughtfully at creation. Renaming the title later is fine; the address stays as first made, which keeps existing links working.

What you add yourself

Beyond the identifier, the metadata a page needs is fields you model on the collection like any other. Typically:

  • A search title — what appears as the headline in search results. Often a tighter, more descriptive version of the entry's own name.
  • A search description — the sentence or two under the title. This is the pitch to a searcher, not a summary of the record.
  • A social image — the picture shown when the page is shared. An asset like any other.

Your site reads these fields and puts them in the page's metadata. That is the whole mechanism — the fields are ordinary, the site does the rendering. Nothing is generated behind your back, which also means nothing appears unless you fill it in.

Why it works this way

It would be possible to auto-generate a description from an entry's content. It would also be worse: generated descriptions read like generated descriptions, and the record's internal wording is rarely what you would say to a stranger deciding whether to click. Keeping these as fields means the person who knows the product writes the pitch — and can see, edit, and improve it alongside everything else about that record.

Notes and limitations

  • The identifier is fixed at creation — renaming an entry does not change its address, by design.
  • SEO fields are ordinary fields — they exist because you added them, and are filled because someone filled them.
  • Your site decides how they are used — Sonta stores the values; rendering them into page metadata is the site's job.
  • Unpublished entries are not public — no metadata will help a page that is not visible; see how collections power a site.
  • Consider marking these fields searchable so you can filter for entries missing a description and fix them in a batch.

How a site reads your records is in using Sonta as your site's backend and how collections power a site. Adding the fields themselves is covered in add or change a field, and publishing them in publish your first catalog.

Frequently asked questions

If I rename an entry, does its web address change?
No — the identifier is fixed when the entry is created. That is deliberate: a stable address keeps existing links and search rankings intact.
Where are the SEO settings?
Add them as ordinary fields on the collection — a search title, a description, a social image — and have your site read them into the page metadata.
How do I find entries missing a description?
Mark the fields searchable, then build a view filtered to entries where the description is empty and work through them.