Zeo delivery method

HTML & Structured Markup

One page purpose carried by the title, headings, links, canonical, and schema, proven on the HTML the template actually renders.

Search engines and assistive technology don't read the design file. They read the HTML that actually renders, including the duplicate H1, the empty link, or the schema field nobody notices in a browser. We inspect what really renders for each template, set a markup contract for titles, headings, links, and structured data, and test it against representative pages before it ships everywhere. We align titles, headings, links, canonicals, and structured data around one page purpose, then prove the live template keeps that meaning intact.

Open the markup with ZeoOn-Page SEO
A Zeo developer assembles title, heading, link, canonical, and schema blocks into a clean browser-page outline.

Some of the 500+ brands we've worked with

See all references
  • KPMG
  • Akakçe
  • TRT
  • Canbebe
  • Bernardo
  • Quick Sigorta
  • Amazon
  • BMW
  • Shell
  • Hyundai
  • PepsiCo
  • Red Bull
  • Decathlon
  • MediaMarkt
  • Bayer
  • Sanofi
  • EY
  • GE
  • 3M
  • Domino’s
  • Lexus
  • Trendyol
  • Hepsiburada
  • Yandex

Stages and gates

How we do it

We start by finding the templates and who owns them, since one fix rarely helps just one page. From there we inspect what actually renders, agree on what the markup can honestly claim, and test real samples before anything ships wider.

  1. Find the templates and their owners

    We group URLs by actual template, rendering path, content source, and component ownership instead of auditing isolated pages one by one. The engineering lead confirms which team owns each template before a fix gets scheduled.

    A template register that shows where one fix can solve the same defect everywhere.

  2. Inspect what really renders

    We capture response HTML and browser DOM, then check titles, H1s, heading order, landmarks, links, images, canonical controls, and content that appears only after JavaScript runs. A specialist checks whether a flagged mismatch is a real defect or an intentional template variation.

    A defect map tied to the component or template that caused it.

  3. Set the markup contract

    We choose supported schema types, map every property to a visible and owned source, and define what happens when the value is empty, stale, or not eligible. Content, data, and engineering owners agree which schema types the page can honestly support and what happens when a value is missing.

    One specification that content, data, SEO, and engineering can all read the same way.

  4. Ship and test representative samples

    The change goes through the owning template, then we compare source HTML, rendered DOM, visible facts, canonical behavior, and validators across normal and edge cases. The template owner approves the release and confirms the rollback path before it reaches the rest of the site.

    A live implementation that matches the accepted contract, with a rollback path if it doesn't.

AI reads what renders at scale; people decide what the page can honestly claim.

AI compares DOM signatures across large URL sets to cluster pages by the template that actually renders them, diffs response HTML against rendered DOM to flag missing or duplicated titles, headings, and canonical tags, matches candidate schema properties against the page's visible content and flags the ones with no visible source, and reruns the validators and DOM comparison across normal and edge-case samples after every build. What the markup may claim is not its call. We do not emit fabricated ratings, reviews, authorship, prices, availability, events, or policy data, we never add hidden content to make a property look supported, we do not keep an ineligible type because a validator accepts its syntax, and we do not promise rich-result display.

Deliverables and acceptance

What you get

Page semantics stay tied to the template that actually emits them.

  • Architecture map

    Template markup register

  • Decision matrix

    Semantic & eligibility matrix

  • Policy document

    Property-to-source contract

  • Evaluation sheet

    Rendered validation pack

We call it done when: The template register, semantic matrix, property-to-source contract, and validation pack are done when every in-scope URL maps to a tested template, rendering path, source, and implementation owner, every matrix row carries its live DOM example, template, severity, and eligibility reason, every emitted property has a visible fact, one canonical source, an owner, and a missing-value behavior, and source HTML, browser DOM, visible content, canonicals, and validators agree across normal and edge samples.

Fit and readiness

When you need this

If a page only makes sense after CSS and JavaScript have done their best, the document underneath is doing too little.

A good fit when

  • Titles, H1s, headings, landmarks, or link text are inconsistent across a shared template, so the rendered document no longer carries one clear page purpose.
  • Canonical tags, metadata, and rendered page purpose don't reliably point to the same URL or intent.
  • Structured-data properties exist, but their visible source, owner, or stale-data behavior is unclear.

Better handled as other work when

  • You expect markup alone to earn a ranking or rich result while the visible page remains incomplete or contradictory.
  • The owning template can't be inspected or changed, and nobody can test the rendered HTML after release.

If one of these is closer to your situation, start here instead: On-Page SEO

We call it done when: Representative templates render a coherent document outline, links that mean something, correct canonical controls, and only the structured properties the visible page can honestly back up.

The specialists behind this SEO work

Zeo's SEO work goes back to 2006, when we started what we call the first SEO blog in the MENA region. The consultants shown here are doing that work today, matched to what this page covers.

Content we've produced on this topic

Articleby Elif Naz Akan KarakoçStructured Data for AI: Tips for Supporting AI Visibility with SchemaArticleby Samet ÖzsüleymanMost Common JSON-LD Schema Issues and SolutionsArticleby Samet ÖzsüleymanHow to Manage Product Variants with isVariantOf Schema?

Tools we use

Tools behind this work

  • Screaming Frog

    source HTML, rendered DOM, canonical, and heading comparisons

  • Sitebulb

    rendering differences and template-level semantic defect triage

  • Schema App

    schema property mapping, deployment, and eligibility checks

  • Lumar

    large template cohorts and repeatable rendered crawl checks

  • Google Search Console

    live rich-result issues and post-release item trends

  • Bing Webmaster Tools

    live URL inspection and Bing-detected markup review

Next step

Inspect the document beneath the design

Bring a few representative templates and whatever validation output you already have. We'll help you find the shared markup problems worth fixing first.
Open the markup with Zeo

Before we start

Questions we hear

Should every available schema.org property be included?

No. We choose properties that accurately describe visible facts, add useful meaning, and have a maintainable source. More markup is not automatically better markup.

Does valid schema guarantee a rich result?

No. Validation proves syntax and some eligibility conditions. Search systems still decide whether and how a feature appears.

Why test both source HTML and browser DOM?

JavaScript, consent, and component timing can change what the browser builds after the initial response. A correct source file is not enough if the crawler or user receives something different.

Do we need to fix every page individually, or just the template?

Whenever the defect comes from a shared template, one fix and one release fixes every page that uses it. Pages built outside the template, or with page-specific overrides, still need their own review. The template register tells you which is which.