Schema markup is the part of your website that search engines read and visitors never see. It is a short block of structured data that says, in plain facts, what your business is, where it is, and what each page contains.
You can add it this week. The risk is not adding it. The risk is adding it badly, so that page one says one thing and page forty says another.
What is schema markup, and what does it tell Google about your business?
Think of it as a label on the box. Your visible page is written for people. The markup is written for software, and it removes the guessing.
Without it, Google infers that you are a plumber, that the address in the footer is your address, and that the number near the top is a phone number. Usually it infers correctly. Sometimes it does not.
With it, you state the facts directly:
- Your business name and type
- Your address, phone number and hours
- The areas you serve
- What a given page is, such as a blog post or a list of questions
Markup does not make a weak site rank. It makes a clear site unambiguous. That is worth an afternoon.
Which facts should the markup state, and where should they come from?
Start with a short list of facts, and write them down once before touching any code.
- Legal or trading name, exactly as customers know it
- Street address, phone and email
- Opening hours
- Year founded
- Service area, by town
- Your review rating and the number of reviews behind it
Now decide where each fact lives. Not in the markup. In one source: a settings file, a database record, a single page in your content system. The markup reads from it, and so does your footer, your contact page and your about page.
If the same phone number is typed by hand in nine places, you will have nine versions within a year. That is not a theory. That is how small business sites age.
Why should the business be described once instead of on every page?
Because a page that describes the business a little differently each time is not helping. It is arguing with itself.
Imagine the homepage says you were founded in 2010, a service page says 2011, and the contact page lists an old suite number. Google has to pick. Sometimes it picks wrong.
The fix is simple. Describe the business in full on one page, usually the homepage, and give that description a stable identity. Every other page then refers back to it rather than restating it. Blog posts say "published by that business." Service pages say "offered by that business."
This is the approach behind the cleanup on A New Leaf Painting. One business, described once. Hundreds of pages, none of them retelling the story in their own words.
How do you add breadcrumbs and article markup to blog posts?
These are the two pieces most small sites skip, and they are the easiest to get right because they follow a pattern.
Breadcrumbs show where a page sits: Home, then Blog, then this post. Add breadcrumb markup to every page, not just the blog. The trail in the markup should match the trail a visitor could follow.
Article markup tells search that a page is a post, and gives it a headline, a publish date, an author and the business behind it. Add it to every post, not just the recent ones.
Two habits keep this clean:
- Generate both from the page itself, so the headline in the markup is the headline on screen.
- Apply them through your template, not post by post. If you add them by hand, post 200 will be missing them.
If your site runs on a common CMS, an SEO plugin may handle much of this. Check what it outputs before you trust it.
How do you mark up a FAQ so search can answer directly?
A FAQ is the friendliest place to start, because the content already exists in the shape search wants: a question, then an answer.
Moore Prep, a one-teacher tutoring practice in Wake Forest, has a parent FAQ. It is marked up as structured data so local search can answer parents directly. A parent searching late at night can get a straight answer without hunting for it.
The rules are short:
- Mark up only questions that are actually on the page, word for word
- Keep the answers in the markup the same as the answers on screen
- Write for the questions your customers really ask, not the ones you wish they asked
- Skip the FAQ markup if the page has no FAQ
Do not stuff a list of questions into the markup that visitors cannot see. That is how a helpful feature becomes a problem.
Why must the review rating in markup match what the page shows?
If your markup says 4.9 stars and the page says 4.7, you have a mismatch, and a mismatch is the quickest way to lose trust with a search engine.
It happens naturally. Someone types a rating into the page in March. A plugin pulls another figure in June. The markup keeps a third from whenever it was set up.
The cure is the same cure as everything else here. One source. The review rating and count live in a single place. The visible badge reads from it. The markup reads from it. Nobody types the number anywhere else.
A New Leaf brought reviews from Google, Facebook, Houzz and Yelp onto one page and made the review figure come from one place, so every page and its search markup agree. That is the standard to copy, even if you only have one review site.
How do you test the markup before and after you publish?
Test twice. Once on a draft, and once on the live page.
- Before publishing: paste the page code or a staging address into Google's Rich Results Test. It shows what Google can read and flags errors.
- Also check the plain facts: the Schema Markup Validator at schema.org confirms the structure is valid, even for types that earn no special display in search.
- After publishing: test the live address of a sample of pages. Pick the homepage, one service page, one blog post and the FAQ.
- Read it like a customer: compare the name, phone, hours and rating in the markup to the page. They should match to the character.
- Watch Search Console: it reports markup problems across the whole site, over time.
Put a reminder in your calendar to repeat this after any redesign, plugin update or platform move. Which brings us to a cautionary tale.
What went wrong on the A New Leaf blog, and how was it restored?
A New Leaf Painting Contractors has painted homes and businesses across Jacksonville and Northeast Florida since 2010. Its site had hundreds of blog posts and paint guides. Then it moved to a new platform, and the move went badly.
Among the damage, the blog had lost the markup that tells Google what a post is. Nobody noticed by looking at it, because the pages looked fine. Markup is invisible. That is exactly why it breaks quietly.
The restoration was the plan in this post, applied at scale:
- One business described once
- Breadcrumbs on every page
- Article markup on every post
- The review figure from a single source
Business facts, from the founding year to the insurance limit, also come from one source, so hundreds of pages cannot drift apart. If you want the full story of that migration, the case study covers it.
A one-week plan for adding markup to a small business site
You do not need a developer for every step, but you will want one for the template work. Here is a week that fits around running a business.
- Monday: write down your business facts and pick the single source for each. Check them against your Google Business Profile.
- Tuesday: add the business description once, on the homepage, using that source.
- Wednesday: add breadcrumb markup site-wide and article markup to the blog template.
- Thursday: mark up your FAQ, using only visible questions and answers. If you have a rating, wire it to one source.
- Friday: test a sample of pages with the Rich Results Test, fix what it flags, publish.
- The following week: re-test the live pages and check Search Console.
If that feels like a lot, our SEO and analytics work covers exactly this. If you would rather see how a practice like Moore Prep handled it, start there.
Your next step today: open your homepage, your contact page and your footer, and check that the phone number is the same on all three. If it is not, you have found your first fix.