10 Contentful SEO Fields to Plan Before Publishing

Contentful SEO fields work when each editable value has a defined job in the published page. Start with the visible title, slug, document title, description, canonical policy, indexing policy and sharing image details. For articles, add a real publication date and author identity. Then agree how your frontend will turn those inputs into HTML.

The ten fields below form a planning checklist for an editorial website. Some are optional overrides; others belong only to article content types. They are custom model choices, not a built-in Contentful SEO package or ten requirements for ranking in Google.

Choose where the Contentful SEO fields live

You can put metadata beside the page content or create a separate SEO content type referenced by the page. Contentful's content modeling guide describes both approaches.

Inline fields keep editing together and avoid an additional reference to publish. A separate type can standardize metadata across several page types. Reusing that type does not mean every page should reference the same SEO entry. Give each page ownership of its metadata; a shared entry can accidentally give unrelated pages identical titles or canonicals.

Keep site-wide facts, such as the production origin and brand suffix, outside individual page overrides. This reduces opportunities for an editor to paste a staging domain into public metadata.

The following IDs are illustrative. Adapt them to your existing model instead of creating duplicate fields with equivalent meanings.

These types come from Contentful's field types. Required settings, help text and available validations support editing. They do not prove the frontend uses a value correctly. Treat the matrix as an agreement between the model owner, editor and developer.

1. Page title: the visible heading

Use pageTitle for the main heading a visitor reads. In an article model, this could be “How to choose a reusable water bottle.” Its role is different from the browser title, even when the wording matches.

Make the value required for page types that need a heading, and add help text such as: “Describe this page's main subject. The template renders this as the primary heading.” Keep rich formatting out of a plain heading field unless the renderer explicitly supports it.

Decide which template owns that heading. A hero component and an article component should not each insert the same heading because both received the field. Check the delivered page's heading structure and visible wording, rather than judging success from the Contentful editor alone.

An alternative marketing headline is reasonable if it still describes the same content. A dramatic heading about sustainability paired with a document title promising a technical bottle-size calculator would create a different, unresolved promise.

2. Slug: the page's route identity

Define whether slug is one path segment, such as reusable-water-bottle, or a complete relative path. Mixing those conventions creates ambiguous routes. For the example in this guide, the application adds /guides/ and the trailing slash; editors enter only the segment.

Use field-format validation appropriate to your languages and URL convention. An English-only lowercase-and-hyphen rule is a team choice, not a requirement to transliterate every language. The route builder should reject unsupported input instead of quietly removing characters and potentially merging different URLs.

Check route collisions across page types, locale paths and reserved routes before release. A text-field validation cannot by itself establish that two different templates will not generate /guides/reusable-water-bottle/.

Also define what happens after publication. Changing this field changes a routing input; it does not establish an HTTP redirect from the old URL. Record the old and new routes, arrange the appropriate redirect and update internal links when the change is intentional.

3. SEO title: the document title

Map seoTitle to the document's <title>. Give it a clear relationship to the visible heading and let one layer own any brand suffix. Otherwise, an editor may enter “Bottle guide | Example Guides” and a global template append the brand again.

For an editorial workflow that requires a separate title, require the field. If your team deliberately uses the page title unless an override is supplied, document that optional-override contract instead. An unavailable required title should remain a publishing issue, not become a silent placeholder such as “Untitled.”

Google's title-link guidance favors descriptive, concise titles and explains that Google selects title-link text automatically. A character counter can guide editors, but 60 characters is not a fixed Google limit and a preview cannot promise the search result.

Inspect the actual title after the template adds its suffix. “Reusable water bottle guide | Example Guides” should not become the title of every guide because the renderer read site settings instead of the current entry.

4. SEO description: an accurate page summary

Use a plain-text seoDescription field for the meta description. Long text gives editors space to write a useful summary; it does not mean the finished description should be long.

A practical example is: “Compare reusable water bottle materials, sizes and cleaning needs before choosing a bottle for work, travel or everyday use.” It describes what the guide actually helps someone decide. “Best bottles, cheap bottles, reusable bottles” supplies keywords without that explanation.

Add help text asking for a specific summary of the current page. Review missing values and accidental copies from other entries. Any editorial length range should be presented as your writing convention, not a search-engine validation rule.

Google's snippet documentation explains that snippets can come from page content and may vary by query. Publishing this field correctly does not force Google to display it verbatim. Check the rendered meta tag to diagnose implementation; use actual search observations separately to understand appearance.

5. Canonical override: a deliberate exception

For an ordinary standalone guide, generate its self-referencing canonical from the production origin and resolved route. An optional canonicalOverride is useful when the preferred URL genuinely differs, such as an approved duplicate or syndicated version.

