Skip to main content
Every published site serves working SEO out of the box: metadata on every page, plus sitemap.xml, robots.txt and llms.txt on the site’s own domain. You tune it in two places in the console: each page’s SEO dialog on the Pages tab, and the project’s SEO tab for the site-wide files.

​
Two titles

A page has two titles, and they legitimately differ. The headline is what a visitor reads at the top of the page; you write it in the page’s content editor. The SEO title is what a browser tab, a search result and a social share show (<title>, og:title); you write it in the page’s SEO dialog, per language, up to 60 characters. The SEO description (up to 160 characters) is the snippet under it. An empty field is never blank: it inherits, live. An empty title falls back to the page’s own headline (or a document page’s first heading), then the home page’s SEO title, then your business name. An empty description falls back to the line under your headline, then the home page’s SEO description, then the agent’s display copy. The home page’s values are the site default the other pages inherit, and the dialog shows the value a visitor will actually get, with a badge saying where it comes from. SEO texts follow the same translation rules as the rest of your copy; see Languages.

​
The social image

Each page can carry its own social card image: a PNG, JPEG or WebP, 1200×630 px recommended, uploaded in the SEO dialog and shared across languages. Without one, the page inherits the home page’s image, then a card generated from your brand logo, then wondeya’s default.

​
The sitemap

Your site serves sitemap.xml automatically: every published page, every published language variant with hreflang alternates, and a modification date taken from the real publish date. In the project’s SEO tab you can:
  • Keep a page out. A published page is listed by default; untick it to leave a live page out of the sitemap. This is the lever with teeth.
  • Set a priority. Priority and change frequency are cosmetic hints that most search engines ignore, and the console says so. The change-frequency hint is available through the API and MCP.
  • Add extra URLs. Same-site paths your pages do not render, for example a /docs served by another tool.

​
robots.txt

Also served automatically and edited in plain language: three toggles decide whether search engines index the site, whether AI assistants may answer from it, and whether AI companies may train on it. All three are on by default, since a landing page’s whole job is to be found. You can add extra Disallow: paths, and an Advanced mode lets you replace the generated body with your own. Either way, the Sitemap: line always points at your canonical address: wondeya appends it and it is never editable.

​
llms.txt

wondeya generates an llms.txt for your site: an English markdown summary that AI agents read, built from your site’s real data and its published routes, served at <your-domain>/llms.txt. Publishing triggers the first generation, so the file appears shortly after your site goes live. The SEO tab previews it and offers Regenerate. Regeneration is fail-soft: if the file cannot be rebuilt, the previous one keeps serving. Paste your own ids for Microsoft Clarity, Google Tag Manager and the Meta Pixel; each is optional and independent, so GTM alone can act as the umbrella. An id is validated against its provider’s format and refused otherwise, and clearing a field removes that tracker. Once at least one id is set, your pages show a consent banner in your site’s own theme: no tracker loads until the visitor accepts, declining loads nothing, and the choice is remembered. With no tracker configured there is no banner.

​
From code

The same levers are scriptable. Over the API, PATCH /v1/pages/{pageId} takes seo and sitemap, and PATCH /v1/projects/{projectId} takes robots, analytics and sitemap. Over MCP, use update_page, update_project and regenerate_llms_txt; see the tool reference. The social image upload is console-only today.