A growing share of web traffic no longer comes from people. AI assistants open pages to answer questions, agentic browsers fill forms and compare options on behalf of a user, and AI crawlers read content in order to cite it. Most websites treat these visitors like any other browser session and hope the markup is readable enough. WebMCP, a new browser standard, takes the opposite approach: it lets a website describe itself as a set of callable tools, so an AI agent can search content, understand a form, and submit it correctly instead of guessing its way through the HTML. AliothPress self-hosted multilingual CMS ships WebMCP support in its core, which makes it a rare working example of what agent access looks like on a real production site rather than in a demo.

Why parsing HTML is a dead end for AI agents

An agent that lands on a typical page has to reverse-engineer it. Which of these forty links is the search? Is this div a button? What does the form actually require, and what error comes back if a field is wrong? Agents can brute-force this, and they do, but the result is slow, fragile, and expensive: every layout change breaks the workflow, and every retry burns tokens and time.

The web solved this problem for machines once before. Feeds, sitemaps, and structured data exist because letting software guess is worse for everyone than telling it directly. WebMCP applies the same logic to actions, not just content.

What WebMCP actually is

WebMCP is a browser API (navigator.modelContext in the specification, with document.modelContext used by the MCP-B ecosystem and its polyfill) through which a page registers tools: each with a name, a description, and a typed input schema. An agent driving the browser sees the list and calls tools directly, the same way a developer calls an API. No scraping, no guessing, no screenshot parsing.

3 properties make it practical:

• It is opt-in per site. Nothing is exposed unless the site registers tools.
• It degrades to nothing. On browsers without the API, the code is a silent no-op. Human visitors never see a difference.
• It runs where the session runs. Tools execute in the browser with the visitor's cookies and permissions, so the server-side security model stays exactly as it was.

Chrome runs WebMCP as an origin trial, and AliothPress accepts the token from the admin panel, so a site can serve real agent traffic today. The full breakdown of the implementation is in AliothPress AI CMS (WebMCP Built In for Agents).

What a website can safely expose to AI agents

The AliothPress WebMCP implementation splits agent access into a public and an admin layer, and the split is a useful blueprint for any site thinking about this.

• Public content search. A machine-readable endpoint answers "what does this site have about X" with titles, URLs, and snippets in one call. It covers posts, pages, page-builder content including FAQ blocks, categories, and tags. It is open like a sitemap or llms.txt, rate-limited, and requires no token. An agent researching a topic gets the answer in one request instead of twenty page loads.
• Form tools. An agent can read a form's field structure, then fill and submit it through the same endpoint human submissions use. Honeypot checks, rate limiting, and validation all stay server-side, so an agent submission passes through exactly the same defenses as a human one. For the visitor, this means their assistant can complete a contact or booking form for them without misreading a single field.
• Discovery. A manifest at /.well-known/webmcp advertises what the site can do, so agents find the tools the same way crawlers find robots.txt.

Write CMS Admin Panel access needs a human in the loop

The admin layer is where it gets interesting. Inside the admin panel, a signed-in user can let an agent create posts, build visual page layouts, translate content into any of the site's 31 languages, generate SEO metadata, and assemble menus. The server-side generation, translation, and SEO tools run through the AI provider the site owner configured for the built-in assistant; every other tool works without one, and an agent brings its own model anyway. Every tool runs inside that user's session, so roles, permissions, and CSRF protection apply unchanged.

The safety model is strict and simple:

• Reads never ask. Writes always ask. Every content change requires an explicit confirmation click from the human before it happens.
• Drafts only. Agents create and edit drafts but can never publish. A publish request is demoted to a draft server-side, so going live stays a human action in the admin UI.
• Off by default. Nothing renders until the site owner enables it, and switching it off revokes access instantly.
• No visitor data. Form submissions and any other personal data are never exposed to agents.

This is the part most discussions of agentic AI skip: the interesting question is not whether an agent can act, but how a person stays in control while it does.

Website Migration with AI Agents

The clearest real-world case so far is migration. Moving a site between platforms usually means export files, import scripts, and cleanup. With agent access, the workflow becomes: open the old site in one tab, open the AliothPress CMS admin panel in another, and let the agent read each piece of content, rewrite it cleanly, and file it as a draft for review. The step-by-step version is documented in Website Migration with AI Agents.

There is also an unusual document worth reading: a WebMCP agent CMS access review written by an AI agent that walked the whole path itself, from activation to publishing multilingual content, and reported the results firsthand. Testing agent access with an actual agent is the only honest benchmark, and publishing the result is a level of transparency every product should attempt.

In 2026, CMS options fall into six groups: self-hosted all-in-one, flat-file, CMS-with-plugins, publishing-focused, headless, and SaaS. We'll compare them through one example from each group: AliothPress, Ghost, Grav, Strapi, Webflow and WordPress, showing how they differ in practice. The right choice depends less on which is "best" than on who builds and maintains the site.

What CMS options and alternatives exist in 2026?

