Schema Markup Explained for Non-Technical Founders

Schema markup is a short, structured description of a page, written for software rather than people, that states what the page is about in terms a search engine can read without guessing. A person landing on your service page sees a heading, a few paragraphs, a list of what is included and a contact button, and understands within seconds that a company is offering a service. A search engine sees text and code, and has to infer the same thing. Structured data removes some of that inference by saying it plainly: this page describes a service, this is the organisation that provides it, and this is the area it serves.

The word “schema” simply means an agreed structure. The markup is the set of labels that follows that structure. Put together, schema markup is a label set that describes things already on the page: a business name, an address, an article’s headline and author, a product’s price and availability.

For a founder who does not write code, the most useful comparison is a well-kept filing label. The document inside the folder is what matters. The label does not make the document better, more persuasive or more trustworthy. It makes the document easier to find and harder to misfile. And a folder labelled “Invoices” that actually contains holiday photographs is worse than an unlabelled folder, because now the label is lying.

That comparison carries the whole discipline. Schema describes the page; it does not change it. If the page is thin, structured data will describe a thin page accurately. If the page is strong, structured data helps machines understand that strength with less ambiguity. What it never does is manufacture quality, reviews or authority that the visible page does not already have.

Structured data and rich results are often used as though they were one thing. They are not. Structured data is the description, and you control it. A rich result is one possible display in search, and the search engine decides, page by page, whether to show it.

Every page with structured data has two layers: the visible content that visitors read, and a machine-readable description of that content that visitors never see. The relationship between them is governed by one strict rule: the description must match the visible layer. Google’s general structured data guidelines ask site owners not to mark up content that is hidden from readers, and markup that misrepresents a page is treated as a policy problem rather than a clever extra.

Picture a service page for an accounting practice. The visible layer has a headline naming the service, a description of what is included, the city the firm serves, a short set of questions and answers, and the firm’s name in the header. The machine layer states that the page describes a Service, provided by a named organisation, available in a named area, and sitting under “Services” in the site’s structure. Every claim in the machine layer can be checked against something a visitor could read.

Now picture the same page with a machine layer that also claims glowing star ratings from a crowd of reviewers, offices in cities the firm has never operated in, and a fixed price the page never mentions. None of that is visible. To a search engine that checks, the page now says one thing to people and another thing to software. That mismatch is exactly the pattern that structured data policies exist to catch.

The two-layer view helps founders in a very practical way. You do not need to read code to review structured data. You need someone to show you, in plain language, what each block claims, and then you check each claim against the page on screen. If a claim cannot be pointed to, it should not be in the markup.

It also clarifies ownership. The visible layer belongs to whoever approves the page; the machine layer belongs to whoever maintains the site. When the two drift apart, it is usually because content changed and nobody told the markup.

JSON-LD is the most common way to add structured data because it sits in one self-contained block, separate from the page’s design, and Google recommends it where a site’s setup allows. It is not the only format, but for most business websites it is the sensible default.

Three formats are in general use. Microdata and RDFa work by adding attributes directly to the HTML elements a visitor sees, so the heading itself carries a label saying it is a headline, and the price text carries a label saying it is a price. JSON-LD takes a different approach. It places a single block of structured text in the page, listing the facts as named properties with values, without touching the visible elements at all.

For a growing business, that separation matters more than the syntax. With attribute-based formats, every design change risks breaking the markup, because the labels are woven through the layout. A designer moves a price into a new component and the label is left behind. With JSON-LD, a section can be redesigned while the description block stays intact, and a developer can regenerate that block from the same data that feeds the page.

That last point is the real advantage. On a well-built site, the JSON-LD block is not typed by hand. It is generated from the same source as the visible content: the article’s title field feeds both the heading on the page and the headline property in the markup, and the product record feeds both the price shown and the price described. When one source feeds both layers, they cannot quietly disagree.

JSON-LD also has a weakness. Because it is separate from the visible content, it is easy to write things into it that the page does not show. The format is not the safeguard; the process around it is. Most platforms output JSON-LD by default, so your real decisions are which types to use, which pages carry them and where the values come from.

Schema.org is a shared vocabulary, run as an open project that the major search engines started together, which defines the names of things and their properties so that every website can label them in the same way. When a developer says a page uses “schema”, they almost always mean this vocabulary.

The vocabulary is large and arranged as a family tree. A LocalBusiness is a kind of Organization. A BlogPosting is a kind of Article, which is a kind of CreativeWork. Each type has properties. An Organization can have a name, a logo, a url, contact points and sameAs links to its official profiles. A Product can have offers, and each offer can have a price, a currency and an availability status.

