SEO GEM · integration
One tag, four fields.
The script does the rest.
Nothing gets built. SEO GEM is an external service that loads inside the article editor and fills four fields. No server-side integration, no library of ours in your codebase, and nothing changes in the article text. Per the specification, that is one working day on the CMS side.
1
script tag on the editor page
4
fields on the article
1 day
of work on the CMS side
0
server-side changes
How it flows
From a click in the editor to the head of the public page.
The whole path runs from the journalist's browser. The platform only stores four fields and renders them on the public page — like any other field it already has.
01
Article editor
The script reads the headline, standfirst and body when the journalist clicks the button.
02
SEO GEM
Returns six headlines, then — after confirmation — the meta description, keywords and schema.
03
Four fields
The CMS stores them with the article and returns them to the frontend through its own API.
04
Public page
title, description, keywords and JSON-LD in the head of the article.
What it takes to start
Three things. Nothing more.
That is the whole list. If your CMS already has SEO fields, only the first and third remain.
01
A script tag in the editor
One line on the article create and edit page. Every specific of your CMS is an attribute on that tag — no custom code.
02
Four fields on the article
SEO title, meta description, keywords and one field for Schema.org. If they do not exist, they are added like any other field and exposed to the frontend.
03
Rendering in the head
The frontend prints those four fields in the head of the article. Three are plain meta tags; the fourth is a structured-data block.
What it looks like
All of the work sits on the editor page.
The script inserts one button and a panel above the SEO title field. It changes nothing else on the page and never blocks saving.
<!-- on the article create and edit page -->
<script src="https://…/cms-embed.js"
data-api-key="your portal key"
data-language="en"
data-editor-type="ckeditor"
data-field-title='[name="heading"]'
data-field-seo-title='[name="seo_title"]'
data-field-meta-desc='[name="meta_description"]'
data-field-keywords='[name="keywords"]'
data-field-schema='[name="schema_org"]'></script>Differences between CMS platforms are handled with attributes, not code: field selectors, editor type, language and the article URL. That is why the same script runs in two entirely different systems — one on CKEditor, one on TinyMCE. For a third editor we add an adapter and the tag stays the same.
Four fields
From the CMS into a head Google understands.
The tool returns shorter values than the field limits, so there is always headroom.
| Field in the CMS | Rendered on the article page | Tool returns · field accepts |
|---|---|---|
| SEO title | <title> | up to 75 · 80 chars |
| Meta description | <meta name="description"> | up to 160 · 180 chars |
| Keywords | <meta name="keywords"> | up to 300 · 300 chars |
| Schema.org | JSON-LD NewsArticle, replacing the generic block | a few KB · textarea |
The schema the tool writes carries the headline, description, language, section, publication and modification dates, author, publisher with logo, image, canonical URL, keywords, and the topics and entities drawn from the text itself. On every later save, the script refreshes the modification date and realigns headline, image and URL on its own — without a single call to the service.
Who does what
The split of work before the first article.
Your side
- A script tag on the article create and edit page
- Four SEO fields on the article, stored and available to the frontend
- Rendering of those four fields in the head of the public page
- A staging environment with a test account, for a joint check before go-live
Our side
- A key for your portal and the whitelist of allowed origins
- A language pack for your market, with output-language validation
- Publisher configuration — name, logo, domain — for the structured data
- A test page replicating your editor structure, before anyone touches your CMS
- A joint test on staging: the full loop from headline to public page, around half an hour
- Per-article and per-section performance reporting from Search Console and GA4
What the tool does not do
The boundaries are tighter than you expect.
It does not touch the article text
It reads the headline, standfirst and body; it writes only into the four SEO fields. The body and every other field stay untouched.
It does not block the newsroom
If the service does not respond, saving and publishing work normally. The fields stay as they were and the journalist gets a retry button.
It does not mix publishers
The key is issued per portal and determines whose data is whose. Your newsroom's headline history never influences suggestions for anyone else.
It does not collect reader data
The tool never sees your visitors. Article text is processed by external AI providers under business terms that exclude the use of content for model training.
Frequently asked
What the technical team asks.
How much work is it really?
Per the specification, one working day on the CMS side: the tag on two editor pages, four fields on the article and the rendering of those fields in the head. Then a half-hour joint test on staging. That is how it went in two different CMS platforms.
Do we need a server-side integration?
No. There is no call to our service from your side and no library of ours in your code. Everything happens in the journalist's browser, on the editor page.
What if we already have SEO fields?
Then most of the work disappears. Send us the selectors for those fields and they are used exactly as they are.
Which editors are supported?
CKEditor 4 and 5 and TinyMCE 5+ work immediately. For another editor, tell us which one and we add an adapter; the rest of the integration is unchanged.
Next step
Send us your editor structure.
We send back a test page.
Before anyone touches your CMS, we build a page that replicates your editor structure and run the full loop on it. Only then does the joint test move to your staging.