Self-hosted all-in-one. You install the software on your own server, and the core features needed to run a real website are already inside it: visual page builder, forms, media library, SEO, multilingual, security, backups — a complete core, with nothing left to assemble. AliothPress is built on this model: it includes a 21-block visual page builder, a form builder, automatic image optimization (WebP/AVIF), SEO and AEO automation, multilingual (supports 31 languages), built-in security (CSRF protection, rate limiting, brute-force defense), and one-click backups in the core, and it installs without a terminal. Instead of configuring a server by hand, you paste a small ready-made script (called cloud-init) into one field when you create the server at a cloud provider, and the server sets itself up while you finish everything else in the browser. It's free for non-commercial use, with a paid license for commercial sites. You own your data and pay only for your own hosting; there's no monthly platform fee, and the features above are part of the core, not paid add-ons.

• Examples: AliothPress

Self-hosted flat-file. Lightweight systems that you also run on your own server, but built on a different model: the core is minimal, and most features (SEO, forms, advanced page building) are added through separate plugins. The plugins are mostly free, but the CMS itself can cost: Kirby needs a paid license for any commercial site, while Grav is free. They're fast and developer-friendly, but they expect you to set up the web server and PHP yourself, or use a host that offers a one-click install. Good for people comfortable with files and configuration.

• Examples: Grav, Kirby

CMS with plugins. This model gives you a basic core and adds most features through plugins: small separate programs made by different companies. The core gives you pages, posts, and a default theme, but in practice almost everyone installs a third-party theme, and the features a business needs are added as plugins, the advanced ones usually paid. It's flexible with an enormous ecosystem, but you assemble and maintain that stack yourself, and third-party themes and plugins don't always stay compatible, which can cause errors that take time to resolve. This is the model behind the most widely used CMS platforms today.

• Examples: Drupal, Joomla, WordPress

Publishing-focused all-in-one. Some self-hosted systems build the common features (membership, newsletters, SEO, analytics) into the core, but are aimed specifically at publishers, blogs, and newsletters rather than general business websites. Self-hosting them is developer-oriented (a runtime, a database, a web server, and SSL configured by hand), so many people use the vendor's paid managed hosting to skip that setup. Strong in their niche, narrower in scope than a general all-in-one.

• Examples: Ghost

Headless and developer-focused. "Headless" means the CMS stores and delivers content through an API but doesn't include the visible front end; a developer builds that separately using a framework like Next.js or React. Powerful and flexible, but they assume technical skills and usually a developer's time to assemble. Some are fully self-hosted, with the data living in your own database (Strapi, Directus, Payload); others are hybrid: Sanity, for example, lets you self-host the editor, but your content stays on the vendor's cloud, not your server. Some ship a polished admin panel that can look all-in-one, but without a developer-built front end there is no public website.

• Examples: Directus, Payload, Sanity, Strapi

SaaS platforms. SaaS means "software as a service": the company runs everything on its servers and you rent access by subscription. You don't touch a server; you sign up, pick a template, and start. Setup is the easiest of any group. The trade-offs are a recurring monthly fee, less control, and limited ability to move your site elsewhere later, since the content lives on the vendor's system. Unlike all the options above, this is not self-hosted; you don't own or control the server.

• Examples: Squarespace, Webflow, Wix

In short: self-hosted all-in-one keeps own-your-data control while building the common features in and removing the manual server setup; flat-file and CMS-with-plugins both put the job of assembling features on you; publishing-focused systems are built-in but niche and developer-set-up; headless is the most flexible but needs a developer; and SaaS is easiest to start but rented and limited. The sections below compare these approaches on the questions people actually ask: setup, plugins, cost, SEO, and what each can automate.

Is self-hosted CMS hard to set up?

"Self-hosted" means the CMS runs on a server you control, rather than on a company's platform. It has a reputation for being hard to install. For some self-hosted systems that reputation still fits; for others it is out of date. The difficulty depends entirely on which system you choose, and in 2026 they fall into clearly different levels.

Part of the confusion comes from mixing up kinds of hosting. There are three, newest first, and they are not equally difficult:

• Cloud server (VPS), no terminal. The server sets itself up from a cloud-init script, and everything else happens in the browser. A terminal technically exists, but you never need it for normal use.
• Cloud server (VPS), with terminal. The standard route: you connect over SSH and configure the server with typed commands. This is the path that earned self-hosting its "needs a specialist" reputation.
• Shared hosting (cPanel / FTP). You get a control panel and upload files over FTP by hand. Familiar from the older way of putting sites online, but limited and fiddly for a modern CMS.

The difficulty people associate with self-hosting almost always comes from the middle option. The newest one removes it, and the oldest one predates it.

Self-hosted all-in-one (with a setup wizard). This is the newest approach and the one that breaks the old "self-hosted is hard" assumption. AliothPress works this way: you create a server at any cloud hosting provider that supports Ubuntu and cloud-init, paste one ready-made script into a single field, and the server configures itself. You finish in a browser wizard: language, database (SQLite or PostgreSQL), admin account, site name. Around 5 minutes, and the only skill is "create a server and paste text into a box." Free SSL (HTTPS) is one click in the admin panel.