A type existing in Schema.org does not mean any search engine will do anything with it. Schema.org describes what can be said; each search engine documents the subset it reads. A plugin may offer a long menu of types, but most earn nothing beyond accurate description.

Entities: things, not strings

An entity is a distinct, identifiable thing: a company, a person, a place, a product or a published work. Search engines organise a great deal of their understanding around entities rather than simply matching words. A brand name that is also an everyday word could belong to a law firm, a paint company or a hill station. The entity “this law firm, at this address, with this website and these official profiles” is unambiguous.

Structured data helps by connecting the mentions on your site to one clear entity. The sameAs property links your organisation to profiles you control. The author property ties an article to a named person who has a page of their own. Consistent names, addresses and web addresses across pages reduce the chance that your business is confused with another using a similar name. This is clarity, not promotion. The goal is to be identified correctly, which is the precondition for being found for the right things.

Structured data can make a page easier to interpret and, for some page types, eligible for enhanced displays in search; it cannot create rankings, reviews or trust that the page has not earned. Keeping those two lists apart is the single most useful habit a founder can bring to any conversation about schema.

What it can do

• Declare the page type. It tells a machine reader that a page is an article, a product, a location or a service description, rather than leaving that to inference.
• Identify the entities involved. It names the business, the author, the product or the place, and connects them to the same entity described elsewhere on the site.
• Supply precise details. Dates, prices, currencies, availability, opening hours and addresses are stated as values rather than buried in sentences.
• Support eligibility for some features. For the types a search engine supports, valid and accurate markup is usually a condition for enhanced displays. It is a condition, not a promise.
• Reduce ambiguity for machine readers. Where a page could be read more than one way, a clear description narrows the options.

What it cannot do

• It cannot lift rankings on its own. A page ranks because it is relevant, useful and trusted for a query. Describing the page well does not substitute for any of those qualities.
• It cannot guarantee a rich result. Search engines decide when to show enhanced displays, and they retire whole features from time to time.
• It cannot create reviews or trust. Ratings in markup must reflect genuine reviews that visitors can read. Markup that invents them is a liability, not an asset.
• It cannot rescue thin content. An accurate description of a weak page is still a description of a weak page.
• More types do not add up to more value. Each extra type is something to maintain and something that can go wrong. The right number is however many honestly describe the page.

One indirect benefit is worth stating carefully. When a search engine does show an enhanced result, it can be more useful to the person searching. That is a benefit of clearer presentation, not a ranking effect, and it lasts only as long as the feature does.

Organization markup describes the business itself, including its name, logo, website address, contact channels and official profiles, and it usually belongs on the homepage or the about page rather than being repeated in full on every page. It is the foundation that other markup on the site refers back to.

The useful properties are the ones a visitor could verify. The name should match the name shown on the site. A legal name belongs only if the site actually displays it. The logo should be the real, current logo. Contact points should be channels the business answers. The sameAs property should list profiles the business controls, such as its own social accounts or a verified business profile, and never directories or pages it does not own. Search engines may use organisation details in places such as the logo shown alongside some results or a panel of business information, but whether and how they do so is their decision.

Why not add the full Organization block to every page? Because repetition adds noise and multiplies maintenance. When the phone number changes, every copy must change, and on a site with many templates one is always missed. The cleaner approach is to describe the organisation fully in one place and let other pages refer to it. An article’s publisher, for example, can point to that single description through a stable identifier rather than restating every detail. Your developer will recognise this as referencing by identifier; you only need to know that one accurate description beats many slightly different ones.

WebSite

WebSite markup describes the site as a whole, chiefly its name and address, and it normally sits on the homepage alone. Search engines may use it when deciding which site name to display in results, which matters most when your brand name differs from your domain. It is small, stable and rarely needs changing once it is correct.

WebPage

WebPage and its more specific forms, such as AboutPage, ContactPage and CollectionPage, describe individual pages. Many frameworks add them automatically. They are harmless when accurate and rarely decisive; the only check worth making is that they do not contradict the page.

BreadcrumbList describes a page’s position in the site’s hierarchy, such as Home, then Services, then a named service, and it suits almost every page below the homepage, provided the trail matches the site’s real structure. It is one of the least glamorous types and one of the most consistently useful.

