Pick a slash convention, then go read your schema

A trailing slash is the / at the end of a URL, and the only rule that matters is that your site picks one form and every reference to a page agrees with it. /services and /services/ are one page at two addresses. Neither is better. Being inconsistent is worse than either.

Most site owners make this decision once, usually by accident, when a platform default is chosen for them. The decision itself is fine. What goes wrong is the sweep afterward.

Five places a URL lives

Write the list down, because the discipline is in the list, not in the choice:

1. The build configuration — whatever your platform calls it, this is what decides which form actually gets served.
2. The canonical tag — the page’s own statement about its real address.
3. The sitemap — the list you hand search engines directly.
4. Internal links — every link from one of your pages to another.
5. Structured data — the url, @id and item values inside your JSON-LD.

Change a convention and the first four get updated, because they are the four you can see. The fifth is inside script tags nobody reads for pleasure, and it survives the migration untouched.

Why the fifth one is the one that gets missed

Because it does not break.

A structured-data URL pointing at the old form still resolves — the redirect fires, the machine follows it, no error appears anywhere. Your rich-result test passes. Your links all work. The only symptom is that the page hands a reader two different addresses for itself in the same breath: one in the canonical tag, one in the schema. It is the kind of contradiction that costs you nothing you can point at and gains you nothing either.

We ran this check across our own site on 17 August 2026 and found 95 url, @id and item values across 22 pages still written in the form the site had stopped serving. The configuration, the canonical and the sitemap had all been correct since the day the convention was set. The schema had simply never been part of the sweep.

Grep the built site, not the source

The reason that count went unnoticed for weeks is worth more than the count.

A search of the source code came back clean three times, because the URLs were not written in the source as text. They were assembled by one line in a template — a base address plus a variable — and a text search cannot match a string that does not exist until the page is built. The same trap catches quote styles: a pattern written for double quotes walks straight past the identical value in single quotes.

So do it the other way around. Build the site, then search the built output, where every template has already become a literal string. That is the only place the whole truth about your URLs exists. If you are working with a developer, this is a two-minute ask, phrased exactly like that.

What to do if yours are wrong

Fix them at the template, not at the page. If 95 URLs are wrong across 22 pages and one line generated all of them, then one line is the fix and 22 hand-edits are 22 opportunities to introduce a typo. Then rebuild and search again — the second search is not optional, because the first fix rarely catches every shape.

None of this is urgent. It belongs in the same category as schema markup generally: worth doing correctly, not worth losing a weekend to, and much easier to keep right than to make right later.

And if you are reading this wondering whether you even need a site to do local search properly, that is a separate question with a real answer.

Technical tidiness like this is not what wins the map pack — the profile is. If you would rather someone kept that side right every month, the plans are on the services page.