Structured data is code with a fixed vocabulary, which makes it well suited to generation. It is also a set of definite statements about your business, which makes an invented value more dangerous here than anywhere else on a site.
Short answer
A tool can produce syntactically correct structured data quickly, which is genuinely useful. Every value in it still has to be checked by a person, because markup states facts definitely rather than in hedged prose. The commonest failures are invented fields, markup describing content visitors cannot see, and code that drifts from the page.
The vocabulary is published, the syntax is strict, and correct examples are plentiful. That combination is close to ideal for a tool, and the output is usually valid on the first attempt.
It also removes the part people find tedious. Nesting, required fields and correct type names are fiddly by hand and consume an hour that a small business owner would rather spend elsewhere.
Our page on schema markup covers what the vocabulary is for. This page is about the specific risks of producing it with a tool rather than by hand.
Prose can be vague. Markup cannot. A field holds a value, and whatever it holds is read as a definite statement about your business by anything that reads the page.
A tool asked to produce business markup will fill fields it has no information for. Founding years, price ranges, area served and rating values all get plausible defaults unless somebody notices and removes them.
That is the single most important check. Read every value as a sentence about your business and ask whether it is true. Anything you cannot confirm should be deleted rather than adjusted.
Validity is the floor, not the finish. A validator confirms the syntax and the required fields. It cannot tell you that the address is last year's or that the rating value describes reviews nobody left.
Markup that contradicts the visible page is worse than no markup, because the contradiction itself is a signal and it is not a good one. Systems read both, and the disagreement is easy to detect.
Generated markup is especially prone to this, because it is produced in one pass and then never revisited while the page beneath it changes. Prices move, hours change, and the code keeps stating the old values.
The durable fix is to generate the markup from the same source as the content, so drift is impossible. Where that is not available, tie the code to the same review cycle as the page it describes.
Anything describing credentials, ratings, prices or area served. These are the same items on the never list from our page on what to keep off, and putting them in code does not change that.
Review and rating fields are the sharpest case. Marking up ratings that are invented, borrowed or hidden is a policy violation and a consumer protection risk. Nothing here is legal advice.
Identity fields matter too. Our page on entity clarity covers why the business name and location have to be stated identically everywhere, including inside markup.
Keep one block per page rather than fragments scattered through the markup. It is easier to read, easier to check and far easier to correct when something about the business changes.
Document which pages carry which types, in a file somebody maintains. Without that record, a site quietly ends up with three different descriptions of the same business in three places.
Re-check after any redesign. Template changes routinely leave markup describing a page shape that no longer exists, and nothing at all will tell you that it happened.
Less than a generator will offer. The organization or local business once, the service or product on its own page, questions where a real set exists, and steps where a real procedure exists.
Every additional type is something to maintain and something that can become false. Stale markup is worse than absent markup, and the maintenance burden is the reason to be conservative.
Our page on structured data for answer engines covers which types actually earn their keep on a small business site.
The syntax usually is. The values often are not, because a tool will fill fields it has no information for. Read every value as a statement about your business and delete anything you cannot confirm.
Only that the syntax is valid and required fields are present. A validator cannot tell whether the address is current, whether the rating is real, or whether the hours match the ones on the page.
Invented fields. Founding years, price ranges, areas served and rating values get plausible defaults unless somebody removes them. Each one is a definite false statement about the business in a format built to be trusted.
It should not. Describing content a visitor cannot see is a policy problem and can lead to features being withdrawn. Mark up what is on the page, and put on the page what you want marked up.
15-day free trial. Card required. Cancel before day 15 and you pay nothing.