A breadcrumb trail tells a search engine how pages relate to one another. It confirms that an individual service belongs to a family of services, or that an article sits inside a particular section of the blog. Some search engines may use that trail when displaying a result, in place of or alongside the raw web address, though presentation varies by search engine and device and can change without notice.

The rule is the same one that governs everything else. The trail should mirror the breadcrumbs visitors see, or at the very least the real path through the site’s navigation. Each step should be a real page that loads. Three failures come up again and again: trails that point to category pages which were deleted in a redesign, trails whose step names are stuffed with keywords that appear nowhere in the navigation, and pages that output two different trails because a theme and a plugin each add one.

The founder check takes a minute. Ask for the trail on a few important pages, read the step names aloud, and open each step. If the names match what visitors see and every step lands on a real page, the markup is doing its job.

Article or BlogPosting markup describes a published piece of writing through its headline, author, publication and update dates, main image and publisher. BlogPosting is the more specific choice for blog entries, and a general Article works too; accuracy matters far more than which of the two you pick.

The headline in the markup should match the title readers see. The main image should be one that actually appears in the article. The publisher should point to the organisation described elsewhere on the site. The dates should be true: when the piece was first published and when it was last meaningfully changed.

Authors

Author details belong in the markup only for a real, named author, ideally with a visible byline and a page that says who they are. If an article is written by an editorial team, say so plainly on the page and in the markup rather than inventing a person to attach it to. Never add credentials, job titles or profile links the person does not actually have. The purpose of author information is to identify who is responsible for the content, and a fabricated author defeats that purpose entirely.

Dates

Update dates tempt people to cut corners. Changing the modified date without changing the article, so that the piece looks freshly revised, is a misdescription. A genuine update, such as replacing outdated guidance, adding a new section or correcting an error, justifies a new date. A changed comma does not. On a CMS, the safest arrangement is a modified date that updates only when an editor saves a real revision, with the visible date on the page drawn from the same field.

LocalBusiness markup describes a business that serves customers at a real physical location, with an address, telephone number and opening hours, and it belongs on a location page, or on the homepage of a single-location business, only when that location genuinely exists and receives customers or operates from that address.

The vocabulary includes many specific forms of LocalBusiness, such as dentists, restaurants, accounting services and hotels. Choosing the most specific honest type helps interpretation a little; choosing a type that does not describe the business, because it sounds more impressive, helps nothing. The core properties are name, address, telephone, url and opening hours. Geographic coordinates belong only when they are accurate to the actual premises, and opening hours only when they reflect when the business is really open, including how holidays are handled.

Several locations

A business with several real branches should give each one its own page with its own LocalBusiness description, and each description should match that page: its own address, its own hours, its own phone number. What it should not do is create a page for every city it would like to rank in and mark each one up as a branch. A service business that travels to clients can describe the areas it serves on a page without claiming an address in each of them. Marking one business up as locations it does not have is precisely the kind of claim that damages trust with search engines and with customers who turn up at an empty address.

Markup and business profiles

For local search, markup is a supporting signal rather than the main event. A properly maintained business profile on the map platforms people use, genuine reviews collected there, and a name, address and phone number that match everywhere they appear usually do more of the work. Markup supports that consistency by stating the same facts on your own site. The wider picture is covered in our guide to local SEO for service businesses, which puts structured data in its proper, modest place.

Service markup describes work a business performs, and Product markup describes a defined item a customer can buy; marking a service up as a product to chase price or rating displays is a misdescription, however common it is.

Service markup can name the service, describe it, identify the organisation that provides it, state the area served and give the type of service. If the page shows a price or a starting price, an offer can describe it; if the page does not, the markup should not either. Service markup is not tied to a dedicated rich result in Google’s documented features, so its value is description: it tells a machine reader, clearly and consistently, what you do, who does it and where.

The temptation is easy to understand: product results can display prices and stars, and some plugins make it one click to label any page as a product. But a consultation, a retainer or a custom project is not a product with a basket price, and describing it as one misrepresents the page.

The better investment is in the visible page. A service page that explains the offer clearly, shows who it is for, answers real objections and gives a straightforward next step will do more than any label. Our guide on service pages that rank and convert covers that structure in depth, and structured data then simply describes the result.

When Product is right

Product markup fits a page that sells a defined item, with offers that state price, currency and availability exactly as the page shows them. If the page lists variants, the markup should describe the same variants. If an item goes out of stock, the availability in the markup should change when the page changes. Search engines may use accurate product data for enhanced product displays, and their merchant tools often have additional requirements of their own, so an ecommerce business should treat product data as a live feed to be kept correct, not a one-off task.