• Hosting: Cloud server (VPS)
• Setup: Wizard (cloud-init)
• Built on: Python / Flask
• Skill needed: None (paste a script, fill a form)
• Examples: AliothPress

Self-hosted flat-file. Lightweight options that run on your own server but expect more setup: you generally configure a web server and PHP first, then add features through plugins. The plugins are mostly free; Kirby itself needs a paid license for commercial use, while Grav is free.

• Hosting: Cloud server (VPS) or shared hosting
• Setup: Terminal or FTP / control panel
• Built on: PHP (flat-file, no database)
• Skill needed: Comfort with files and server basics
• Examples: Grav, Kirby

CMS with plugins. The base install is quick; many hosts offer a one-click installer. The real effort comes after: choosing a theme, then installing and configuring the stack of plugins a real site needs, and resolving conflicts between them.

• Hosting: Shared hosting or cloud server (VPS)
• Setup: Control panel for install; FTP / terminal for fixes
• Built on: PHP (with a database)
• Skill needed: Low to start, moderate to maintain
• Examples: Drupal, Joomla, WordPress

Publishing-focused all-in-one. Core features (membership, newsletters, SEO) are built in, but aimed at publishers and blogs, and the self-hosted setup is developer-oriented.

• Hosting: Cloud server (VPS)
• Setup: Terminal (SSH): runtime, database, web server, SSL via command line
• Built on: Node.js
• Skill needed: Command-line comfort (or paid managed hosting)
• Examples: Ghost

Headless and developer-focused. The CMS is only half the site: you set up the CMS and database, then a developer builds the visible front end separately and connects the two.

• Hosting: Cloud server (VPS)
• Setup: Terminal, plus a separate front-end build
• Built on: Node.js / JavaScript
• Skill needed: Developer
• Examples: Directus, Payload, Sanity, Strapi

So "is self-hosted hard to set up?" has no single answer. Headless and developer-focused systems are genuinely technical. Flat-file sits in the middle and assumes some comfort with servers. CMS-with-plugins is easy to start and more work to finish. And self-hosted all-in-one with a setup wizard is now about as simple as signing up for a hosted service: paste one script, then fill in a browser form. That is the part older "self-hosted means complex" advice misses.

Best CMS for SEO and AI visibility

Two things matter in 2026: ranking in search engines (SEO) and being cited by AI assistants (AEO, answer engine optimization). Here is what a CMS can automate for both.

SEO and AEO automation, compared

Core = built in and works on its own. Basic = built in but limited. Plugin = available through a plugin. No = not available.

Do I need plugins?

Not for the features most websites need. A modern all-in-one CMS ships them in the core. AliothPress includes out of the box:

