Schema markup for a company site, in plain language

Schema markup is a structured description of a page, written so a machine can name the same things a person sees. It sits beside the writing. It does not stand in for the writing.

For schema markup for business website work, three types cover almost everything a small company needs. Describe the organization on the homepage. Describe an article on each post. Describe questions only when those questions are visible on the page.

What you are describing

A company site is a set of claims: who you are, what you offer, which questions you answer, and which pieces you have published. Schema repeats those claims in a predictable shape. Search engines and other consumers may use that shape. They still have to read the page. If the page is vague, a precise block of JSON-LD will not make it specific.

Think of the markup as a label on a box. The label should match the contents. Organization markup on a page that never says the company's name is a label for a different box. Article markup on a page with no author and no date describes a publishing habit you do not have. FAQ markup on a page with no questions describes a conversation that is not there.

Add the label after the page is true. Then keep the two in the same edit. When the visible email changes, the markup changes. When a post is renamed, the headline in the data changes. Drift between the screen and the script is how structured data becomes fiction.

Organization on the company homepage

The homepage is the right place for a description of the studio or the company. The useful fields are the ones a stranger can check: the name, the site URL, a logo, an email, and the public profiles you actually operate. Hanabi's public profiles are the LinkedIn company page and the Instagram account. Those are the kind of links that belong in sameAs, because they are the same entity, not a random mention.

Use one description. If the visible sentence says the studio designs and builds websites and product interfaces for founders, the markup should not say something broader or cuter. Consistency is the point. A second, fancier summary in the script is a second story.

ProfessionalService is a reasonable alternative when you want the type to say "this is a practice people hire," and Organization is the broader type. Pick one and use it on the canonical homepage. Repeating it on every URL adds noise. Inner pages can refer to the organization; they do not each need a full biography.

Leave off fields you cannot stand behind. A founding date, a headcount, or a service area you invented to look complete will outlive the brainstorm that produced it. Empty is better than false.

Questions, only when they are on the page

Schema.org defines an FAQPage as a web page that presents one or more frequently asked questions. The type is a kind of page. The questions are the subject of that page. Markup it when a visitor can read those questions and the answers without guessing that a hidden block exists.

That rules out a common shortcut: pasting questions into JSON-LD that the design never shows. It also rules out marking up a page of headings that merely end with question marks, when the page is not a set of answers. If you want the type, publish the FAQ. Four to six real questions on a homepage is a solid set. Three at the end of an article is enough for a post.

Keep each answer self-contained. A machine that lifts one answer should get the recommendation and the condition, not a fragment that depends on the previous heading. The visible paragraph and the acceptedAnswer text should match. If legal review trims the visible answer, trim the markup in the same commit.

Hanabi's articles show their FAQs but emit article and breadcrumb schema, not FAQ schema. Google retired FAQ rich results, so the visible answers matter more than adding that markup. The order of operations is the writing first. The schema follows the writing onto the page.

A fuller note on which questions deserve that treatment is FAQ sections that help buyers and search engines. Read that before you generate a long list from a keyword tool.

Articles, authors, and dates

A post wants Article or BlogPosting data: a headline, a date, an author, a description, and a hero image with a URL. The author should be a real byline. Google's helpful-content guidance treats "who created this" as part of how people judge trust. A studio byline is honest when the studio wrote the piece and a reader can see that name on the page. A fictional person is not a shortcut to trust.

The date is the publish date, updated when the piece actually changes. Changing the date because you heard that freshness is a ranking trick is the kind of behavior that guidance warns against. Update the date when you update the advice.

The description in the markup should be the same excerpt a person might see in a snippet. One summary, used in the page and in the data, is easier to keep true. Canonical URLs belong here only when they repeat the real canonical of the page. An override that points at a different story is how duplicates start.

Breadcrumbs, if you show them, can be marked up because they are visible. A breadcrumb trail that exists only in the script is another label without a box.

Writing still does the work

Structured data will not rescue a homepage that never says what the company does. It will not choose your title for you, though a clear title and a clear H1 give every consumer, human or not, the same handle on the page. It will not invent proof. Project names, offers, and answers still have to be written in sentences.

Use a small set and review it when the site changes:

• Organization or ProfessionalService on the homepage, matching the visible name, URL, and profiles.
• Article or BlogPosting on each post, with a real author, date, and image.
• FAQPage only where the questions and answers are on the screen.
• No markup for claims the page does not make.

Validate the JSON when you template it. A missing comma is a quiet failure. A wrong URL is a louder one, because it describes a page you do not mean. Check a homepage and a post after any change to the layout, since templates are where old fields linger.

If you are putting this in place while the marketing site is being built, the copy and the schema should land together. Hanabi's services are the kind of plain offer a homepage description can repeat without embellishment: design and production for founders, stated once, then marked up to match.