The grey area of packaged offers

Some businesses sell packaged services: a fixed-scope audit bought online, a recorded course, a software subscription. The honest test is practical. Could a customer select it, see a fixed price and complete a purchase as the page presents it? If so, Product or a more specific type, such as a course or a software application, may describe it truthfully. If the page leads to a conversation, a proposal or a custom quote, it is a service, and Service is the right description.

FAQPage markup can still describe questions and answers that are visible on a page, but Google stopped showing FAQ rich results in Search from 7 May 2026 and has since removed that feature’s documentation, so nobody should add FAQ markup expecting an expanded FAQ display in Google results.

This change followed a long narrowing. For some years Google had already limited FAQ rich results to well-known, authoritative government and health websites, which meant that for most businesses the display had effectively disappeared well before it was formally retired. A similar retirement happened earlier to how-to results. Anyone still selling FAQ markup as a way to take up more space on a Google results page is selling a feature that no longer exists there.

So is FAQPage worth adding at all? It depends on cost and accuracy. FAQPage remains a valid type in the Schema.org vocabulary, and it accurately labels a real question-and-answer section. Other search engines, tools or answer systems may read it; none can be promised to. If your CMS generates it automatically from the same fields that display the questions, it costs almost nothing to keep. If it requires hand-maintained code that will drift from the visible questions, it is not worth the upkeep. Either way, questions that exist only in markup and not on the page should never be added.

What matters far more is the visible FAQ itself. Questions written the way buyers actually ask them, answered directly in the first sentence and then explained, help human readers first and give any machine reader clean, quotable text. That discipline is at the heart of what answer engine optimisation actually involves, and it does not depend on any particular markup being displayed.

The wider lesson: markup chosen to chase a display can lose its purpose overnight, while markup chosen to describe the page accurately stays useful whatever happens to the display.

Review and AggregateRating markup should only describe genuine reviews that visitors can read on the same page, and this is the area where misleading structured data does the most damage to a business’s credibility.

The boundaries are clear enough to write as a list:

• Reviews must be real. They should come from genuine customers, not be written, paraphrased into ratings or selected and scored by the business.
• Reviews must be visible. Google’s review snippet guidelines require that review content be readily available to users on the marked-up page, and that it be obvious the page contains reviews.
• Reviews must not be borrowed. The same guidelines say not to aggregate reviews or ratings from other websites into your own markup.
• Self-serving reviews have their own rule. Google’s current guidelines say that when a business controls reviews about itself, including through an embedded third-party widget on its own site, its LocalBusiness and Organization pages are ineligible for star review displays.
• Numbers must match the page. An aggregate rating and review count in markup should be the figures a visitor sees, and should update when they change.

The practical consequence for a service business is significant. A homepage with a few client testimonials is perfectly good visible content. Turning those quotes into an aggregate star rating in markup describes something that is not there: a rating system. And even if the business ran a genuine review system on its own site, the self-serving rule means star displays for its own LocalBusiness or Organization pages should not be expected. Testimonials belong on the page as testimonials; the markup should leave them alone.

For ecommerce, the picture is different. A product page that collects and displays genuine customer reviews can describe them with Review and AggregateRating markup, as long as the values reflect exactly what is displayed. Ratings that are hidden, filtered to remove poor reviews, or copied from a marketplace listing do not qualify.

The risk also goes beyond search, because presenting invented reviews as genuine can create consumer-protection exposure in many markets. If a real customer did not write it and a visitor cannot read it, it does not go in the markup.

Most business pages need one primary type plus a breadcrumb trail, and the right choice follows from what the page actually is. The table after this chapter summarises the common page types in three columns: what usually fits, what fits only if it is true, and what to avoid. The middle column is where most mistakes are made, because it holds markup that is right for some businesses and wrong for others.

Homepage

Organization and WebSite usually fit, describing the business and the site as a whole. LocalBusiness fits only when the business has a real physical location that the homepage represents. Avoid Product or review markup for the whole business: a company is not a product, and a rating for the entire business on its own homepage runs straight into the self-serving review rule.

Service page

Service and BreadcrumbList usually fit. FAQPage fits only when the questions and answers are visible on the page, and even then it should not be expected to produce an FAQ display in Google. Avoid Product markup for a service, for the reasons covered in the chapter on the line between the two.

Article

Article or BlogPosting, with BreadcrumbList, usually fits. Author details fit only for a real, named author. Avoid marking up text that is not on the page, such as a summary, headline or set of questions that exists in the markup alone.

