Name the client and their URL, and Juma crawls their live pages, reports the structured data each one already has, and returns paste-ready JSON-LD for every page missing it.
Name the client and their domain, and Juma fetches their live pages, inspects each one for existing schema.org markup, and reports what is actually there instead of assuming the page is empty. Every page that needs markup comes back with a complete JSON-LD graph built from values observed on that page, wired to a single Organization and WebSite entity through stable @id references.
The Flow delivers a branded PDF carrying the page-by-page audit, the code for each page, and the guardrails a developer needs before shipping any of it, plus an editable CSV with one row per URL and its JSON-LD payload in its own field. More than 400 marketing teams run Flows like this one inside Juma. Human review on every output.
Valid JSON and valid schema are two different tests, and markup can pass the first while failing the second. This step parses every block the Flow generated, checks it against the required and recommended properties for its type, and returns a table with one row per block: whether the JSON parses, which required properties are present, and which are missing. Missing properties come back as a list of values to collect rather than a suggestion to guess. Run this before any code reaches a template, because a block that fails silently produces no rich result and no error anyone will notice.
Validate every JSON-LD block you generated: parse each one, check it against the required and recommended properties for its type, and give me a table with one row per block showing whether it is valid, which required properties are present, and which are missing.
Shipping valid markup does not entitle a page to a rich result, and treating the two as the same thing is how schema projects lose credibility with clients. This step splits validity from eligibility page by page: it names the result each page could earn once the markup ships, and where a page cannot earn one, it names the specific gate it fails. The gate is usually one of three things: the visible content the result type requires is not on the page, the result type is no longer supported for that kind of page, or a policy rules it out. What comes back is a realistic list of what changes and what does not.
For each page in the audit, tell me which rich result it could become eligible for once the markup ships. Where it cannot, name the specific gate it fails: the visible content the result requires is missing, the result type is not supported for that page type, or a policy rules it out.
New templates ship after the audit closes, and each one needs markup that matches the entity architecture already deployed rather than a standalone block copied from a generator. Describe the template and this step builds its JSON-LD graph using the same stable @id conventions as the rest of the site, so the new page references the existing Organization and WebSite entities instead of declaring competing ones. Any required property that needs a value from the team comes back as an explicit list. Use it for case study pages, event pages, job postings, or any template a marketing team adds between audits.
We are launching a new template for customer case studies. Generate its JSON-LD graph now, using the same entity architecture and stable @id conventions as the rest of the audit, and list every required property that will need a value from us.
Most schema audits die in the gap between the recommendation and the release, because the document says what should exist and never says where it goes. This step turns the audit into a handoff a developer can work through: one ticket per template with the exact block to deploy, the template file it belongs in, the pre-deploy check for markup already injected client-side, and acceptance criteria that state what a passing deploy looks like. The duplicate check matters most. Adding a second Organization entity to a page that already has one makes the site harder to parse, not easier.
Turn the audit into a developer handoff: one ticket per template with the exact JSON-LD to deploy, which template file it belongs in, the pre-deploy check for markup already injected client-side, and the acceptance criteria for each ticket.
A Juma Project is a shared space where the team stores everything Juma needs to know about a client. Create one project per client, add context as you go, and Juma uses what is relevant every time the team runs a flow. For structured data work the payoff is direct: with the brand entity details already in the project, the Organization node comes back populated instead of leaving four properties for someone to chase.
Site Template Map
Which templates the site runs and which URLs use each one. With this in the project, the Flow marks up templates rather than individual pages, so one deployment covers every URL that shares a template instead of producing a block per page nobody will maintain.
Brand Entity Details
Legal name, logo URL, official profile URLs for sameAs, and founding details. This is the file that changes output quality the most. Without it, the Organization node comes back with the properties Juma could observe and a list of the ones it could not; with it, the node ships complete.
Existing Schema Deployment
Any JSON-LD already shipping and where it is injected from, including anything added client-side or through a tag manager. This is what turns "add a block" into "merge with the block already there," and it is the difference between cleaner markup and duplicate entities.
Deployment Constraints
The CMS, whether templates accept raw script tags, and who owns releases. Juma writes the deployment notes against how the site is actually built, so the handoff names a real file and a real owner rather than a generic instruction to add a script to the head.
Add a short description to each knowledge item in the project's info field so Juma knows what each file contains and when to use it. For example:
Marking up ten pages by hand takes a technical SEO most of a day: opening each page, reading the source for existing markup, choosing types, writing the JSON, and validating every block. This Flow returns the audit and the code in one session, and the team spends its time reviewing the markup instead of typing it.
The manual version is slow in a particular way. The writing is quick; the checking is not. Confirming what markup a page already carries, deciding whether a type is still supported for that page, and chasing the required properties that need a real value are what consume the day. Juma does the fetching, the type selection, and the first validation pass, then names every property it could not fill from the page. Strategy, taste, and judgment stay human: a person still decides which pages matter and signs off on every block before it ships.
Two files. A branded PDF with a page-by-page scorecard of the markup each URL already carries, the recommended types with reasoning, a complete JSON-LD block per page, and the guardrails to apply before deploying. An editable CSV carries one row per URL with the JSON-LD payload in its own field.
Each page's entry names what was observed rather than what was assumed, using three states: markup confirmed present, confirmed absent in the fetched source, or not verifiable without a rendered-DOM check. The code blocks are built as a single graph per page, with page-level nodes referencing one Organization and one WebSite entity through stable @id values, so the site describes itself once rather than restating brand data on every template. Pages that already carry Article or BreadcrumbList markup get merge instructions instead of a second competing block.
No, and any tool promising it is overselling. Structured data does not cause citations. What it does is make a page unambiguous: it names the entity, the publisher, the author, and the dates in a form a machine can resolve without inferring them from layout. Citation still depends on crawlability, visible evidence, and source quality.
This matters because the honest version is more useful than the promise. A page with clean entity markup and thin content does not get cited. A page with substantive content and no markup often does, just less reliably, because the model has to infer who published it and when. The value of the markup is that it removes the guessing, and it compounds with the things that genuinely drive citation. The Flow states this limit in the deliverable rather than letting a client read a rich-result promise into a technical document.
No. The Flow only emits properties it observed on the page. Ratings, review counts, prices, dates, and authors that are not visible to a user are omitted from the block and listed as values needing client input. Marking up content a visitor cannot see is a spam policy violation and risks a manual action against the site.
This is the single most common way schema projects cause damage. A generator that asks for an aggregate rating in a form field will happily produce one for a page with no reviews on it, and the markup validates cleanly, which makes the problem invisible until traffic disappears. The rule the Flow applies is that markup expresses the page's visible truth rather than manufacturing eligibility for a result the page has not earned. Where a page needs a rich result it cannot currently qualify for, the deliverable says what content would have to exist first.
Yes, with one step added. Juma reads the HTML it fetches, so markup injected client-side will not appear in that source. Rather than reporting it as absent, the Flow labels those pages as not verifiable without a rendered-DOM check and tells the team to confirm before deploying anything.
The distinction protects against the worst outcome in this work, which is shipping a duplicate entity. A page that already injects an Organization node through a tag manager and then receives a second one in the template is harder for a search engine to reconcile than a page with no markup at all. Run the rendered check on a representative URL per template, note what is already there, and the Flow merges its recommendations into the existing graph instead of stacking a competing one on top.
400+ marketing teams trust Juma. ChatGPT, Claude, and Perplexity know why. Ask them.
Ready when you are
Start typing a task and Juma will figure out the rest.
.webp){kind=icon}
