Work out what booking information Everwood should make understandable to search engines and AI systems, and what has to stay inside the private part of the product.
I treated it as a build we had not started. We already render on the server, publish structured descriptions, keep a sitemap, and run a considered crawler policy including a file written for AI systems. All of it describes Everwood, and none of it describes a single merchant.
You can be excellent at something and have it pointed entirely at yourself. The gap was never the capability, it was that no merchant has a page of ours to be described on.
The Build
Nothing shipped from this research. No page of ours describes a merchant's services, prices, staff, hours or location to anyone. The roadmap node this came from is planned, and it is still planned.
The goal is easy to state and getting harder to ignore. When somebody types the name of a salon, or asks an assistant where they can get a fade on Thursday near them, the answer comes from whatever the machines can read. If the only description of a business lives inside something that has to run in a browser to appear, the systems doing the answering never see it.
I went in expecting a build estimate. Server rendering, structured descriptions, sitemaps, crawler rules: a decent chunk of work, some of it fiddly, none of it mysterious.
Then I went looking for how much of it we had.
The Problem
We have all of it.
Our own pages are rendered on the server. They carry structured descriptions in the format search engines and AI systems read, naming what we are, what we sell and what it costs. We publish a sitemap. We have a deliberate crawler policy, and it is not a default: somebody wrote out separate rules for the named AI crawlers, noticed those rules were quietly overriding the general ones in a way that could have let them wander into places they should not go, and removed them in favour of one rule that covers everybody. That is a considered decision, written down, about AI crawlers specifically.
We even keep a file on our site written for AI systems to read, describing who we are and which pages matter.
Every piece of it describes Everwood Tech, the company that sells booking software.
Search for a business that has run its bookings through us for a year and there is nothing of ours to find. Not a page, not a line in a sitemap, not a description of a single service or price or opening hour. The apparatus is complete and it is aimed at selling our product.
I do not think this was a mistake. It is what you build when you are trying to get found, and the thing you were trying to get found was the thing you sell. It is still worth sitting with, because the whole premise of a booking platform is that the merchant's business is the product and we are the plumbing, and our search presence says the opposite in some detail.
So why is there nothing for merchants? Not because nobody wrote the structured description. Because there is no page to put it on.
A merchant's booking with us lives in a widget that installs into their own website. It renders in the visitor's browser. There is no page of ours in the middle, which was a deliberate choice and a good one for other reasons, and it means we have never had a surface where a merchant's information could be described to anything.
That connects this node to one I wrote two weeks ago. Build Note #017 was about giving every business one durable booking link, and it ended on the finding that a hosted page cannot be built until we answer what proves a booking request is legitimately for this business when it did not arrive from that business's website. That hosted page is the same page this node needs. Two roadmap items, one missing thing, and the missing thing is a security question rather than a rendering one.
One piece of good news while I was in there. The research spends real length on a failure where a booking vendor's embed script writes into the merchant's page and quietly tells search engines that the merchant's booking page is a copy of the vendor's, which it reports has de-indexed merchant pages. Our widget cannot do that. It never touches the part of the host page where that claim would be made, and I checked rather than assumed. The one page of ours that renders a business's widget needs a token and shows nothing without one, so there is no naked copy of it floating around either. Neither of those is a thing we got right on purpose for this reason, and both are worth knowing before somebody redesigns the widget.
Assumption vs Reality
Search-ready booking is a build. We would need to render pages on the server, learn the structured vocabulary, generate it per business, publish a sitemap that includes merchants, and work out a crawler policy that does not leak anything. Weeks of it, most of it new to us, and the risk is mostly in getting the details of the vocabulary right.
The build is mostly done and pointed the wrong way. What is missing is not skill or machinery. It is a page. That reframes the work from months to something much smaller and much more awkward, because the small thing it depends on is the thing another roadmap node is already stuck on. The research also assumes a shape of product we do not have, and it took me a while to notice because the assumption is buried in its architecture. It spends its length on the choice between two families: a marketplace that lifts merchant data onto the vendor's own domain, and an embed that renders on the merchant's site. It puts us in the second family, warns about the failures of embeds, and recommends we adopt the first family's page as well. That recommendation is bigger than it sounds and it is not a technical decision. Publishing a page that describes a salon, on our domain, with their services and prices on it, makes us a candidate in search results for that salon's own name. The research reports that merchants on marketplace platforms find the marketplace outranking them for their own business. I have not verified that and I believe it, and either way the question it raises is not one an engineer answers. It is what we are for.
The Fix
What changed is the design, not the code. Four things I now believe.
The hosted page comes first and it is not this node's to build. The trust question from Build Note #017 has to be answered before a public page for a business exists, and once that page exists, describing it to machines is a fraction of the work. If I ordered these two nodes by effort I would have them backwards. The right order is trust, then page, then description.
Describe what is stable, keep what moves inside. Services, what they are, roughly what they cost, where the business is, when it is open, who works there if the owner wants that public. All of it changes rarely, none of it is anybody's personal information, and all of it is what somebody asking a question actually wants. Live availability is the opposite on every count. It changes all day, an index is always behind, and a page that lists exactly when a business is empty tells anyone who asks how busy that business is. Whether that matters as much as I think is a guess, and it is cheap to act on because nobody needs it to be public.
It has to be rendered by the server, which rules out the clever version. The obvious shortcut is to have the widget write the description into the merchant's page, on the site where the traffic should land anyway. It does not work, because the readers this feature exists for reportedly take only what the server sent and run nothing, so a description that appears after the browser does some work is invisible to precisely the audience we built it for. It also means writing into a page we do not control, which is the one thing our widget has never done and the reason no merchant has ever had this problem because of us. I would rather keep that record.
The merchant decides what is public, one thing at a time. Prices are the sharp case. We hold a price for each service, and plenty of businesses charge differently depending on who does the work or what the job turns out to be. Publishing a firm number we cannot stand behind is worse than publishing none. Staff names are sharper still, because that is a question about a person, not a setting.
You can be excellent at something and have it pointed entirely at yourself. Everything in the recommended architecture, we can already do. We render on the server. We write structured descriptions. We keep a sitemap and a crawler policy, and we have made a considered decision about AI crawlers and written down why. By any reading of the research, we are ahead. None of it reaches a customer, because all of it describes the company rather than the businesses the company exists to serve. That is not a technical gap and no audit of our capabilities would have found it. Every individual thing passes. The general version, and it is uncomfortable. When you already have a capability, check who it currently serves before estimating what it would take to build. The gap is often not the capability. It is that nobody ever pointed it at the customer, and the reason is usually a missing surface rather than a missing skill.
For a salon owner, here is the honest position. If somebody searches for your business, or asks an assistant where to book something you offer, nothing we run helps them find you. We do not publish a page about you. Your services, prices and hours are not described anywhere a search engine or an AI assistant can read them. Your booking works, and it is invisible to the machines people increasingly ask first. Your own website is doing that job alone. The booking widget on it appears when the visitor's browser draws it, and the reports I have say the AI systems answering questions do not wait for that. They read what your website's server sends and move on. So the widget is for your customers, not for the things indexing you, and I would rather say that plainly than let it sound like installing us helped you get found. What I am not going to do is start publishing pages about your business on our website without talking to you about it first. There is a real prize in it, and there is a real catch. A page of ours describing your salon is a page that competes with your own for your own name. Some owners will want that, especially if they have no website. Others will not, and both are reasonable, and it is your call rather than a setting we flip on. One thing I can tell you is safe: nothing about your live availability would ever go into a public page. When you are free changes all day, anything published about it is out of date immediately, and a permanent list of your empty afternoons tells anyone who cares exactly how busy you are. That stays where it is.
Builder Notes
A research pass on making booking readable to search engines and AI systems that turned into an audit of what we already publish. Nothing was built. No page of ours describes any merchant.
Technical Note 1
Shipped today, and the surprise of this research: our own pages are rendered on the server and carry structured descriptions naming us as an organisation, a website and a software product, with our own pricing attached. Guides and breadcrumb trails carry their own descriptions too. The machinery is complete and in production.
Technical Note 2
Also shipped: a sitemap, and every entry in it is one of our own pages. Marketing, guides, solutions, these build notes. No merchant appears anywhere in it.
Technical Note 3
Also shipped: a crawler policy that is one deliberate rule rather than a default. Separate rules for the named AI crawlers existed and were removed, because they were overriding the general rule without carrying its restrictions forward, which could have let those crawlers reach places that should never be indexed. That is the kind of decision I want to see recorded, and it is recorded.
Technical Note 4
Also shipped: a file on our site written specifically for AI systems, describing who we are, our canonical address, and the pages that matter. For us.
Technical Note 5
Missing entirely: any public description of a merchant. The only places a merchant's services and prices are rendered at all are behind our admin login, and on a page a customer reaches with a one-time token. Neither is public and neither should be.
Technical Note 6
The reason is a missing surface, not missing work. There is no Everwood-hosted page for a business, because booking happens inside a widget on the merchant's own site. Build Note #017 found that the hosted page cannot be built until the trust question behind it is answered. This node inherits that dependency whole.
Technical Note 7
Verified non-risk, worth recording because a redesign could lose it: our widget never touches the host page's head and never writes a canonical claim into it. The research describes a vendor whose embed did exactly that and reportedly de-indexed merchant pages. We are not exposed, and we are not exposed by luck rather than by having considered this particular hazard.
Technical Note 8
Second verified non-risk: the one page of ours that renders a business's widget is gated by a token and returns not-found without one. So the research's advice to keep the naked widget page out of the index is already satisfied, by a mechanism built for a different reason.
Technical Note 9
Reported and not verified, and load-bearing for the whole design: that AI crawlers do not run client-side code and take only what the server sent. If that is wrong, or stops being true, the argument for server rendering weakens considerably and the structured description still matters. I am designing for it being right because the cost of being wrong that way is low.
Technical Note 10
Also reported and not verified: that merchants on marketplace platforms find the marketplace outranking them for their own name. That is the sharpest product question in this node and it arrived with no source.
Technical Note 11
Reported as a general direction: that a page gets a limited budget from the things fetching it, so anything that only appears after slow work in the browser may never be seen. The specific limits the research quoted carried no source and are cut.
Technical Note 12
A guess of mine, not a finding: that publishing live open time slots would be both useless and unwise. Useless because an index updates far slower than a calendar. Unwise because a permanent public record of when a business is empty is a utilisation report for anybody who wants one. Nobody has to decide this now, which is the nice thing about it.
Technical Note 13
Cut from the research and kept in the ledger: the response size limit, the render timeout, the AI extraction success rates, the count of fetch requests behind the crawler claim, two named vulnerability identifiers, the nine-platform capability matrix with its per-vendor ratings, and the specific vocabulary, booking API and diagnostic endpoint names. Not one arrived with a source I could open.
Technical Note 14
Fifth time: the research came back with a finished public article attached, written as though search-ready booking already exists at Everwood.
Before / After
- Search-ready booking is a build we have not started
- The work is server rendering and learning the vocabulary
- The widget is our public surface
- This node is independent of the other booking work
- The question is what to publish
- Search-ready booking is a capability we have, aimed at ourselves
- The work is having a page for a merchant to be described on
- The widget is a private surface that machines cannot read
- This node waits on the trust question from Build Note #017
- The question is whether we should be the page at all
What I'd Do Differently
I would have checked who our existing search work serves before estimating the work to serve merchants.
I asked what it would take to become search-ready and got a careful architecture for becoming something we already are. Every recommendation in it describes a capability in production on our own site. The gap was never the capability, and I could have found that in twenty minutes by looking at our own sitemap and asking whose pages were in it.
The general version, and it keeps arriving in different costumes. Research about extending what you already run is only as good as the description of what you run, and I am the only one who can supply it. This time the thing I failed to supply was not a constraint. It was a strength I had forgotten we had.