Product page

Product with offers usually fits, with price, currency and availability matching the page. AggregateRating fits only for genuine reviews shown on that page. Avoid ratings that are not visible or not real, including scores imported from elsewhere.

Location page

LocalBusiness with address and hours usually fits. Opening hours and coordinates fit only when they are accurate. Avoid marking one business up as locations it does not have, whether through city pages dressed as branches or addresses that customers cannot visit.

About page

Organization details usually fit, since this is a natural home for the full description of the business. The sameAs property fits only for profiles the business controls. Avoid repeating the full Organization markup on every page; describe it once, well, and let other pages refer to it.

The common structured data errors are describing things the page does not show, choosing the wrong type, leaving values to go stale, publishing conflicting duplicate blocks, and injecting the same markup across every page. Each one is easy to make and easy to miss, because none of them is visible to a visitor.

1. Invisible claims. Ratings, prices, questions, addresses or credentials that exist in markup but not on the page. This is the most serious error because it is a misrepresentation, not just a mistake.
2. The wrong type. Product for a service, LocalBusiness for a business with no premises customers can visit, or a news article type for an evergreen guide. The markup may validate perfectly and still describe the page wrongly.
3. Conflicting duplicates. A theme and an SEO plugin each output an Organization block, with different names, different logos or different contact numbers. A machine reader now has two versions of the truth and no reason to prefer either.
4. Stale values. A price changed on the page but not in a hand-pasted block, opening hours that ignore a new schedule, or a closed branch still described as open.
5. Site-wide injection. A template that adds the same FAQPage, AggregateRating or LocalBusiness block to every page, whether or not that page has any of the content described.
6. Copied code. Markup lifted from another site or a tutorial that still carries someone else’s name, web address or logo. It happens more often than anyone admits.
7. Syntax errors. A missing bracket or comma can make an entire block unreadable. The page looks fine to visitors, and the markup silently does nothing.
8. Markup on pages search engines cannot use. Carefully described pages that are blocked from crawling or marked not to be indexed. The description exists, but nothing reads it.

The consequences range from wasted effort to real harm. Invalid markup is usually just ignored. Misleading markup is different: Google can apply a manual action for structured data that breaks its guidelines, which removes eligibility for rich results until the problem is fixed and a review is requested. The larger cost is often internal, because a site full of conflicting descriptions is also a sign that nobody owns the facts about the business.

Structured data should be checked twice before launch, once for correct use of the vocabulary and once for eligibility in search features, and then monitored after launch, because a block that passes today can break with the next template change or plugin update.

Two tests, two questions

The Schema Markup Validator, provided by the Schema.org project, checks whether markup is well formed and uses the vocabulary correctly, for any type. Google’s Rich Results Test answers a narrower question: whether a page’s markup is valid for the specific features Google supports, and whether the page is eligible for them. Eligible does not mean the feature will appear. It means one condition has been met.

This prevents a common false alarm. Service markup can pass the Schema.org validator while the Rich Results Test reports no rich result. That is expected, not a failure, and no reason to add Product markup.

What to ask for as a founder

• A test result for each page template, not only the homepage.
• A plain-language list of what each block claims, so you can check every claim against the visible page.
• A separation of errors from warnings. Errors usually prevent a feature from working. Warnings often flag optional properties that are missing.
• Confirmation that no warning was cleared by inventing a value. An optional property left empty is better than one filled with something untrue.

Search Console after launch

Once the site is live, Google Search Console becomes the monitoring tool. Where Google detects supported structured data, it reports valid items and items with issues for those features. The URL Inspection tool shows the structured data Google found on a live page as it saw it, which is useful when a page renders differently for a search engine than for a browser. The Manual Actions report is where a structured data policy problem would be flagged. Reports update with a delay, so check them after each significant deploy rather than expecting instant confirmation.

For a page-level view that goes beyond markup, Branditify’s checker that shows what search and answer engines can read on a page explains which signals are present and which checks can be verified from the page itself. It looks at one page at a time and is not a site crawler, so it complements template testing and Search Console rather than replacing them.

The reliable way to keep structured data accurate is to generate it from the same fields that render the page, so that a content change updates the markup automatically; hand-pasted blocks go stale, usually without anyone noticing.

Three patterns come up repeatedly. A price is edited in the CMS while a forgotten code field keeps the old one. A blog template hard-codes one author for every article. A branch closes, but its LocalBusiness block in a shared footer keeps describing it.