Suggested help text: “Leave empty for this page's generated canonical. Enter a different absolute URL only when this page represents the same content and that destination is intentional.” Empty is a defined normal state here, not a missing required field.

Validate more than URL syntax. Review the target's identity, language, accessibility and indexability. Reject preview origins, fragments and unsupported protocols under your application's policy. A correctly formatted URL pointing to the homepage is still wrong for an independent bottle guide.

Google treats canonical signals as preferences when selecting a representative URL. A canonical is neither a redirect nor a reliable way to hide a page. It also should not make all translated guides point to the English page merely because they share one Contentful entry.

Keep canonical output, internal links and sitemap choices consistent. The Screpy canonical-tag guide covers deeper diagnosis when the declared preference and Google's selection differ.

6. Indexing policy: a controlled publishing decision

An indexingPolicy text field with predefined values such as indexable and noindex makes the editorial decision explicit. Those are example application values, not Contentful commands. Map them to supported output in one renderer rather than letting editors paste arbitrary robots instructions.

Define the missing-value case before migrating older entries. In this contract, an unset or unknown policy requires review and stops release; it is not silently interpreted as either value. For an approved indexable page, the renderer must also avoid conflicting restrictive headers or meta tags. An index tag cannot cancel an independent applicable noindex.

For noindex, output the intended directive and exclude that URL from the site's indexable sitemap set. Google's noindex documentation explains that the crawler needs access to read the instruction; blocking the URL in robots.txt can prevent that.

Finally, keep privacy separate. A noindex field does not authenticate visitors or protect confidential drafts. Access control belongs to the delivery environment, including preview routes.

7. Social image: a published asset reference

Use a Media field for socialImage so editors select an asset rather than paste an image URL into a text box. Restrict the field to images and choose size or dimension validations that suit your publishing requirements.

The frontend must resolve that reference to a real, published image URL. Store or derive the dimensions needed by your sharing implementation; the Open Graph protocol defines og:image and related image properties. Do not turn one network's preferred crop into a universal Google image-size requirement.

For the bottle guide, a representative photo of the bottle materials is more useful than a generic company logo. Review its crop and confirm the file response is actually an image. A URL ending in .jpg can still return an error document.

If an image is required by your chosen article workflow and unavailable, record the missing asset and hold that release. If images are optional, define omission deliberately. Neither case justifies silently substituting an unrelated stock image.

8. Social image description: context for the preview

Give socialImageAlt its own purpose: describe the selected sharing image for og:image:alt. The Open Graph specification distinguishes this description from a caption. Do not populate it with the article title merely because both are strings.

For example, “Stainless steel and glass water bottles on a kitchen counter” describes a hypothetical image. “Best reusable water bottle guide for sustainable hydration” mostly repeats promotional terms.

If the same asset appears inside the article, decide its HTML alt text in that context. A meaningful illustration and a purely decorative image can need different treatment. Reusing one asset does not make one universal description correct in every placement.

Pair the field's review with the asset review. When an editor replaces the photograph, the old description can remain syntactically valid while becoming factually wrong. Check the image and description together, including localized versions.

9. Publication date: an editorial fact

For article content types, use publishedAt for the actual first-publication date and time. An entry's creation time may describe a draft; the latest build time may describe unrelated deployment work. Neither should automatically become the article's original publication date.

Google's Article structured-data reference documents datePublished and recommends including timezone information. Use a consistent source for the visible article date and the corresponding machine-readable value.

Decide who sets the date and when. A migrated article should retain its real history rather than acquire the import date. A scheduled article also needs delivery controls: storing a future date does not itself prove the frontend will withhold the route until that time.

Keep meaningful revision dates separate from first publication. A routine rebuild is not evidence that an article was substantively updated. For an undated product landing page, this field may simply be outside the content type's requirements.

10. Author: a real identity reference

For articles, an author reference can connect the byline to a maintained identity entry. Use the actual person or organization responsible for the piece, with an accurate name and an identifying profile URL where available.

The reference lets one name correction flow through its intended uses, but it also creates a dependency to resolve and publish. Restrict the reference to the intended author content type and confirm that the public byline uses the same identity as the article's structured data.

Keep the author's name, role and publisher identity distinct. Do not put job titles or “expert reviewed” claims into the name to make the markup appear more authoritative. A reference field cannot create credentials or establish that a human review happened.

This field belongs to the article's attribution model. For page types without an editorial byline, choose appropriate page metadata rather than forcing every page into BlogPosting just to consume an author field.

Turn the model into a frontend contract