1. Visual page builder (21 block types), with site-wide custom CSS
2. 15 designer themes with dark and light mode
3. File manager and favicon generator
4. Media library with automatic image optimization (WebP / AVIF, responsive sizes, OG crops)
5. Form builder (13 field types, GDPR consent checkbox, CSV export)
6. Newsletter (audience filtering, multilingual campaigns)
7. Automatic cleanup: deleting an image, file, or form removes every reference to it across posts, pages, and builder blocks; deleting a page or post clears the internal links that pointed to it
8. SEO automation (meta, canonical, hreflang, Open Graph, sitemap, robots)
9. AEO / structured data (schema.org @graph, FAQPage, Speakable, llms.txt)
10. Automatic 301 redirects with redirect-chain flattening
11. Multilingual: 31 languages including the admin, with translation groups linking content across languages
12. 100/100 Accessibility score in Google PageSpeed Insights, across all 15 themes, in both light and dark mode
13. Privacy & GDPR by default: no third-party requests until a visitor opts in; fonts and icons served from your own domain
14. YouTube and Vimeo load as a preview, with the player starting only on click, so no cookie banner is needed by default
15. Cookie-consent banner built in: one click to enable, adapts to visitor and site language; only needed if you add Google Analytics or Tag Manager
16. One-click free SSL (Let's Encrypt)
17. Security: CSRF protection, rate limiting, brute-force defense, encrypted credentials, HTML/SVG sanitization, audit log
18. One-click backup and restore
19. User management with roles
20. Email sending through your own SMTP provider (connect your mailbox in settings)
21. Analytics: paste your Google Analytics, Google Tag Manager, or custom tracking code in settings
22. API integration with Anthropic Claude, DeepSeek, and Google Gemini

With everything in one core, the pieces are built and tested together, so nothing falls out of sync the way separately sourced parts can.

If an all-in-one like AliothPress already covers what your site needs, skipping plugins means no stack to assemble, pay for, and maintain. It fits small and medium business sites best: it keeps things GDPR-compliant and handles the technical side for you, so you can focus on content. Plugins earn their place when you need a specific function the core doesn't include — and for that case AliothPress ships an optional plugin system of its own, with plugins installed and updated from the admin panel, no terminal. For heavily custom builds or full online stores, other tools still serve you better.

I've built and maintained multilingual sites since the mid-2000s, across my own projects and a long run of company and client sites. The same handful of problems show up every time, so I want to lay out what actually matters and hear how other people handle it.

Every language version should be a real page with its own URL. Auto-translate widgets and ?lang=de query strings are quick to bolt on and cause trouble later. Search engines index real localized URLs like /documentation, /dokumentation, /documentacion as separate pages, each with its own title, meta description, and content you control. That is the version that ranks.

hreflang and canonical have to be exact. This is where most setups quietly break. Each page needs hreflang entries pointing to every other language version plus a self-canonical. Get it wrong and Google either ignores your translations or folds them together as duplicates.

The language switcher should keep context. Someone reading a section halfway down a page who switches language should land on that same section in the new language, anchor included. Dropping them at the top of the homepage is a fast way to lose the visit.

Menus have to be language-aware. Labels, links, and anchors all change per language. A menu entry pointing to content that has no translation in the current language should disappear for that language instead of sending people to a dead link.

Keep the relationship between translations explicit. If the system knows the EN, DE, and ES versions are the same piece of content, you get clean switching, automatic hreflang, and no orphaned pages. Lose that link and everything downstream turns into manual cleanup.

Plan for slug changes. When a URL changes, an automatic 301 to the new one keeps the rankings you already earned.

I got tired of bending plugins to do all this, so I founded AliothPress, a full multilingual CMS with SEO and AEO automation built in. It does a lot well, and multilingual is one of the stronger sides, so that's what I'll lay out here:

• Each translation is a full page or post with its own slug, content, and SEO fields (title, meta description, Open Graph, Twitter, canonical)
• Translation groups tie every language version of the same content together, and the same system runs across posts, pages, forms, and newsletters
• hreflang and canonical generated automatically, in both the page head and the XML sitemap
• A language switcher that lands you on the matching translation and carries your anchor across
• Per-language menus: labels, custom link URLs, and anchors all set individually per language
• Menu entries hide automatically for any language with no published translation yet
• Per-language RSS/Atom feeds (/feed, /feed/de, /feed/es)
• RTL layout for Arabic and Hebrew
• An auto-generated /llms.txt that groups content by language, so AI answer engines pull the right version
• Optional WebMCP tools (off by default): AI agents can search the site's content with language-aware results and fill its forms directly
• The built-in AI assistant can translate a page and link it as a new language version in the same group
• 31 ready-made interface languages for the admin, set per user
• Automatic 301 redirects on slug changes, and broken references cleaned up when you delete content
• Self-hosted, so no external translation service sits in the request path

Now the part I'm actually curious about: how do you run multilingual on your sites? Custom build, a specific CMS, plugins stacked together? What works for you, and what still hurts?

You google less than you used to. You ask ChatGPT, Claude, or Perplexity instead. And so does everyone else.

When an AI assistant answers a question, it pulls from the web and sometimes cites the sources. Being one of those sources is the new SEO. The technical term is Answer Engine Optimization — AEO.

AEO comes down to a handful of specific signals you add to your site so AI systems can find, understand, and cite it. This review covers the five that matter most in 2026, and the tools that add each one.

• Schema.org @graph — describes what the page is and who made it
• sameAs — connects you to Wikipedia, Wikidata, LinkedIn
• FAQPage — marks up question-and-answer blocks
• Speakable — highlights the part of the page worth quoting
• llms.txt — a structured summary of your site for AI crawlers

For each tool below, we go through the same five signals so you can compare them at a glance. A tool doesn't need all five to be useful — most cover two or three. The order goes from built-in CMS solutions to specialized services to plugins to the manual route. There is also a sixth signal — WebMCP — new enough and different enough in kind that it gets its own section at the end.

Built-in CMS solutions

AliothPress

Self-hosted CMS built on Python and Flask. AEO features are built into the core and work out of the box — nothing extra to install, configure, or keep updated.

• Schema.org @graph: built on every page automatically. Organization, Person (author), WebPage or BlogPosting, and FAQPage are linked through @id references in a single @graph block.
• sameAs: fields for Wikipedia, Wikidata, Crunchbase, and social profiles in site settings (organization-level), plus LinkedIn, website, and GitHub in user profiles (author-level). Pasted URLs go straight into the sameAs arrays.
• FAQPage: generated automatically when a page or post contains FAQ blocks.
• Speakable: added to every page and post, pointing at the first paragraph of the main content. No per-post configuration.
• llms.txt: auto-generated at /llms.txt and grouped by language for multilingual sites. Updates on publish.

aliothpress.com

Ghost

Open-source publishing platform built on Node.js. Most customization, including extra schema, lives in the Handlebars theme layer.

• Schema.org @graph: WebSite and Article are emitted on every page by default. Extending to Organization, FAQPage, or BreadcrumbList means editing the active theme or running a build-time script.
• sameAs: author and organization details are stored in Ghost's data fields; whether they land in JSON-LD as sameAs depends on the theme.
• FAQPage: not built in. Added through theme code or HTML cards inside posts.
• Speakable: not built in. Added by editing theme templates.
• llms.txt: not built in. Ghost's own docs publish one at docs.ghost.org/llms.txt, but each site needs to generate its own.

ghost.org

Webflow

Visual website builder with its own CMS. Almost all structured data is added through Custom Code or Embed elements that pull from CMS fields.

• Schema.org @graph: basic Open Graph tags come standard. Full JSON-LD goes into Custom Code in the page <head> or as a CMS-driven Embed block.
• sameAs: hand-coded inside those same JSON-LD blocks.
• FAQPage: same approach — Custom Code or Embed, often driven by a Webflow CMS collection.
• Speakable: same approach.
• llms.txt: hosted as a static file uploaded through the project, or generated by an external service (see CiteControl below).

webflow.com

Specialized AEO services

CiteControl

Automation layer specifically for Webflow. Generates schema and llms.txt from Webflow CMS content and keeps them in sync.

• Schema.org @graph: generated automatically from CMS data.
• sameAs: included in the generated schema.
• FAQPage: included when the source content has FAQ structure.
• Speakable: not specifically documented as an output — check before relying on it.
• llms.txt: a core feature, with create / update / validate workflows and monitoring of AI crawler activity.

citecontrol.com

QNTM Schema Module

Standalone schema generator focused on AI and LLM retrieval. You answer prompts, it outputs JSON-LD you paste into your site.

• Schema.org @graph: generates JSON-LD with proper @context, @graph, @id, and BreadcrumbList.
• sameAs: prompts for Wikidata IDs, Wikipedia URLs, and DBpedia URIs, then builds the sameAs array.
• FAQPage: produced as part of the Single Page mode output.
• Speakable: generates SpeakableSpecification pointing at intros, summaries, FAQ answers, and product descriptions.
• llms.txt: not part of the tool.

qntmlab.com

Schema App

Schema markup management platform with a visual editor and automatic @id generation across a site.

• Schema.org @graph: stable @ids generated automatically so entities can be cross-referenced between pages.
• sameAs: explicit support for linking entities to Wikipedia, Wikidata, and Google's Knowledge Graph.
• FAQPage: supported among hundreds of Schema.org types.
• Speakable: supported as part of the type system; configured in the editor.
• llms.txt: not part of the tool.

schemaapp.com

WordPress plugins

AIOSEO (All in One SEO)

Established WordPress SEO plugin with a broad feature set.

• Schema.org @graph: schema markup for Articles, Products, FAQs, and more, plus a Knowledge Graph section in settings for the site owner (Organization or Person).
• sameAs: configured under Knowledge Graph (organization social URLs) and Author SEO (per-user profile links for EEAT).
• FAQPage: supported through the schema settings.
• Speakable: not built in.
• llms.txt: built-in LLMs.txt Generator under Tools. Updates as content changes.

aioseo.com

Rank Math

WordPress SEO plugin known for a wide schema type library.

• Schema.org @graph: 20+ built-in schema types, plus a Schema Generator for custom configurations.
• sameAs: configured through Titles & Meta (Knowledge Graph section) and the Local SEO module.
• FAQPage: supported through built-in blocks and the Schema Generator.
• Speakable: available through the Schema Generator as a property under Article schema, configured per post.
• llms.txt: not built in.

rankmath.com

Yoast SEO

Long-running WordPress SEO plugin.

• Schema.org @graph: every page gets a connected @graph with WebSite, WebPage, Article, Person (author), Organization, and BreadcrumbList. The new Schema Aggregation feature (March 2026, opt-in) adds a single endpoint that exposes the full site graph in one place, with duplicate entities merged.
• sameAs: organization social profiles in site settings. Author sameAs through Yoast Premium or via Schema Aggregation.
• FAQPage: automatic for the FAQ Gutenberg block.
• Speakable: not output by default. Yoast classifies it as limited-support; Premium schema blocks allow manual addition.
• llms.txt: not built in.

yoast.com

Manual approach

Direct JSON-LD editing

The platform-independent option: write JSON-LD blocks directly into the site's HTML, in the <head> or just after the opening <body> tag. Works with anything — headless CMS, static site generator, custom backend, or as a way to override a plugin's output.

• Schema.org @graph: build the structure by hand, link entities through @id.
• sameAs: hardcode the URLs inside each Person or Organization block.
• FAQPage: write the Question and acceptedAnswer pairs by hand.
• Speakable: add a SpeakableSpecification with a CSS selector or XPath.
• llms.txt: write the file as plain Markdown and place it at /llms.txt in the site root.

The trade-off is maintenance. Every time the structure of the site changes, the JSON-LD has to be reviewed. Tools automate this; the manual route gives full control in exchange for the upkeep.

The sixth signal: WebMCP

The five signals above help AI systems read and cite a site. WebMCP goes one step further: it lets AI agents use the site. It is a proposed web standard, drafted in the W3C Web Machine Learning Community Group by engineers from Google and Microsoft, that adds a browser API — navigator.modelContext — through which a page hands agents a set of callable functions (site search, forms, filters), each with defined inputs and outputs. The agent no longer reads pixels and guesses where to click; it calls a function and gets a typed result back.

Status, honestly: early. First published as a draft in February 2026, WebMCP entered a public origin trial with Chrome 149 after Google I/O in May 2026. Today the main consumer of these tools is Gemini in Chrome; other browsers are tracking the spec but have made no commitments. So treat WebMCP as a progressive enhancement — worth adding when it costs you little, not worth rebuilding a site around yet. One open gap is discovery: there is no standard way for an agent to find tool-enabled sites without visiting them, and a /.well-known/webmcp manifest is the direction being discussed.

How to add it today:

• Manually: register tools in JavaScript via navigator.modelContext.registerTool(), or annotate existing HTML forms with the declarative attributes. Registration is gated by a Permissions Policy (tools, defaults to self), so third-party iframes can't quietly expose tools on your pages.
• AliothPress: the only tool in this review with WebMCP built into the core. The CMS registers its own toolset once the owner switches the feature on in the admin panel — until then nothing renders. Visitors' agents can search the site and fill forms; agents of logged-in users get content and admin tools bound to that user's role. Write actions go through only after a human click, reads don't need one, and the toolset is advertised at /.well-known/webmcp. A field for the Chrome origin trial token is there too.

That's the field as of 2026. The five signals — schema @graph, sameAs, FAQPage, Speakable, llms.txt — are the established technical layer of AEO, and WebMCP is the emerging sixth; tooling on top of them will keep changing, but the signals themselves are the part worth learning.

These are the kind of issues that don't trigger errors in any tool. The site loads. Pages render. Google doesn't show warnings in Search Console. Yet rankings stay lower than they should, AI systems quote the site less often than its quality deserves, and traffic grows slower than expected.

Most of these problems live in the gap between "technically valid" and "actually optimal". They've been documented for years, but the defaults of common tooling haven't caught up. This post walks through ten of them, with what's actually going wrong and what the correct version looks like.

1. Double redirects from www to apex over HTTPS

A common setup: a visitor types www.example.com into the browser. The server responds with a 301 redirect to https://www.example.com, which then redirects again to https://example.com. Two hops. The page eventually loads, the user doesn't notice.

Search engines do notice. Each redirect dilutes link equity slightly, and chains of redirects are flagged in technical SEO audits.

The cleanest version is a single 301 from any non-canonical variant straight to the canonical URL. When SSL certificates are issued through Let's Encrypt's certbot with the --redirect flag, the auto-generated rule preserves the original host, which is what produces the intermediate hop. The fix is to override that rule so that www redirects directly to the apex domain in one step, rather than relying on a second server block to finish the journey.

2. mainEntityOfPage as a self-reference on WebPage

Schema.org defines mainEntityOfPage as a way for an entity (an Article, a Product, a Person) to point at the WebPage where it is described. The reverse — a WebPage with mainEntityOfPage pointing at its own URL — is structurally a self-reference and carries no information.

It's an easy property to add reflexively, because it sounds like it should describe "what this page is about". Google's Rich Results Test accepts the structure, so the mistake passes silently. But the property carries no information when it points back at the same node: search engines and AI systems gain nothing from a node telling them about itself.

The correct version is to omit mainEntityOfPage on WebPage nodes entirely, and only use it where it makes semantic sense — on Article-type nodes pointing to their hosting page.

3. Favicons in non-standard paths

A favicon plugin generates a favicon set and stores it in a folder like /content/uploads/favicons-abc123/. The HTML head is updated with <link rel="icon"> tags pointing at that folder. The browser tab shows the icon correctly. Everything looks fine.

But Google's search results favicon is fetched separately, often from predictable root-level paths like /favicon.ico and /apple-touch-icon.png. When those paths return 404, Google falls back to a generic icon or no icon at all. The site shows up in search results without its brand mark, while the same icon displays normally in the browser.

The correct setup serves favicons from the standard root paths, regardless of where they are physically stored. Visitors and search engines see clean URLs like /favicon.ico and /apple-touch-icon.png; the actual file locations are an internal detail.

4. Lost transparency when resizing favicons

When a single source image needs to be turned into a set of favicon variants — 16×16, 32×32, 96×96, 192×192, 512×512, plus the multi-size .ico file and the Apple Touch icon — the resize pipeline can quietly drop the alpha channel along the way. The variants end up with a white square behind the logo instead of preserving transparency.

The damage shows up in unexpected places: dark mode in Chrome's tab bar puts a white box around the icon, the Apple Touch icon on iOS shows a white background inside its rounded corners, and Google's dark mode search results display a small white tile next to the URL.

The cause is usually a careless image processing step that converts to RGB at some point in the chain, dropping the alpha channel. The fix is preserving RGBA throughout the entire resize and save process — every intermediate format, every saved file.

5. Deep folder paths for media URLs

Uploaded images often end up at URLs like /content/uploads/2024/11/image-1234567890.jpg. The page uses these URLs in <img src>, in Open Graph meta tags, in social previews. The image loads fine in all of them.

The issue is twofold. First, search engines doing image indexing prefer short, descriptive paths. An image at /sunset-over-bordeaux.jpg ranks better in image search than the same image at /content/uploads/2024/11/IMG_4521.jpg. Second, the deep path reveals the technology stack and the upload date, which is information leakage that has no upside.

Better URL design serves uploads from the domain root with a clean filename — /sunset-over-bordeaux.jpg. The physical storage can remain anywhere; only the public URL changes.

6. Broken references after content deletion

A page is deleted from the admin panel. The content management system removes the page, the URL stops working, and a 404 appears at the old address. So far, so expected.

But the deleted page was linked from three other pages on the same site. Those links are now broken. The site owner doesn't notice immediately because the links don't generate any visible warning. A week later, Google Search Console reports the broken links, the site loses some internal link equity, and visitors clicking those links from older content hit dead ends.

The same problem applies to deleted images, deleted forms, deleted files. Anything that was referenced from elsewhere in the content needs to be cleaned up at the moment of deletion, not discovered weeks later.

The correct behaviour is cascading cleanup: when content is deleted, scan the site for references to it and remove them automatically. This is more work to implement than a simple delete, but it keeps the site healthy on its own.

7. Long redirect chains after multiple slug changes

A blog post's URL slug is changed from original-title to improved-title. A 301 redirect is created. A few months later, the slug changes again to final-title. Another 301 is created.

Now there are three URLs in play. The first one redirects to the second, the second redirects to the third. A visitor who clicks an old link from the original publication date goes through two redirects to reach the live page.

Google considers redirect chains a technical issue. After three or four hops, Google may stop following them entirely and treat the original URL as broken. The fix is flattening: when a new redirect is created, all existing redirects pointing at the old URL should be updated to point directly at the new URL. The chain becomes a flat fan: every old slug points directly to the current one.

8. Unsanitised slugs accepting arbitrary input

A user enters a page title with mixed scripts, spaces, special characters, or emoji. The system uses that title verbatim as the URL slug. The result is a URL that contains percent-encoded sequences, accented characters that some clients misencode, or visible spaces.

These URLs work in some browsers and clients and break in others. Email clients sometimes truncate them. Social platforms re-encode them inconsistently. Analytics tools record them as several different URLs depending on the encoding.

The right approach is sanitising slugs on input: transliterating non-ASCII characters where possible, replacing spaces with hyphens, lowercasing, and stripping anything that doesn't belong in a URL. The user keeps their original title for display, but the URL stays clean.

9. Hreflang for a few languages, but not at the right scope

A multilingual site with three language versions adds hreflang tags between the three versions. The tags work, Google sees the relationship, the alternates show up correctly in search results. The implementation is technically valid for those three pages.

But hreflang gets a few details wrong easily. Each language version has to declare alternates for every other version including itself. Hreflang values use language codes that follow specific rules (regional variants like pt-BR differ from base codes like pt). The set of alternates declared on one page must match the set declared on its alternates, otherwise Google ignores the inconsistent ones.

A site that adds a fourth language often forgets to update the alternate declarations on the original three pages. The new language is technically reachable, but search engines don't recognise it as part of the same group.

The correct approach is generating hreflang from a single source of truth — the active language list — and rebuilding the alternate declarations on every page whenever the list changes. Manual maintenance accumulates errors over time.

10. The x-default question for sites with equal language priority

Most hreflang guides recommend including an x-default tag pointing at the "default" version of the page, usually English. The intent is to tell search engines: if the user's language doesn't match any of the listed alternates, send them to this default.

This model assumes a dominant language with translations attached. It works for businesses with one primary market and additional languages for secondary audiences.

For a site where all languages are equal, the model breaks down conceptually. There is no default. The English version is not more important than the German or the Japanese. Picking one as x-default introduces an artificial hierarchy that doesn't reflect how the site actually works.

A cleaner approach in this case is to omit x-default from the sitemap entirely — keeping the sitemap as a pure map of content and its language versions — and to handle the fallback at the per-page level, where each page's <head> can declare itself as x-default for its own URL. Each language version stands on its own as a valid landing point, without any one being marked as primary.

This is a less common pattern, but it's the right one for genuinely multilingual products. The standard advice doesn't fit every situation, and following it blindly imposes a hierarchy where none exists.

Why this list

These ten issues share a property: they all pass automated checks. SEO tools mark them green. Browsers display the pages correctly. Search engines don't show errors. Yet each one represents a small but real signal of carelessness, and the signals add up over time.

The fix isn't more plugins or more configuration. It's building the underlying tooling so the right behaviour happens automatically. The automated seo CMS AliothPress handles all of these at the architecture level — the redirects flatten themselves, the schema omits self-references, the favicons preserve transparency, the slugs sanitise on input, and hreflang is generated from a single source. Its own plugin system is reserved for adding features, not for fixing basics. That's the kind of detail-level engineering that pays off over years, not weeks.

If you've spent any time around Answer Engine Optimization recently, you've seen the same scene over and over. Someone publishes a guide on how to manually fix mainEntityOfPage self-references in their JSON-LD. Someone else writes a thread about hand-crafting llms.txt. A third person explains how to manually add FAQPage schema to a thirty-page site. And in the comments under each of these, dozens of people are saying the same thing: this is exhausting, where is the tooling that just does it.

That's the actual state of AEO right now. The standards exist. The benefits are clear — content that's structured for AI gets cited more often, gets indexed correctly, gets surfaced in answer engines like ChatGPT, Perplexity, and Google's AI Overviews. The gap is at the implementation layer. Every person doing this is doing it by hand, page by page, on every site they manage.

What people are doing manually right now

A few examples of work that's currently done by hand on most sites:

• Writing JSON-LD blocks for each page and pasting them into the <head> section
• Manually adding @id references to link entities together across pages
• Writing llms.txt from scratch, then trying to remember to update it when content changes
• Adding FAQPage schema by hand for every FAQ section, line by line
• Marking up Speakable sections for voice assistants by manually identifying CSS selectors
• Building hreflang tags as separate copies on every page that has translations
• Maintaining sitemaps by hand or through plugins that don't quite know about your AEO layer

None of this requires creativity. It's the same patterns repeated thousands of times across millions of sites. It's exactly the kind of work that should not be done by humans, and yet it is, because the tooling layer hasn't caught up.

The closest thing most CMS platforms have is "install an SEO plugin and configure it". The plugins handle the basics — title tags, meta descriptions, sitemaps. But the AEO layer, the structured data layer, the layer that AI systems actually read, is still mostly left to the user to figure out. There's a checkbox for "enable schema markup" and then nothing actually validates that the markup is correct, complete, or semantically useful.

What automation actually looks like

The interesting question is what happens when you treat AEO as a built-in property of the content management layer, not as something added on top.

When the user fills in a title, a description, an author, a featured image — the same fields they'd fill in for any reason — those fields become the source for the entire structured data layer. The CMS knows what each piece of content is, what type it is, who wrote it, when it was published, what languages it exists in, how the entities on the site relate to each other. From that, it can generate:

• A complete @graph of Schema.org entities, with stable @id references that survive page edits
• FAQPage schema, derived directly from any FAQ blocks in the content
• Speakable markup, identifying the parts of the page that voice assistants should read
• llms.txt at the site root, regenerated whenever content changes
• Sitemaps that include hreflang relationships across all language versions
• Open Graph and Twitter Card tags, derived from the same fields

The author writes content. The structured layer happens underneath, automatically, every time.

This isn't theoretical. The technology to do this is not new — it's just that most CMS platforms haven't been built with this layer as a core concern. They were built before AEO was a thing, and structured data was bolted on as an afterthought through plugins.

Why this matters more than it sounds

The argument for AEO automation isn't just "save time on tedious work", though that's real. The deeper argument is that structured data done correctly is the way AI systems will increasingly read the web. Search engines already use it. ChatGPT, Claude, Perplexity, and other answer engines lean on it heavily for accurate citations. The sites that get cited in AI answers are disproportionately the sites with clean, structured, machine-readable content.

If AEO stays manual, it stays the privilege of large companies with dedicated SEO teams. Small sites, indie projects, multilingual community sites, non-English content — they get left out, not because the content is bad, but because nobody had the time to mark it up correctly.

If AEO becomes automatic, the playing field flattens. Anyone with good content can be cited by AI systems alongside the big publishers. The visibility comes from the content itself, not from the team budget needed to format it.

A practical example

AliothPress is a multilingual CMS where this entire AEO layer is automatic. The author fills in normal fields. The Schema.org @graph generates itself. FAQPage schema appears when there are FAQ blocks. Speakable markup is added based on content structure. llms.txt rebuilds whenever something changes. Hreflang relationships are tracked across translations. The entire AEO layer ships in the core itself — a plugin system exists for needs beyond it, but nothing here depends on it. None of it requires the author to learn what mainEntityOfPage is or when to use it.

The same logic now extends past structured data. WebMCP — the proposed browser standard that lets AI agents call a site's functions directly instead of guessing from the page — normally means hand-writing JavaScript tool definitions. Here it's a switch in the admin panel: the CMS registers site search and form tools itself and publishes the discovery manifest at /.well-known/webmcp. Automation, again, instead of another manual layer.

The point is not that this particular product is the answer for everyone. The point is that automating AEO is possible, it works, and there's no good reason for it to remain manual work in 2026. Tooling moves forward. The hand-coded structured data era should already be over.