Rules to build into templates

• One owner per type. Decide which part of the system outputs Organization, which outputs breadcrumbs and which outputs page-specific types, and switch off every other source.
• Conditional output. Output AggregateRating only when genuine reviews exist and are displayed, and FAQPage only when the page’s FAQ section actually has items.
• Values from content fields. Headlines, prices, hours, dates and authors should come from the same fields that display them, never typed twice.
• No site-wide page types. Page-specific markup belongs to page templates, not to the header or footer.

Plugins and platforms

SEO plugins, themes and ecommerce platforms often produce markup automatically, and much of it is sensible. The risk is overlap and default settings nobody reviewed. Audit what each component outputs, turn off duplicated features, and retest after any theme change or major plugin update, because updates can quietly switch features back on.

Sites built with JavaScript

Google documents that it can process structured data added with JavaScript, but anything that depends on rendering adds a step that can be delayed or fail. Where the framework allows it, markup rendered on the server alongside the visible content removes that dependency and is easier to test.

Redesigns deserve special attention, because they are when markup is most often lost, duplicated or left describing pages that have moved. Any website redesign checklist should include an inventory of current structured data, a mapping of each type to the new templates, and a retest of every template before launch.

If the underlying problem is that content, design and markup live in different places with no shared source, patching the markup will not last. The durable fix is a website rebuilt on a clean content model, where each fact about the business is entered once and every layer of the page reads from it.

Structured data may help some answer engines and AI systems identify entities and read page facts, but whether a page is cited in an AI-generated answer depends mainly on clear, credible, accessible visible content, and no markup guarantees a citation.

Many answer systems work from text they retrieve and read, which means the visible page carries most of the weight. A clear definition near the top, a direct answer under a descriptive heading, and a plainly stated fact are easy for any reader, human or machine, to use. Markup can support that by stating the same entity details consistently, but a page whose visible content is vague will not become quotable because its markup is precise.

The practices that help both search engines and answer engines overlap heavily:

• Answer the question in the first sentence or two of each section, then explain.
• Use headings that describe what the section answers, not clever labels.
• Keep entity details, including name, address, services and profiles, consistent across the site and the profiles you control.
• Show authorship and dates on the page, not only in markup.
• Make sure important pages can be crawled and render their main content reliably.

Understanding how ranking and being cited differ helps set sensible expectations. Ranking is about being chosen from a list of results; being cited is about being the source an answer draws on. Structured data plays a supporting role in both, and a leading role in neither.

Be cautious of any offer that sells schema with promised AI citations. Nobody controls how answer systems choose their sources.

A founder can judge structured data work without reading code by working through a short set of questions about the site, the business facts and the process that will keep them accurate.

1. List templates, not pages. Homepage, service pages, articles, products, locations, about. Markup is designed per template.
2. Name the primary type for each template in one sentence. If the sentence is hard to write, the page’s purpose may be unclear.
3. Point to every claim on screen. For each property described, find where a visitor can see it. Remove anything that cannot be found.
4. Confirm the business facts. Name, logo, address, phone, opening hours and the profiles you actually control, agreed once and used everywhere.
5. Set a review policy. Only genuine reviews displayed on the same page, and no star markup built from testimonials.
6. Remove site-wide blocks that do not belong. Organization described once; page types only on the pages they describe.
7. Ask for both validation results. Schema.org validity for every template, and Google eligibility where a supported feature applies.
8. Agree who updates markup when content changes. The best answer is that nobody has to, because it is generated from content fields.
9. Schedule a recheck after every redesign or platform change. That is when markup breaks most often.
10. Judge the work by accuracy, not promises. Clean reports and truthful descriptions are the deliverable. Rankings and rich results are never guaranteed by anyone honest.

Cost follows scope rather than a list of types. The number of distinct templates, the platform, whether markup can be generated from existing content fields, and how much of the current site’s information is inaccurate or duplicated all drive the effort involved. Fixing the underlying facts often takes longer than writing the markup. For the way we scope that work, see how engagements are priced.

For businesses that want this handled properly, we treat structured data as part of an SEO and AEO engagement rather than a standalone add-on, because the visible content, the site structure and the markup have to agree with one another to be worth anything.

If you would rather start with a first look at how a page presents your business, the free single-page brand audit reviews one page from its URL and is a sensible way to see where the visible layer stands before any markup is discussed.

Get the page right, describe it truthfully, keep the description current, and let search engines decide what to do with it.