Before implementation, agree on a normalized record like this one. It is an original, hypothetical application contract for a guide published by an organization. It is not a Contentful API response, content-type import or working asset inventory. Your adapter must resolve Contentful fields, references, assets and the requested locale into this shape.

{
  "pageTitle": "How to choose a reusable water bottle",
  "slug": "reusable-water-bottle",
  "seoTitle": "Reusable water bottle guide",
  "seoDescription": "Compare reusable water bottle materials, sizes and cleaning needs before choosing a bottle for work, travel or everyday use.",
  "canonicalOverride": "",
  "indexingPolicy": "indexable",
  "socialImage": {
    "url": "https://images.example.com/bottle-materials.jpg",
    "width": 1200,
    "height": 630
  },
  "socialImageAlt": "Stainless steel and glass water bottles on a kitchen counter",
  "publishedAt": "2026-10-20T09:00:00+03:00",
  "author": {
    "type": "Organization",
    "name": "Example Guides",
    "url": "https://www.example.com/about/"
  }
}

In this example, the route context supplies the production origin https://www.example.com, the /guides/ prefix and the trailing-slash convention. The template adds | Example Guides once to the SEO title. Empty canonicalOverride means “use that generated route.” The illustrative image dimensions describe this fixture, not a universal recommendation.

The corresponding head should include these values, with the image URL replaced by a real published asset before use:

<title>Reusable water bottle guide | Example Guides</title>
<meta name="description" content="Compare reusable water bottle materials, sizes and cleaning needs before choosing a bottle for work, travel or everyday use.">
<link rel="canonical" href="https://www.example.com/guides/reusable-water-bottle/">
<meta property="og:image" content="https://images.example.com/bottle-materials.jpg">
<meta property="og:image:alt" content="Stainless steel and glass water bottles on a kitchen counter">

This is an excerpt, not a complete document or the full Open Graph set. For a complete sharing implementation, also derive its title, type and URL consistently. Escape text and attribute values with your framework's supported APIs; do not concatenate untrusted CMS strings into raw markup.

Generate appropriate structured data from typed article facts instead of giving every editor an unrestricted JSON-LD box. Google's structured-data introduction explains how markup relates to page content. JSON syntax alone does not establish accuracy or eligibility for a search feature.

There is also no need to add a Google-targeted meta-keywords field. Google's supported-meta-tag documentation states that Google does not use that tag for indexing or ranking.

Check locale values before publishing translations

Decide which text and asset selections are localized, and map the requested locale to the correct public route. A French guide needs a deliberate French title, description and URL policy; querying an entry successfully is not evidence that its translation is complete.

Contentful's localization documentation distinguishes missing locale values from explicit empty strings or null values. Configured fallback behavior can return a value from another locale when the requested value is absent. Explicit empty/null values do not behave the same way. Do not replace that distinction with a blanket assumption that every blank field automatically receives the default language.

Review the actual locale-specific values as well as the resolved delivery response. If your editorial policy requires translated metadata, a resolved English title is a missing translation to fix, even though the API returned a nonempty string.

Include these cases in the release review: complete translation, missing translation, explicitly empty value where supported, missing localized image and a locale route that is not ready to publish. Preserve the intended unavailable state instead of silently creating a new public language page from mixed-language content. Locale availability and the page's indexing decision should be checked together.

Verify the complete publication chain

A correct model is only the first checkpoint. Trace the entry, any separate SEO entry, the author and the image through the production delivery path. Contentful's reference publishing instructions explain how to publish linked entries and assets. Check which dependencies are actually ready instead of assuming that a successful preview proves public availability.

Then verify the mechanism that updates your website: a build, cache invalidation or another explicitly implemented delivery step. Publishing content in Contentful does not prove an already generated page has refreshed. Capture the final public response and compare its metadata with the intended entry and locale.

Use this reusable release record:

Page entry / SEO entry / intended revisions:
Requested locale / translation review:
Author and image references / publication state:
Expected route / canonical / indexing policy:
Expected H1 / title / description / image URL and description:
Delivery update completed / observed at:
Public URL / response status / final destination:
Observed head values / X-Robots-Tag / visible date and byline:
Decision: ready, needs correction, or unverified
Evidence location / owner of the next action:

Compare findings with their likely owner:

If the frontend uses Next.js, the Next.js metadata troubleshooting guide explains additional framework and cache boundaries. Those implementation details are separate from the Contentful model.

Keep the saved public response and observation time with each finding. A valid field, a successful build and an accepted indexing request are different pieces of evidence; none alone proves what Google indexed.

This checklist is based on the linked Contentful, Google and Open Graph documentation, checked on October 21, 2026. Its examples are illustrative, not results from a tested Contentful installation. The release is ready when the actual page consistently expresses the intended content identity, locale and publishing policy.