# Altaris - full text > Custom websites for US local service businesses. Paid once, not monthly, no commission. Web studio building fast, bookable websites for local service businesses across the United States - restaurants and cafes, hotels and short-stay, security and CCTV, chauffeur and close protection, and auto services. Paid for once rather than monthly, with commission-free online ordering and reservations. This file carries the full text of every sector, service, case study, guide and comparison page, including their FAQs. It does not reproduce the standalone pages - home, about, pricing, no-monthly-fees, contact, privacy and terms - whose substance is in the commercial terms and the note on claims at the end of this file. /llms.txt is the shorter index if you only need one answer per page. Contact: hello@altarisdev.com Enquiries: https://altarisdev.com/contact/ --- # Sectors ## Auto services URL: https://altarisdev.com/for/auto-services/ We build custom websites for auto repair shops, alloy wheel specialists, detailers and tire fitters across the United States. Each one is fast, works on a phone in a parking lot, and is structured so Google can read your services, hours and reviews. You pay for it once, with no monthly platform fee and no commission on the work it brings in. ### Why one services page is not enough Diamond cutting, powder coating, refurbishment, crack repair, tire fitting: these are separate jobs at separate prices, and people search for them by name. A single page that lists all of them has one title, one description and one set of structured data to spend, so it competes properly for none of them. Giving each job its own page means each one can carry its own `Service` markup, its own FAQ answers, and internal links from the pages that relate to it. ### The quote has to work in a parking lot Most of your enquiries arrive from a phone, often while someone is standing next to the car looking at the damage. So the quote path is built for that: a short form, large tap targets, the option to attach a photo, and a phone number that dials with one tap. ### What search engines need to be told We mark up the shop as an `AutoRepair` business with its real opening hours, the service areas you genuinely cover, your service catalog, and your reviews with their aggregate rating. Those are the fields that decide whether your listing shows stars and hours or just a blue link. ### Questions **How long does an auto shop website take to build?** Most shops are live in two to three weeks from the kick-off call. That covers a home page, a service page for each job type you want to rank for, a quote form, and the structured data that gets your hours and reviews into search results. **Will it bring in more quote requests?** That depends on your market and what you have today, so we will not promise a number. What we control is the parts that reliably matter: a page per service that can rank, a quote form that takes seconds on a phone, and a site fast enough that people do not leave before it loads. **Do I need a separate page for every service?** If you want to rank for those services, yes. A single page listing diamond cutting, powder coating and refurbishment competes for none of them properly. Separate pages each get their own title, structured data and internal links, and each can win its own search. **What happens if I want to leave?** There is no contract to exit and nothing recurring to cancel, because you were never on a plan. What there also is not is a copy of the site to take with you - we host and run what we build, so moving to another developer means a rebuild. Worth knowing before you start rather than after. --- ## Hotels & short-stay URL: https://altarisdev.com/for/hotels-and-short-stay/ We build websites for boutique hotels, aparthotels and serviced apartments that are designed to win the direct booking instead of handing it to an online travel agency. Rooms, rates and availability are marked up so search engines can read them, the booking path is short, and the site is fast enough to hold someone who is comparing four tabs. ### The direct booking is the whole point Every room night sold through an online travel agency carries commission, and the guest stays the agency's customer rather than yours. A direct-booking site cannot make the agencies disappear, but it can make booking with you the obvious and easier option for anyone who has already found you. That means a short booking path, honest rates shown without a hunt, and enough detail on the page that nobody needs to open a second tab to decide. ### Room pages, not a room table Guests search for a studio, a one-bedroom, somewhere that sleeps four. A table of room types on one page cannot rank for any of those. Each room type gets its own page with its own photography, rates and amenities, and its own `HotelRoom`, `Offer` and `BedDetails` structured data. Those room pages reference the parent property by `@id` rather than restating the address and phone number, so your details are declared once and cannot drift out of sync. ### Questions **Can it work with the booking engine we already use?** Yes. The site is built around whatever engine you are on rather than replacing it, so your rates, availability and payments stay where your team already manages them. If you have no engine yet, the site can take enquiries and deposits while you decide. **Will this reduce what we pay the OTAs?** It can only help if guests can find and finish a direct booking easily, which is exactly what the build targets. We cannot promise a percentage, because that depends on your mix and your rates. What we can do is remove the friction that sends people back to the OTA. **Do you handle photography?** We do not shoot it, but we will tell you exactly what shots the layout needs and at what sizes, and we will optimize whatever you have. Good room photography moves direct bookings more than almost anything else on the page. **How many pages does a small hotel need?** Usually a home page, one page per room type, a location page, and a short page each for amenities and policies. Room pages matter most, because they are what people search for and what carries the structured data. --- ## Security & CCTV URL: https://altarisdev.com/for/security-and-cctv/ We build websites for CCTV, alarm, access control and monitoring installers across the United States. Each service gets its own page so it can rank on its own terms, the structured data tells search engines what you install and where you work, and the quote path is short enough that a facilities manager will finish it on the first visit. ### A page per service, because that is how people search CCTV installation, access control, alarm systems, monitoring and maintenance are distinct searches with distinct intent. Each gets a page that can rank on its own, carrying its own `Service` markup and its own FAQ answers to the questions that actually come up on those calls. ### Certifications where buyers look for them Licensing and accreditations are often the strongest trust signal a security business has, and most installer sites bury them in the footer. We put them in the page copy, near the decision, and into the structured data where there is a field for them. ### Questions **Why does each service need its own page?** Because a facilities manager searching for access control installation will not land on a page that mentions it in a list of eight things. A dedicated page carries its own title, its own structured data and its own internal links, so it can rank for that search and speak only to that buyer. **Can you show the areas we cover without faking an office?** Yes, and this matters. Service areas go into the structured data as the regions you genuinely serve, and the pages say so plainly. Inventing addresses to game local search breaks Google's guidelines and tends to get the listing pulled. **Do you work with residential or commercial installers?** Both, but they need different pages. Residential buyers want reassurance and a price range; commercial buyers want specifications, certifications and a named contact. Trying to serve both with one page usually converts neither. **What about certifications and accreditations?** They go front and center, and into the structured data where there is a field for them. For security work these are often the single strongest trust signal you have, and most installer sites bury them in a footer. --- ## Restaurants & cafes URL: https://altarisdev.com/for/restaurants-and-cafes/ We build custom websites for restaurants and cafes where the menu is structured data rather than a photograph, and bookings run through your own payment account instead of a marketplace taking a cut per cover. You pay once for the build. No monthly platform fee, no commission on orders, and no plan to keep renewing. ### 94% of restaurant sites get this wrong We audited 190 US restaurant websites and [94% publish no menu a machine can read](/guides/restaurant-structured-data-study/). 91% never even declare that they are a restaurant rather than a generic business. The bar in this sector is extremely low, which is the opportunity. ### The menu is the most valuable thing on the site It is also the thing most often thrown away. A menu published as a photograph or a PDF is opaque: no search engine can read a dish, a price or a dietary note, and no assistant can recommend you to somebody asking what to eat nearby. We build menus as structured data. Each dish is a `MenuItem` inside a `MenuSection` with its own `Offer` and price, which is why [Villas Cafe](/work/villas-cafe/) can be read item by item by anything that comes looking. ### Bookings and orders that do not pay a toll A reservation taken through a marketplace costs you per cover and hands the diner relationship to somebody else. An order taken through a platform costs you a percentage forever. Both can run on your own site and your own payment account instead. [Enos Restaurant](/work/enos-restaurant/) takes bookings through a reservation API on its own infrastructure, marked up as a `ReserveAction` so search engines understand the page offers something you can act on. ### Restaurants are the hardest market, and we will say so The search results for restaurant websites are owned by funded software companies with marketing budgets we do not have. We are not going to pretend otherwise. What we offer is narrower and clearer: a faster site, a menu that is readable, ordering that takes no cut, and no monthly bill for any of it. ### Questions **How is this different from BentoBox or Popmenu?** Those are subscriptions, typically $179 to $499 a month, and the site lives on their platform. This is a one-time build that costs nothing per month to run afterwards. We have written a page on each of them, including the cases where buying theirs is the better decision - they are at /compare/. **Can my menu appear in Google search results?** It can if the menu is marked up as data rather than published as a picture or a PDF. We put every dish in as a MenuItem inside a MenuSection, each with its own Offer and price. That is what makes a menu readable by a search engine, and increasingly by an assistant somebody is asking where to eat. **Do I have to leave my delivery apps?** No, and most restaurants should not. The apps bring customers who were never going to find you otherwise. The argument is about your direct orders, where paying a commission to a platform for a customer who already knows your name is money given away for nothing. --- ## Takeaways URL: https://altarisdev.com/for/takeaways/ We build takeaway websites around the search that actually brings customers in - the dish and the town together, not the brand name. Each build carries Restaurant structured data, a landing page per area worth competing for, and ordering that runs on your own payment account so no platform takes a cut of every order. ### Nobody searches for your brand name Not until they already know you. A new customer types the food and the town, and the results they get are decided by which businesses bothered to build a page for exactly that phrase. [Brothers Fish & Chips](/work/brothers-fish-chips/) has one, separate from its home page, with its own title, its own copy and its own structured data. That is the whole trick, and most takeaway sites skip it because a template does not encourage it. ### The commission question A delivery platform taking 15 to 30 percent of an order is reasonable value for a customer who found you through them. It is a poor deal for a regular who knows your number by heart and used the app because it was the easiest route. Direct ordering on your own site does not replace the apps. It gives the second group somewhere else to go. ### The simplest thing that works A takeaway site does not need a build pipeline, a framework or a content management system that somebody has to log into. Brothers is six hand-written HTML files with no build step, which means nothing to upgrade and nothing to break. ### Questions **Will a website get me off the delivery apps?** Not entirely, and anyone promising that is overselling. The apps reach people who would never have found you. What a direct ordering path does is stop you paying a commission on the customers who already know your name and would have ordered from you anyway - which is usually the larger share of regulars. **What does commission-free ordering actually mean?** Orders arrive through your own site and the money settles into your own payment account. Your card processor takes their standard rate, the same as on the card machine in the shop, and nobody else takes anything. There is no per-order fee and no percentage. **Why does a separate page per area matter?** Because people search for the food and the place together, and a page can only properly compete for one such phrase. A single page mentioning six towns competes weakly for all six. A page written for one of them, with its own title, copy and structured data, competes properly for that one. --- ## Chauffeur & close protection URL: https://altarisdev.com/for/chauffeur-and-close-protection/ We build websites for chauffeur, executive transport and close protection companies, where the buyer is cautious, the purchase is discreet and credibility has to be established before anyone makes contact. Each service gets its own page and its own structured data, and the whole thing is paid for once, with no monthly platform fee. ### A cautious buyer decides before they call Nobody enquires about close protection casually. By the time somebody makes contact they have already read the site, formed a view about whether the firm is serious, and decided whether giving their name feels safe. Every one of those judgements happens before you know they exist. So the site has to do the work unattended: specific about services, clear about coverage, and free of the things that make a cautious person close the tab. ### No tracking, and that is a feature [Central Security Chauffeurs](/work/central-security-chauffeurs/) ships no third-party analytics and no advertising scripts. There is no consent banner because there is nothing to consent to, and no record of the visit leaves the site. In most sectors that is a performance decision. Here it is what the client expects, and the fact that it also makes the site faster is a bonus rather than the point. ### Questions **Should a close protection firm publish prices?** Usually not, and this is the one place we argue against publishing them. The work varies too much for a figure to be meaningful, and a published rate invites the wrong enquiries. What does help is being specific about what a quote depends on, so a serious client can tell whether to call. **How do you handle discretion and privacy?** By default we ship no third-party tracking, which means no consent banner, nothing loaded from an advertising network, and no record of a visit leaving your site. For this sector that is not a performance decision, it is a client expectation. **Why separate pages for each service?** Because airport transfers, corporate accounts, event transport and close protection are different searches made by different people with different budgets. One page covering all four has a single title and a single set of structured data to spend, and ends up competing properly for none of them. --- # Services ## Websites ($1,500) URL: https://altarisdev.com/services/websites/ A custom website is $1,500 for a small site or $3,000 for a multi-page site with a page per service. You pay once, for the work of building it, and nothing after that - no monthly fee, no commission on anything you sell, and no charge for the small changes you will want in the first month. We host it and keep it running as part of the service. Explicitly not for: - Anything needing customer accounts, memberships or logged-in state. That is software, and we would tell you so rather than build a worse version of it. - Businesses whose budget is under a thousand dollars. A builder subscription is the right tool at that budget and we will say so on the call. ### What you actually receive A finished site, built for your business rather than selected from a library, and then run for you. We handle the hosting, the certificate, the deployment and the small changes. There is no dashboard to learn and no account to administer. What you are not buying is a subscription. The price is for the work, the work happens once, and afterwards the invoices stop. ### What gets built A page for each thing you sell, because a single services page has one title and one set of structured data to spend and ends up competing properly for nothing. A linked JSON-LD graph on every page describing your business, services, hours and FAQs. A contact or quote path that works one-handed on a phone. And nothing else: no carousel nobody scrolls, no chat widget, no popup. ### How it runs One to three weeks. A fixed price agreed before anything starts, so there is no hourly meter and no scope conversation halfway through. You see it on a staging URL before it goes live, and after launch you email us for changes rather than logging in anywhere - we host and run it for you. ### Where this is the wrong purchase If you need customer accounts, memberships, or anything with logged-in state, you need software rather than a website, and we will say so rather than build a weaker version of it. If your budget is under a thousand dollars, a builder subscription is genuinely the better tool - the [Wix comparison](/compare/wix-alternative/) works through why. ### Questions **How long does it take?** About a week for a small site, two to three for a multi-page one, measured from the kick-off call rather than from when you first enquired. The usual cause of delay is photography, so we will tell you exactly which shots the layout needs before you book a photographer. **What do you need from me?** Your services and prices, any photography you already have, and access to the domain and existing site if there is one. If a page needs copy we will draft it and you correct it, which is faster for everyone than asking you to write from a blank page. **What happens after launch?** It costs you nothing per month. We host it, keep it online, and do small changes - wording, prices, a new photo - free of charge when you email us. Anything larger is quoted per job, and an optional care plan is available if you would rather have us on call with agreed response times. --- ## Online ordering (Quoted) URL: https://altarisdev.com/services/online-ordering/ Online ordering built into your own site, settling into your own payment account. Your card processor takes their standard rate, exactly as they do on the terminal in the shop, and nobody else takes anything - no per-order fee and no percentage to a platform. It does not replace the delivery apps, and it is not meant to. Explicitly not for: - Replacing the delivery apps. They reach people who would never have found you, and we are not going to pretend a website changes that. - Businesses with no existing regulars. Direct ordering captures demand you already have; it does not create it. - Complex inventory, modifiers across hundreds of items, or multi-location stock. At that scale you want a dedicated platform. ### Where the money goes A platform ordering system sits between you and your customer and takes a cut of everything that passes through. A commission of 15 to 30 percent on a $40 order is $6 to $12, on a customer who typed your name into a search box. Direct ordering removes the intermediary rather than negotiating with it. The order arrives on your site, the payment settles into your account, and the only deduction is the card fee you already pay on every transaction in the building. ### Making the ordering path readable An ordering form is invisible to a search engine unless you describe it. We mark the path up as an `OrderAction` with a typed entry point and a delivery method, which is the vocabulary assistants use when deciding whether a business can actually take an order. The [booking and ordering guide](/guides/booking-and-ordering-schema/) has the working markup. The menu gets the same treatment - every item as a `MenuItem` with its own price - so what you sell is legible as well as orderable. ### Be clear about what this is not It is not a delivery network. If you do not have drivers, this gives you collection orders and whatever delivery arrangement you already run. It is not a demand-generation machine either: it captures orders from people who already know you, which is the point, but it will not find you new customers on its own. And at genuine scale - hundreds of items with modifier trees, or stock shared across locations - a dedicated platform is the right answer and we will tell you so. ### Questions **What does it actually cost to take an order?** Your payment processor’s standard rate on the card transaction, which is the same percentage they charge you in person. There is no second deduction. Compare that with a platform taking 15 to 30 percent, or a subscription that adds a per-order fee on top of the monthly figure. **Will this get me off the delivery apps?** No, and be suspicious of anyone who says it will. The apps bring you customers who had never heard of you. What direct ordering does is stop you paying commission on the regulars who already know your name and used the app because it was the easiest route. That is usually the larger share of orders. **Who handles refunds and failed payments?** You do, through your payment provider’s dashboard, the same as any other card transaction you take. There is no intermediary to go through and no support queue to wait in, which is better when something goes wrong and worse if you wanted somebody else to own it. --- ## Booking & reservations (Quoted) URL: https://altarisdev.com/services/booking-and-reservations/ A booking or reservation path built into your own site, running on infrastructure you control rather than a marketplace that charges per cover and owns the guest relationship. The path is marked up as a ReserveAction so search engines and assistants can read it as something a visitor can actually do. Explicitly not for: - Complex inventory: yield management, channel syncing across OTAs, or seasonal rate rules. That is a product, not a build. - Replacing the OTAs entirely. They are a marketing channel as much as a booking one, and leaving them completely is rarely the right call. ### The cost is not only the commission A marketplace booking costs you a percentage, which is the visible part. The less visible part is that the confirmation email, the reminder, the review request and the record of who stayed or ate and when all belong to the platform. Next time, they market to your guest. A booking taken on your own site costs you nothing per cover and leaves all of that with you. ### How it is built For a restaurant, a small reservation API on your own infrastructure - [Enos Restaurant](/work/enos-restaurant/) runs one of its own - handling covers, time slots and confirmations. For a property with real inventory complexity, we integrate with the system you already run rather than rebuilding it worse. Either way the booking path is marked up as a `ReserveAction` with a typed entry point and a declared result, so the capability is machine-readable rather than hidden inside a form. ### What we will not do We will not build you a yield management system, a channel manager, or anything that syncs rates across a dozen OTAs. Those are products with teams behind them and the right move is to buy one. Nor will we tell you to leave the marketplaces. They find you guests who had never heard of you. The argument is about the guest who already knows your name. ### Questions **Should I drop the OTAs and booking marketplaces?** Almost certainly not. They are a marketing channel that happens to take bookings, and for a property nobody has heard of they do real work. The goal is to stop paying a commission on the guest who searched for you by name and landed on a marketplace because it outranked you. **What about availability and calendars?** For a restaurant, a reservation API on your own infrastructure handles covers and time slots perfectly well. For a hotel with rates changing by season and inventory shared across channels, you want a dedicated system and we will integrate with it rather than rebuild it badly. **Will Google show a reserve button?** Not from markup alone. Those features largely run through partner integrations and no amount of correct JSON-LD enrolls you in one. What the markup does is make the capability legible to assistants answering questions directly, which is a smaller audience today and a growing one. --- ## Speed & SEO rescue (Quoted) URL: https://altarisdev.com/services/speed-and-seo-rescue/ A fixed-price written audit of your existing site covering page speed, structured data, crawlability and the technical reasons you may not be ranking. You get a prioritized report you can hand to any developer, not a sales document. Often the honest conclusion is that your site is fine and the problem is elsewhere. Explicitly not for: - Anyone wanting a score rather than an explanation. A Lighthouse number is free and takes thirty seconds; the value here is knowing which findings matter. - Sites where the real problem is that nobody knows the business exists. An audit cannot fix a demand problem and we will say so instead of taking the fee. ### What gets checked **Speed, and the cause of it.** Not a score - the specific thing making the page slow, whether that is unoptimized images, a builder runtime, render-blocking requests or a slow origin. **Structured data.** What you emit, what is missing, and what is wrong. This is where most local business sites have the largest gap: a generic `LocalBusiness` where a specific type exists, no service entities, hours as prose, or an invented rating that is a [penalty risk](/guides/local-business-schema-mistakes/). **Crawlability and indexation.** Whether your pages can be found and read, whether your sitemap and robots rules say what you think they say, and which AI crawlers you are currently blocking by accident. **The page structure itself.** Whether you have a page per thing you sell, or one page trying to rank for nine different searches at once. ### What you get A written report, prioritized. Not a list of two hundred findings sorted by severity, which is how automated tools produce something impressive and useless, but the handful of things that would actually change an outcome, in the order we would do them. It is yours. Hand it to whoever built your site, hand it to a different agency, or act on it yourself. There is no obligation to hire us and the report does not read like a pitch, because a report written to sell a rebuild is worth nothing to the person reading it. ### When we will tell you to do nothing Often. A technically sound site that is not getting enquiries usually has a content problem or a demand problem, and neither is fixed by rebuilding it. We would rather return that verdict for a small fee than take a build budget for work that will not help. ### Questions **Is this just a Lighthouse report?** No. Lighthouse is free and you can run it yourself in thirty seconds. What it does not tell you is which of its complaints matter for your business, what is causing them, or what to do first. The audit is the interpretation, with the findings ranked by what would actually change an outcome. **Do I have to hire you to fix it?** No, and the report is written so you do not have to. It is specific enough to hand to any competent developer, including the one who built the site. We would rather be the people who told you the truth than the people who held the findings hostage. **What if my site turns out to be fine?** Then we tell you that, and you have spent a small fixed fee to stop worrying about it. It happens more often than you would expect - a site that is technically sound but invisible usually has a content or a demand problem, and rebuilding it would not have helped. --- ## Structured data (Quoted) URL: https://altarisdev.com/services/structured-data/ Structured data is how you tell search engines and AI assistants what your pages mean rather than leaving them to guess. We build one linked JSON-LD graph per page covering your business, services, hours, menu, FAQs and reviews, validated against both the Schema.org vocabulary and Google before it ships. Explicitly not for: - Guaranteeing rich results. Markup makes a page eligible; Google decides what to show, and anybody promising otherwise is overselling. - Inventing reviews or ratings. We will not mark up a rating you do not have, because that is a spam policy violation that risks a manual penalty. ### We measured how rare this is We audited 190 US restaurant websites across eight cities and [94% carry no menu markup at all](/guides/restaurant-structured-data-study/) - not on the homepage, not on the menu page. 91% never declare that they are a restaurant. That is the gap this work closes, and it is measured rather than asserted. ### What it is, without the mystique Structured data is a block of JSON in the page that says, in a vocabulary machines already agree on, what the page is about. That this is a restaurant. That it opens at nine. That this dish costs $14.50. That these four questions have these four answers. Without it, a search engine is inferring all of that from prose, and an assistant answering a question about you is guessing. ### One graph, properly linked The common failure is not missing markup - it is markup that contradicts itself. Five pages each declaring a fresh `LocalBusiness` with no identifier have told search engines there are five businesses. We build one graph per page where each real-world thing has a stable `@id` and everything else references it. The business is declared once; the service pages point at it; the menu is defined on the menu page and referenced elsewhere. The [schema mistakes guide](/guides/local-business-schema-mistakes/) works through the seven we see most. ### The specific type, always `AutoRepair`, not `LocalBusiness`. `CafeOrCoffeeShop`, not `Restaurant`. `LodgingBusiness`, not `Organization`. The specific types inherit everything the generic ones have and add meaning on top, so there is no cost to precision and a real cost to vagueness. Across our builds that has meant `Restaurant`, `Menu`, `MenuItem`, `OrderAction`, `ReserveAction`, `LodgingBusiness`, `HotelRoom`, `BedDetails`, `CafeOrCoffeeShop`, `AutoRepair`, `Service`, `FAQPage`, `AggregateRating` and `BreadcrumbList`. ### Two things we will not do We will not promise rich results. Markup makes a page eligible and Google decides the rest. We will not mark up a rating you do not have. Fabricated `AggregateRating` is a spam policy violation, it attracts a manual action, and the penalty lands on the whole domain rather than the one page. ### Questions **Will this get me rich results in Google?** It makes you eligible, which is the only honest claim available. Google decides what to show based on the query, the page and its own confidence, and correct markup never guarantees a result. What it reliably does is make your content readable, which matters more every year as assistants answer questions directly. **Can you retrofit this to my existing site?** Usually yes, and it is one of the better-value things to do to a site that is otherwise fine. The work is mostly in getting the entities and their relationships right rather than in writing JSON, so it does not depend much on what the site is built with. **How do I know it is correct?** We validate against the Schema.org validator and Google’s Rich Results Test before launch, and they check different things - one tells you the vocabulary is right, the other tells you Google can use it. You get both results, and you can re-run them yourself whenever you like. --- # Selected work ## Argyle Apart Hotel (Hotel & short-stay, London, 2025) Case study: https://altarisdev.com/work/argyle-aparthotel/ Argyle Apart Hotel needed a site that could win direct bookings rather than feed online travel agencies. We built a twelve-page Astro site with a dedicated page per room type, each carrying HotelRoom, Offer and BedDetails structured data, and a booking path short enough to finish on a phone. ### What the build had to solve A serviced apartment operator is in a strange position: it competes with hotels on search, and with online travel agencies on price, while paying the agencies for the privilege. The brief was therefore not "make a nice site" but "make the direct booking the easy one". ### Room pages as the core of the site Guests do not search for aparthotels in the abstract. They search for a studio, a one-bedroom, a place that sleeps four. So each room type got its own page rather than a row in a table, and each page carries the structured data that lets search engines read the bed configuration, the occupancy and the rate. Those room pages reference the parent `LodgingBusiness` by `@id` rather than restating the address and contact details. Facts are declared once, which means they cannot drift out of sync. ### Performance as a booking feature Someone comparing four properties in four tabs will leave the slowest one. Images are generated at three widths through `astro:assets`, the hero is preloaded and everything else is lazy, and the CSS is inlined so there is no render-blocking stylesheet request. --- ## E R Alloy Wheels (Automotive services, Watford, 2025) Case study: https://altarisdev.com/work/e-r-alloy-wheels/ Live site: https://eralloywheels.co.uk E R Alloy Wheels repairs and refurbishes wheels, and needed each service to be findable on its own terms rather than buried in a list. We built a six-page Astro and Tailwind site with a page per job type, AutoRepair structured data carrying service catalog, reviews and opening hours, and native view transitions with no framework JavaScript. ### Several services, several searches Diamond cutting, powder coating, refurbishment and crack repair are four different jobs at four different prices, and people search for them by name. A single services page mentioning all four ranks for none of them well, because it has one title, one description and one set of structured data to spend. So each became a page. Each has its own `Service` node, its own internal links, and copy written for someone who already knows which job they need. ### Reviews where they count For local automotive work, the star rating in the search result does a lot of the selling before anyone reaches the site. The build marks up `AggregateRating` and individual `Review` nodes from real reviews, so they are eligible to appear alongside the listing. Service areas are marked up as the places the shop genuinely covers. That distinction matters: claiming a county you cannot service is the usual way these listings get pulled. ### No framework, still animated Page transitions animate through the native CSS `@view-transition` rule rather than a client-side router, and the header is excluded from the animation so it stays put. The result is a site with transitions and zero framework JavaScript in the bundle. --- ## Central Security Chauffeurs (Security & close protection, London, 2025) Case study: https://altarisdev.com/work/central-security-chauffeurs/ Live site: https://www.centralsecuritychauffeurs.co.uk Central Security Chauffeurs provides SIA-licensed security chauffeurs and close protection. We built a nine-page Astro site where every page emits one @id-linked JSON-LD graph, each service has its own page and FAQ markup, social cards are generated at build time, and a plain-text llms.txt guide makes the business quotable by AI assistants. ### A high-trust purchase, researched quietly Nobody fills in a form to ask whether a close protection officer is licensed. They read, they decide whether the operation looks serious, and they either call or they do not. So every service page opens with a direct, quotable answer to what the service is and who it is for, then answers the licensing and availability questions in FAQ markup underneath. ### One graph per page Rather than scattering structured data through templates, the whole site emits a single JSON-LD `@graph` per page from one module. The business and website nodes are always present; the page adds its own. Everything cross-references by `@id`, so the phone number and service area exist in exactly one place. Unconfirmed facts are explicitly `undefined` with a `TODO(client)` marker and spread conditionally, so the markup never ships an empty property waiting to be filled in. ### Built to be quoted by assistants Being citable by ChatGPT, Claude and Perplexity was in the brief. The `robots.txt` endpoint names sixteen AI crawlers and allows each explicitly. Two plain-text guides, `llms.txt` and `llms-full.txt`, describe the services in a form assistants can lift, and both carry `X-Robots-Tag: noindex` so they never compete with the real pages as duplicate content. ### Motion that knows when to stop GSAP, ScrollTrigger, SplitText and Lenis all live inside one `gsap.matchMedia()` block gated on `prefers-reduced-motion: no-preference` and a desktop width, with a cleanup function. Under reduced motion, none of it is created at all. Scroll positions are recalculated after `document.fonts.ready`, because font swap changes line breaks and therefore every measurement. --- ## Enos Restaurant (Restaurant, Weybridge, 2025) Case study: https://altarisdev.com/work/enos-restaurant/ Live site: https://www.enosrestaurant.co.uk Enos is an Italian restaurant in Weybridge that needed reservations running on its own infrastructure rather than through a marketplace taking a cut of every cover. We built the site with its own reservation service behind the booking form, and marked that path up with ReserveAction and FoodEstablishmentReservation so search engines can read it as a bookable action. ### Bookings that belong to the restaurant A reservation taken through a marketplace costs money per cover and, more importantly, puts somebody else between the restaurant and the diner. The booking confirmation, the reminder, the record of who came and when - all of it accrues to the platform. Enos takes bookings through its own site, backed by a small reservation API of its own. There is no per-cover fee because there is no intermediary to pay. ### Making the booking path machine-readable A booking form is invisible to a search engine unless you tell it what the form does. This build marks the reservation path up as a `ReserveAction` with a `FoodEstablishmentReservation` result and a typed `EntryPoint`, which is the vocabulary Google and AI assistants use to understand that a page offers a bookable action rather than just describing one. The rest of the graph carries the parts people actually search for: the menu, the opening hours, the address and the coordinates. ### Motion without the cost The site uses GSAP for sequencing and Lenis for scroll, both scoped inside a `matchMedia` block with teardown, so a visitor who has asked their operating system for reduced motion gets a static page rather than a degraded animated one. --- ## Villas Cafe (Cafe, Finsbury Park, London, 2025) Case study: https://altarisdev.com/work/villas-cafe/ Live site: https://villas-cafe.co.uk Villas Cafe is a specialty coffee shop and all-day kitchen in Finsbury Park. We built a single-page site with no framework at all, and put the entire menu into structured data at item level - CafeOrCoffeeShop, Menu, MenuSection, MenuItem and Offer, each dish carrying its own price so search engines and assistants can read the menu rather than guess at it. ### The menu is the product, so the menu is the markup Ask a search engine what Villas Cafe serves and it can answer, because every dish on the page is a `MenuItem` inside a `MenuSection`, and every one of them carries an `Offer` with a price. That is unusual. The common pattern is a photograph of a menu board, or a PDF, both of which are opaque. This matters more every year. When somebody asks an assistant what to eat near Finsbury Park, the places whose menus are readable are the places that can be recommended. ### One page, done properly Not every business needs twelve pages. A cafe has one story, one menu, one gallery and one address, and splitting those across separate URLs would dilute rather than help. So this is a single page with four sections, one URL that collects all the links anyone sends it, and anchor navigation for people who want to jump. ### No framework There is no React here, and no Astro either. The site is TypeScript compiled by Vite and shipped as finished files. For a site with no interactive state beyond a menu toggle, a framework would have been weight with nothing to carry. --- ## Brothers Fish & Chips (Takeaway, Bushey, Hertfordshire, 2025) Case study: https://altarisdev.com/work/brothers-fish-chips/ Live site: https://busheybrothers.co.uk Brothers Fish & Chips is a takeaway in Bushey, Hertfordshire. The site is six pages of hand-written HTML, CSS and JavaScript with no build step and no framework, carrying Restaurant structured data, opening hours and coordinates, plus a dedicated landing page targeting the town-and-dish search that actually brings a takeaway its customers. ### People search for the dish and the town Nobody searching for dinner types a takeaway's brand name unless they already know it. They type the food and the place. That search deserves its own page - one with a title, a description and a set of structured data entirely devoted to it, rather than a mention halfway down a home page trying to do five jobs at once. So the site has one, alongside the usual home, menu, about and contact pages. ### No build step at all This is the simplest site we have shipped and deliberately so. Six HTML files, one stylesheet, one script. There is no framework, no bundler and no build pipeline, which means there is nothing to upgrade, nothing to break on a dependency change, and nothing between the files and the browser. For a takeaway whose site needs to change a few times a year, that is the right amount of machinery. A build pipeline is a maintenance commitment, and committing somebody else to one they did not ask for is how sites rot. ### Honest note on speed This is the slowest of the sites on this page, which is worth saying out loud. Hand-written HTML is not automatically fast - how images are sized and served matters more than the framework question, and there is headroom here we have not yet spent. --- ## Delta Surveillance (CCTV and security installation, London, 2025) Case study: https://altarisdev.com/work/delta-surveillance/ Live site: https://deltasurveillance.co.uk Delta Surveillance installs CCTV and security systems in London. The site carries LocalBusiness markup alongside a separate Service node for each thing the company installs, plus FAQPage structured data built from the questions customers actually ask before committing to a security install. ### They search for the problem, not the product Someone wanting cameras does not search for the model. They search for the worry - a break-in nearby, a delivery going missing, a business insurer asking for coverage. Pages that answer those questions get found; pages describing product lines do not. So the structured data treats each offering as its own `Service` rather than lumping them into one page about what the company does. ### Questions before contact details Nobody books a security survey without first wanting to know what it costs, how long it takes, whether it needs planning permission and what happens if it breaks. Those questions are marked up as `FAQPage` entries, which makes them eligible to be shown directly in search results and quotable by an AI assistant. ### Honest note This is a React application, and at the time of writing it ships more to the browser than the other sites on this page. The structured data work here is the strongest part of the build; the payload is the part we would revisit. --- # Technical guides ## 94% of US restaurant sites have no menu markup URL: https://altarisdev.com/guides/restaurant-structured-data-study/ We checked the structured data on 190 US restaurant websites across eight cities. 94% carry no menu markup on either the homepage or the menu page, 91% never declare that they are a restaurant rather than a generic business, and 22% emit no structured data at all. Eleven sites in the sample do it properly. We ran the audit twice, at 124 sites and at 190, and the headline figures did not move. ### What we did Published restaurant guides covering **Atlanta, Austin, Chicago, Dallas, Los Angeles, New Orleans, New York and Seattle**. Eleven guides resolved; fifteen more returned 404 and were skipped, which the harvester records rather than hides. Every outbound domain was extracted, then publishers, directories, ordering platforms, social networks, asset hosts and ad-tech removed. That left **213 candidate restaurant domains**, of which **190 responded** on 31 October 2026. Each site had its homepage fetched and every JSON-LD block parsed. Where the homepage linked to a menu page, that page was fetched too, so no restaurant was marked down for keeping its menu markup where it belongs. ### What we found | Finding | Sites | Share | |---|---|---| | No menu markup, homepage or menu page | 179/190 | **94%** | | No FAQ markup | 188/190 | 99% | | No opening hours as structured data | 175/190 | **92%** | | Never declares itself a restaurant | 173/190 | **91%** | | No breadcrumb markup on the homepage | 169/190 | 89% | | No booking or ordering action declared | 151/190 | 79% | | No stable identifier on the business | 146/190 | 77% | | Describes a business, but only generically | 98/190 | 52% | | No business entity described at all | 75/190 | 39% | | No structured data whatsoever | 41/190 | 22% | | Claims an aggregate rating | 5/190 | 3% | | Broken, unparseable markup | 0/190 | 0% | ### The numbers did not move when the sample grew We ran this twice. The first pass covered 124 sites from five cities. The second covered 190 from eight, with a corrected business-type test and a cleaned sample. **94% and 91% both times.** A figure that survives a 53% increase in sample size and a change of cities is measuring something real about how restaurant websites get built, not an artefact of which guides we happened to pick. ### The menu number is the one that matters A restaurant's menu is the most valuable content it owns. It is what people search for, what they compare, and what an assistant needs in order to recommend the place to someone asking where to eat nearby. **In this sample, 94% of it is unreadable by machine.** Not missing - the menus are all there, as photographs, as PDFs, as beautifully typeset HTML with no markup attached. Readable by people, opaque to everything else. Eleven sites out of 190 did it properly. The best of them declares `Restaurant` on the homepage and `Restaurant` plus `Menu` on the menu page, which is what the whole sample should look like. Another emits nothing at all on its homepage and `Restaurant`, `Menu` and `FAQPage` on its menu page - which is why following the menu link mattered, and why a study that judged homepages alone would have reached the wrong answer about it. ### Nine in ten never say what they are 173 of 190 sites never declare that they are a restaurant. 75 describe no business entity at all, and a further 98 describe one only as a generic `Organization` or `LocalBusiness` - a description equally true of a dentist, a law firm and a scrapyard. Schema.org has had a `Restaurant` type for over a decade. It inherits everything the generic types carry and costs nothing to use. The [local business schema guide](/guides/local-business-schema-mistakes/) covers why the specific type is always the right call. ### What almost nobody gets wrong Two findings cut the other way, and they are worth stating because they contradict the usual agency pitch. **Nothing was broken.** Zero sites had an unparseable JSON-LD block. When these restaurants emit structured data, it is valid. The problem is omission, not malformation, and anyone selling you a "fix your broken schema" audit is solving a problem this population does not have. **Almost nobody is faking reviews.** Five sites claimed an aggregate rating. Fabricated ratings are the one structured-data mistake that attracts a manual penalty, and this population is not making it. ### No restaurant is named here Not the ones that failed, and not the eleven that got it right. These are small businesses that did not ask to be in a study, and a site whose entire argument is about doing this honestly should not build its credibility by listing other people's mistakes under their trading names. The aggregate is the finding. If you want to know how your own site does, run the audit against it - the script is below and it takes a minute. ### Limitations, stated plainly **The sample flatters the population.** These restaurants were chosen because a publication wrote about them, which correlates with having a budget and someone competent building the site. A random sample of US restaurants would almost certainly be worse. **Homepage and menu page only.** A site could carry excellent markup on a reservations or locations page and still be counted as failing the things we checked elsewhere. **One point in time.** Measured 31 October 2026. Sites change. **Eight cities, not the country.** Enough to say the pattern is overwhelming. Not enough to put a decimal point on it, which is why no figure here has one. **Hotels were attempted and abandoned.** Eight of twelve hotel guides refused our requests, which left the sample dominated by one article whose outbound links were mostly its own publisher's international editions and a pile of ad-tech. Roughly seven genuine hotels survived, all in a single city. The honest move was to drop the vertical rather than publish 100% of 30 when a third of that 30 were not hotels. ### Reproduce it Both scripts are in this site's repository, along with the list of guides the sample was drawn from. The sample itself is not committed - it is a list of real businesses, and the point of the previous section is that we do not publish those. You regenerate it, which also means you are checking our harvesting rather than trusting it. ```bash npm run harvest scripts/samples/guides-restaurants.txt restaurants \ > scripts/samples/us-restaurants.txt npm run audit scripts/samples/us-restaurants.txt ``` The audit refuses to print percentages from fewer than 30 reachable sites. That guard is aimed at exactly this kind of study: easy to run badly, and easy to publish a confident number from a sample that cannot carry one. ### Questions **How was the sample chosen?** We took published restaurant guides covering eight US cities, extracted every outbound domain, and removed publishers, directories, ordering platforms, social networks and asset hosts. That left 213 candidate domains, of which 190 responded. The sample is biased towards restaurants good enough to be written about, which correlates with having a budget and a competent developer - so the true population is probably worse than this, not better. **How confident are you in these numbers?** More than we expected to be. We ran the whole thing twice on different samples, 124 sites and then 190, and the two headline figures came out identical both times: 94% with no menu markup, 91% never declaring themselves a restaurant. A pattern that stable across two independent draws is not a sampling accident. **Does any of this actually affect rankings?** Structured data is not a ranking factor the way a link is. What it does is make a page eligible for rich results and legible to assistants answering questions directly. The honest framing is that 94% of these restaurants cannot have their menu read accurately by a machine, and the share of people asking a machine rather than scrolling results goes up every year. **Can I reproduce this?** Yes, and you should rather than take our word for it. The harvesting and auditing scripts are both in this site’s repository, the guide list and the sample are committed beside them, and the whole run is two commands. Every figure on this page can be regenerated from scratch. **Did you try other sectors?** We tried hotels and abandoned it. Eight of the twelve hotel guides refused our requests, which left the sample dominated by a single article whose outbound links were mostly its own publisher’s international editions and ad-tech. About seven genuine hotels survived, all in one city. We would rather report a failed sampling frame than publish a percentage from that. --- ## Getting your menu into search results URL: https://altarisdev.com/guides/menu-structured-data/ A menu published as a photograph or a PDF is invisible to search engines: no dish, price or dietary note can be read from it. Marking the menu up as JSON-LD - a Menu containing MenuSection objects containing MenuItem objects, each with its own Offer and price - makes every item machine-readable, which is what allows a dish to appear in a search result or be recommended by an assistant. ### Why a picture of a menu is worth nothing Most restaurant sites publish the menu as an image or a PDF. Both are opaque. A search engine looking at a photograph of a menu board sees a photograph. It cannot tell you have a carbonara, it cannot tell what it costs, and it cannot offer you to somebody asking an assistant where to eat nearby. That is the single most valuable content on the site, thrown away. ### The shape of the data Menu markup nests in a specific order, and getting the nesting wrong is the most common failure. A `Restaurant` has a `Menu`, a `Menu` has `MenuSection` objects, and a `MenuSection` has `MenuItem` objects. Prices live on an `Offer` attached to the item. ```json { "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://example.com/#restaurant", "name": "Example Kitchen", "servesCuisine": "Italian", "hasMenu": { "@type": "Menu", "@id": "https://example.com/menu/#menu", "name": "All day", "hasMenuSection": [ { "@type": "MenuSection", "name": "Pasta", "hasMenuItem": [ { "@type": "MenuItem", "name": "Carbonara", "description": "Guanciale, pecorino, egg yolk, black pepper", "suitableForDiet": "https://schema.org/LowLactoseDiet", "offers": { "@type": "Offer", "price": "14.50", "priceCurrency": "USD" } } ] } ] } } ``` Three details in there matter more than they look: - **`priceCurrency` is required** alongside `price`. A price with no currency is ambiguous and gets ignored. - **`price` is a string without a symbol.** `"14.50"`, not `"$14.50"` and not `14.50`. - **`@id` on the restaurant** lets every other page reference the same entity instead of declaring a new one. A site that declares five unlinked `Restaurant` nodes has told search engines it is five restaurants. ### Link it, do not repeat it The menu page declares the full `Menu`. Every other page should reference it by `@id` rather than restating it: ```json { "@type": "Restaurant", "@id": "https://example.com/#restaurant", "hasMenu": { "@id": "https://example.com/menu/#menu" } } ``` This is the part most implementations miss. Repeating the whole menu on every page creates competing definitions of the same thing. ### The mistakes we see most 1. **The menu is an image.** Nothing else on this list matters until this is fixed. 2. **Items with no price.** A `MenuItem` without an `Offer` is a name floating in space. 3. **Sections flattened away.** Every item hung directly off the `Menu` with no `MenuSection` loses the structure a human reader uses. 4. **Markup that disagrees with the page.** If the JSON-LD says $14.50 and the page says $16, you have a problem that is worse than having no markup. 5. **`AggregateRating` invented.** Covered in [the local business guide](/guides/local-business-schema-mistakes/) - this one can get you a manual penalty. ### Check it before you ship it Paste the rendered page into Google's Rich Results Test and the Schema.org validator. They disagree deliberately: the Schema.org validator tells you whether the vocabulary is correct, and Google's tells you whether you are eligible for anything it shows. You want both clean. We [audited 190 US restaurant sites](/guides/restaurant-structured-data-study/) and 94% carry no menu markup at all, so doing this puts you ahead of almost everyone in the sector. [Villas Cafe](/work/villas-cafe/) is a worked example - every dish on a single-page cafe site is a `MenuItem` inside a `MenuSection` carrying its own `Offer` and price. ### Questions **Does menu markup guarantee a rich result?** No. Structured data makes a page eligible for a rich result; it never guarantees one. Google decides what to show based on the query, the page and its own confidence. What markup reliably does is make the content readable, which matters increasingly for assistants answering questions rather than only for the blue-link result. **Should I mark up prices if they change often?** Yes, but only if you will keep them current. Stale prices in structured data are worse than no prices, because a customer who sees one figure in a search result and another on the page has caught you being careless. If prices move monthly, generate the markup from the same source as the page so the two cannot drift. **Can I mark up a menu that lives in a PDF?** You can add the markup to the HTML page that links to the PDF, but the better answer is to stop using the PDF. A PDF is unreadable on a phone, slow to load, and invisible to most of what you want reading it. The menu is the most valuable content a restaurant has and it belongs in HTML. --- ## Making a booking path machine-readable URL: https://altarisdev.com/guides/booking-and-ordering-schema/ A booking or ordering form is just an HTML form: nothing about it tells a search engine that the page offers something you can act on. Describing it as a ReserveAction or OrderAction with a typed EntryPoint is what turns a form into a declared capability, which is the vocabulary assistants use when deciding whether a business can actually take a booking. ### A form says nothing about itself You can have a perfectly good reservation form on a page and every machine reading that page will see a `
` element. There is nothing in HTML that says "this restaurant takes bookings" in a way anything can act on. Schema.org has vocabulary for exactly this, and almost nobody uses it. `potentialAction` attaches an action to an entity and says what the entity can do. ### ReserveAction ```json { "@context": "https://schema.org", "@type": "Restaurant", "@id": "https://example.com/#restaurant", "name": "Example Kitchen", "potentialAction": { "@type": "ReserveAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/book/", "inLanguage": "en-US", "actionPlatform": [ "https://schema.org/DesktopWebPlatform", "https://schema.org/MobileWebPlatform" ] }, "result": { "@type": "FoodEstablishmentReservation", "name": "Table reservation" } } } ``` The three parts each do a job. `target` says where the action happens. `actionPlatform` says where it works. `result` says what you get if you complete it - and `FoodEstablishmentReservation` is a far more specific statement than "a form was submitted". For hotels the result type is `LodgingReservation`; the structure is otherwise identical. ### OrderAction Ordering uses the same pattern with a different action and a `deliveryMethod`: ```json { "@type": "OrderAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://example.com/order/", "actionPlatform": "https://schema.org/MobileWebPlatform" }, "deliveryMethod": "https://schema.org/OnSitePickup" } ``` Use `OnSitePickup` for collection and `ParcelService` or `OwnFleet` for delivery, and declare both as separate actions if you offer both. Declaring delivery you do not do is the fastest way to collect bad reviews from people who waited. ### Be honest about what this buys you It will not place a reserve button in a Google result. Those features run largely through partner programs, and correct markup does not enroll you in one. Anybody telling you otherwise is selling. What it does is make the capability legible to everything reading the page, which now includes assistants answering "can I book a table at X" directly. That audience is growing considerably faster than the one clicking reserve buttons in search results, and the markup costs an hour. ### Keep it attached to the right entity The action belongs on the business, not on the page. A common error is declaring the `ReserveAction` inside a `WebPage` node, which says the page can be reserved. Attach it to the `Restaurant` or `LodgingBusiness` by `@id` so the statement is about the business. [Enos Restaurant](/work/enos-restaurant/) runs this in production, with the reservation handled by its own API rather than a marketplace taking a cut of each cover. ### Questions **Will this put a Reserve button in Google?** Not on its own. Google’s booking features largely run through partner integrations rather than open markup, and no amount of correct JSON-LD enrolls you in one. What the markup does is make the capability legible to everything else that reads the page - assistants included - and that audience is growing faster than the one looking at reserve buttons. **What is an EntryPoint and do I need one?** An EntryPoint describes how the action is actually performed: the URL template, the HTTP method, and the platforms it works on. Without it you have said a booking exists but not where it happens, which is only half the statement. It is a few lines and it is the part that makes the action usable rather than decorative. **Does this work for a third-party booking widget?** Yes, and you should point the urlTemplate at wherever the booking genuinely happens, including a third-party page. Describing a booking path you do not control is still accurate. What you must not do is describe a booking capability you do not have. --- ## Seven local business schema mistakes URL: https://altarisdev.com/guides/local-business-schema-mistakes/ Most local business structured data is technically valid and still close to useless, because it uses the generic LocalBusiness type when a specific one exists, claims service areas the business does not cover, repeats unlinked copies of the same entity on every page, or invents an AggregateRating - which is the one mistake on this list that can earn a manual penalty. ### 1. Using `LocalBusiness` when something specific exists This is the most common and the easiest to fix. Schema.org has specific subtypes that inherit everything `LocalBusiness` has and add meaning: `AutoRepair`, `CafeOrCoffeeShop`, `Restaurant`, `LodgingBusiness`, `HairSalon`, `Dentist`, `Plumber`, `SecurityService`. ```json { "@type": "AutoRepair", "@id": "https://example.com/#business" } ``` Use the narrowest type that is still true. ### 2. Claiming service areas you do not serve `areaServed` listing every county within fifty miles is a common piece of optimism. It does not help you rank in those places, and claiming coverage you cannot deliver is how listings get reported. Mark up what you actually cover, typed properly: ```json "areaServed": [ { "@type": "City", "name": "Austin" }, { "@type": "AdministrativeArea", "name": "Texas" } ] ``` ### 3. Unlinked copies of the same entity on every page If every page declares a fresh `LocalBusiness` with no `@id`, you have told search engines you have as many businesses as you have pages. Declare the entity once with a stable `@id`, then reference it everywhere else: ```json { "@type": "WebPage", "@id": "https://example.com/services/#page", "about": { "@id": "https://example.com/#business" } } ``` One graph per page, one `@id` per real-world thing, references instead of repeats. ### 4. Inventing `AggregateRating` This is the one that can actually hurt you. Marking up ratings that do not exist, or that you gathered yourself and presented as independent, violates Google's structured data spam policies and earns a manual action. If you have genuine reviews on your own site, mark them up. If you do not, leave the field out. An absent rating costs you a star in a search result; a fabricated one can cost you the rich result entirely, across the whole domain. ### 5. Opening hours as prose `"openingHours": "Mon-Fri 9-5"` is a string. Use the structured form so it can be parsed, and include the edge cases: ```json "openingHoursSpecification": [ { "@type": "OpeningHoursSpecification", "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"], "opens": "09:00", "closes": "17:30" }, { "@type": "OpeningHoursSpecification", "dayOfWeek": "Saturday", "opens": "09:00", "closes": "13:00" } ] ``` Times are 24-hour. A business closed on Sunday simply omits it. ### 6. NAP that disagrees with itself Name, address and phone number should be byte-identical across your markup, your Google Business Profile, your footer and every directory listing. "Street" in one place and "St" in another is a reconciliation problem you are handing to a machine that will not always get it right. ### 7. Services as a list instead of entities A paragraph listing six services is not six things. Each service a business wants to be found for deserves its own `Service` node, and usually its own page: ```json { "@type": "Service", "@id": "https://example.com/services/cctv/#service", "serviceType": "CCTV installation", "provider": { "@id": "https://example.com/#business" } } ``` [Delta Surveillance](/work/delta-surveillance/) does this per offering; [E R Alloy Wheels](/work/e-r-alloy-wheels/) does it per job type. ### Validate both ways Run every page through the Schema.org validator and Google's Rich Results Test. The first tells you whether the vocabulary is right; the second tells you whether Google will do anything with it. Passing one is not passing the other. ### Questions **Can bad structured data actually hurt me?** Yes, in one specific way: marking up reviews or ratings that do not exist, or that you collected yourself and presented as independent, is a spam policy violation and attracts a manual action. The rest of the mistakes on this list waste the opportunity rather than cause damage, but that one is genuinely dangerous. **How specific should the business type be?** As specific as schema.org offers. If AutoRepair, CafeOrCoffeeShop, LodgingBusiness or HairSalon describes you, use it instead of LocalBusiness. The specific types inherit everything the generic one has and add meaning on top, so there is no cost to being precise and a real cost to being vague. **Do I need structured data if I have a Google Business Profile?** They do different jobs. The profile feeds the map pack; the markup describes your website and is what non-Google systems read, assistants included. They should also agree with each other - a name, address or phone number that differs between the two is a signal neither can resolve. --- ## Getting your business quoted by AI assistants URL: https://altarisdev.com/guides/ai-crawlers-and-llms-txt/ AI crawlers do different jobs and need different decisions: training crawlers like GPTBot build models, search crawlers like OAI-SearchBot build the index an assistant answers from, and user-triggered fetchers visit because somebody asked. Blocking the first does not remove you from the second, and conflating them is how businesses accidentally make themselves unquotable. ### Three kinds of crawler, three different decisions Treating "AI crawlers" as one category is the root of most bad decisions here. There are three jobs, and you may reasonably want different answers for each. **Training crawlers** collect content to train models. `GPTBot`, `ClaudeBot`, `CCBot`, `Google-Extended` and `Applebot-Extended` are in this group. Blocking them keeps your content out of future model weights and has no effect on whether an assistant can find you today. **Search crawlers** build the index an assistant searches when answering a live question. `OAI-SearchBot`, `Claude-SearchBot`, `PerplexityBot` and `Bingbot` do this. **These are the ones that decide whether you can be cited at all.** Blocking them is how a business makes itself invisible to assistants while believing it has protected something. **User-triggered fetchers** visit a page because a person asked an assistant to look at it. `ChatGPT-User`, `Claude-User`, `Perplexity-User` and `MistralAI-User` behave this way. Blocking them means a potential customer who pastes your URL gets told the page cannot be read. For a local business the answer is usually: allow all three. Your product is a service, not the prose on the page, and being quotable is the entire point. ### A robots.txt that says what you mean `robots.txt` groups do not inherit. A rule under `User-agent: *` is replaced, not supplemented, by a more specific group - so a crawler you name needs its own complete rules. ``` User-agent: GPTBot Allow: / User-agent: OAI-SearchBot Allow: / User-agent: ChatGPT-User Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-SearchBot Allow: / User-agent: PerplexityBot Allow: / User-agent: Google-Extended Allow: / User-agent: * Allow: / Sitemap: https://example.com/sitemap.xml ``` Crawler names change, and vendors add new ones without much announcement. Check the operator's own documentation rather than trusting a list in a blog post - including this one. ### The Google-Extended trap This one is worth stating on its own because it is expensive and widely misunderstood. `Google-Extended` controls whether your content may be used for Gemini training and grounding. It does **not** control AI Overviews in Google Search. Those are served from the ordinary Search index, crawled by `Googlebot`. Blocking `Google-Extended` therefore does not remove you from AI Overviews - it only gives up the other use while leaving you exactly as exposed. If you genuinely want out of AI Overviews, the lever is `nosnippet` or `max-snippet`, and those also cut your normal search snippet. There is no free version of that choice. ### Is llms.txt worth it? Honestly: probably, barely, and not for the reasons it is usually sold. `llms.txt` is a **proposed convention**, not a standard. No major AI company has publicly committed to reading it, and there is no good public evidence that it changes what assistants say about you. Agencies selling it as essential are ahead of the facts. We ship one anyway, because it is half an hour of work, it costs nothing to serve, and the downside is zero. Keep it generated from the same content as your pages so it cannot drift, and serve it with `X-Robots-Tag: noindex` so it does not compete with the real pages as duplicate content. ### Write the answer, then the page The single highest-leverage thing is unglamorous: put a direct, self-contained answer in the first paragraph under each `

`. Assistants extract passages. A paragraph that answers the page's question completely, in forty to seventy words, without depending on the heading above it or the paragraph below it, is a paragraph that can be lifted and attributed. A page that opens with "Welcome to our website" offers nothing to lift. Every page on this site is built that way, including this one. Look at the paragraph under the heading at the top and you will see the pattern: it answers the question on its own, so it survives being quoted somewhere else. ### Questions **Is llms.txt an official standard?** No. It is a proposed convention, not a specification any major AI company has committed to honouring, and you should treat claims about its impact with scepticism. We ship one because it is half an hour of work and costs nothing, not because there is evidence it changes outcomes. Anyone presenting it as essential is overstating what is known. **Should I block AI crawlers?** It depends what you sell. A publisher whose product is the writing has a real argument for blocking training crawlers. A local business whose product is a service wants to be found and quoted, and blocking the crawlers that feed assistant answers removes you from a channel where your competitors will still appear. **Does blocking Google-Extended remove me from AI Overviews?** No, and this is the most expensive misunderstanding in this area. Google-Extended governs whether your content is used for Gemini model training and grounding. AI Overviews in Search are served from the normal Search index via Googlebot, so blocking Google-Extended does not take you out of them - it only costs you the other use. --- # Comparisons with named platforms ## Owner.com (Restaurant marketing and direct-ordering platform) URL: https://altarisdev.com/compare/owner-com-alternative/ The alternative to Owner.com is a site you pay for once. Owner.com charges $249 a month plus 5% of each order, or $499 a month with no order fee. A custom build is $1,500 or $3,000 once, takes no commission, and costs nothing per month afterwards. Owner.com also runs your marketing, which we do not. Their published pricing: $249 to $499 a month, per location, per month, billed month to month with no long-term contract. Checked 2026-10-31. Outside the headline plan: The $249 Flexible plan adds a 5% restaurant fee to each order. The $499 Flat Rate plan removes that fee. The two plans cost the same at about $5,000 a month in direct orders. ### Point by point **What you pay** - Owner.com: $249 or $499 every month, for as long as you want the site to stay up. - Altaris: $1,500 for a small site or $3,000 for a multi-page site, paid once. **Commission on orders** - Owner.com: 5% of every order on the $249 plan. None on the $499 plan, which is why the plans converge around $5,000 a month in orders. - Altaris: None, on any plan. Orders settle into your own payment account and only your card processor takes their standard rate. **What you are buying** - Owner.com: Access to a platform, for as long as you keep paying for it. - Altaris: A finished piece of work, quoted and paid for once. We host and maintain it afterwards at no monthly cost. **If you stop paying** - Owner.com: The site and the ordering stop with it. - Altaris: There is nothing recurring to stop paying. The site stays up and the ordering keeps working. **Marketing** - Owner.com: Run for you - email, text campaigns, offers and win-back automation, operated by their team. - Altaris: Not included, and we will not pretend otherwise. We build the site. Marketing stays with you or your agency. ### When to choose them instead - You want the marketing actually run for you. This is the real product and it is the thing a one-time build does not replace. If nobody on your team is going to send the emails, their fee buys someone who will. - You are starting from zero direct orders. Owner.com is built to move customers off the delivery apps, and that campaign work matters more at the start than what the website costs. - You want month-to-month with no commitment. There is no contract and no cancellation fee, which is a genuinely lower-risk way in than paying a build up front. ### What Owner.com actually sells It is easy to read Owner.com as a website product and conclude it is expensive. It is not really a website product. It is a marketing service with a website and an ordering system attached, and the monthly fee mostly pays for the campaigns, the automation and the people running them. That matters, because it decides whether this comparison is relevant to you. If you want the marketing done for you, nothing on this page replaces it and you should keep reading their site rather than ours. If you already have someone doing your marketing, or you intend to do it yourself, then you are paying $249 to $499 a month plus a possible 5% for a website and an ordering form, and that is the part worth challenging. ### The commission is the part people underestimate The headline figure is the monthly plan, but the 5% restaurant fee on the Flexible plan is usually the larger number. At $5,000 a month in direct orders it is $250, which is why the $499 flat plan exists and why the two converge at roughly that volume. At $10,000 a month the Flexible plan costs $749 all in. A site that takes orders through your own payment account has no equivalent line. Your processor takes their standard rate on the card transaction, exactly as they do in the dining room, and that is the end of it. Over five years at $10,000 a month in orders, the difference is not a rounding error. ### What you give up We are not going to pretend this is free of trade-offs. You lose the campaign engine, the done-for-you email and text automation, and a team whose job is to chase your customers back. You also take on the job of deciding what to change on the site, rather than having a vendor do it. What you get instead is the thing nobody rents you: a site that costs nothing to run, cannot be switched off by a billing dispute, and has no bill attached to it at all. ### Questions **Is a one-time build actually cheaper than Owner.com?** On their $499 flat plan, a $3,000 site pays for itself in six months. On the $249 plan it takes twelve, before counting the 5% order fee, which on $5,000 a month of orders is another $250. But that comparison only holds if you do not need the marketing their fee pays for. **Can I take commission-free ordering without leaving Owner.com entirely?** You can run a second ordering path on your own site and keep theirs, though paying two systems rarely makes sense for long. The more common pattern is to move the website and ordering first and keep a marketing retainer with somebody, whether that is them or anyone else. **What happens to my existing customer list?** Ask them for an export before you give notice, and check your contract for what you are entitled to. Any platform holding your customer list is leverage over you, which is a good argument for keeping that list somewhere you control from the start. --- ## BentoBox (Restaurant website and online ordering platform) URL: https://altarisdev.com/compare/bentobox-alternative/ The alternative to BentoBox is a custom site you pay for once. BentoBox does not publish standard pricing, and third-party figures range from roughly $49 to $600 a month plus setup, so the first thing to do is get their quote in writing. A one-time build is $1,500 or $3,000 once, takes no commission on orders, and costs nothing per month afterwards. Their published pricing: Not published, quoted per restaurant, typically as a monthly plan plus a separate setup fee. Checked 2026-10-31. Outside the headline plan: Third-party sources report anywhere from about $49 a month for a basic takeout plan to $479 or more for a full-feature tier, with setup variously reported between $500 and $5,000, and per-order fees on some plans. Those figures contradict each other, so treat the quote you are given as the only real number. ### Point by point **Knowing the price** - BentoBox: No public price list. What you pay depends on the quote you negotiate. - Altaris: $1,500 and $3,000 are published on our pricing page. Larger builds are quoted, and fixed before work starts. **What you pay** - BentoBox: A monthly plan for as long as you use it, plus setup up front. - Altaris: One payment. Hosting is $0 a month afterwards. **What the fee buys** - BentoBox: Continued access to their platform. The design and the ordering go when the subscription does. - Altaris: The build itself, once. We host and run it afterwards at no monthly cost. **Ordering fees** - BentoBox: Per-order fees apply on some plans, alongside card processing. - Altaris: No per-order fee. Only your card processor takes their standard rate. **Who does the work** - BentoBox: A product team, a template library and a support desk behind it. - Altaris: One studio. Better for a site built around your business, worse if you need a vendor with a support SLA. ### When to choose them instead - You are a multi-location group. Central menu management across sites, with permissions and a support contract, is a real product need and a one-time build does not answer it well. - You want events, catering enquiries, gift cards, email marketing and ordering as one integrated product with one vendor to call. Assembling that yourself is work, and theirs is mature. - Your team will not maintain anything. A subscription buys someone else being responsible, which is worth real money if the alternative is a site nobody updates. ### Start by finding out what it costs BentoBox does not publish a price list. That is a legitimate way to sell a product that varies by restaurant, but it has a side effect: the internet is full of confident numbers that disagree with each other. Preparing this page, we found the same product described as $49 a month and as $479 a month, with setup quoted anywhere between $500 and $5,000, almost always on sites run by their competitors. So we are not going to add another invented figure. Get their quote in writing and itemised; the lines worth insisting on are in the FAQ below. Then you can compare it to $1,500 or $3,000, paid once, which is on our pricing page because we think you should be able to work this out without a call. ### Where they are genuinely strong BentoBox is a mature product with good design work behind it, and for a restaurant group it solves problems a single site does not have: menu changes pushed across locations, staff permissions, one vendor to call when something breaks, events and catering enquiries handled in the same place as ordering. If that is your situation, the honest answer is that a one-time build is the wrong shape of solution and you should weigh them against Popmenu or Toast rather than against us. ### Where a one-time build wins For a single restaurant, most of that machinery is overhead you are renting. What you actually need is a fast site, a menu search engines can read, a page per thing you sell, and an ordering path that does not take a cut. That is a finite piece of work, and it does not need to recur as a monthly charge for the next decade. ### Questions **Why can I not find BentoBox pricing anywhere?** Because they quote per restaurant rather than publishing a list, which is normal for this kind of product. It does mean the figures you find in comparison articles are unreliable - we found the same plan described as $49 and as $479 on different sites. Ask for a written quote covering the plan, the setup fee and any per-order charge. **What should I ask for in their quote?** The monthly figure, the setup fee, the contract length and notice period, any per-order fee, and what happens to your site and customer data if you leave. The last one matters most and is the one least often volunteered. **Can my site look as good as a BentoBox site?** Their design work is genuinely strong, and we would not claim otherwise - that is a large part of what the fee buys. The difference is that a custom build is designed around your menu and your service rather than selected from a library, and it is yours afterwards. --- ## Popmenu (Restaurant website, interactive menu and marketing platform) URL: https://altarisdev.com/compare/popmenu-alternative/ The alternative to Popmenu is a site you buy once rather than rent. Popmenu publishes plans at roughly $179, $299 and $499 a month per location, with online ordering sold as an add-on. A custom build is $1,500 or $3,000 once, includes commission-free ordering in the quoted tier, and costs nothing per month afterwards. Their published pricing: $179 to $499 a month, per location, per month, with roughly 10% off when prepaid annually. Checked 2026-10-31. Outside the headline plan: Online ordering is an add-on rather than part of the base plan. Additional locations are charged separately. A custom enterprise tier sits above the published plans. ### Point by point **What you pay** - Popmenu: $179 to $499 every month, per location, plus the ordering add-on. - Altaris: $1,500 or $3,000 once, for the site. Ordering builds are quoted per project. **Cost of a second location** - Popmenu: Charged again, per location, every month. - Altaris: Usually extra pages on the same site, quoted once. **What the fee buys** - Popmenu: Continued access to their platform and templates, billed monthly per location. - Altaris: The build itself, once. Hosting and small changes afterwards cost you nothing. **Interactive menu features** - Popmenu: Their signature product. Menu items get their own pages, photos, reviews and follows. - Altaris: We build menu pages with full Menu and MenuItem structured data, but no social layer on top. **Ongoing marketing** - Popmenu: Email and text campaigns, and an AI phone answering product, bundled into the higher plans. - Altaris: Not included. The site is the deliverable. ### When to choose them instead - You want the interactive menu itself. Item-level pages with photos, reviews and follower notifications are their actual innovation, and a static menu page is not the same thing. - You want the marketing and the AI phone answering in one bundle with one invoice. Buying those separately costs money and coordination. - You are one location and will stay one location. Their per-location pricing is least punishing at that size, and the lower tier is a modest monthly cost against not having to think about it. ### What the monthly fee buys Popmenu's distinctive product is the interactive menu: individual dishes become pages that can carry photos, reviews and followers, and customers get notified when something they follow comes back on. That is a genuine product idea and it is not something you replicate by writing a menu page in HTML. The higher tiers add marketing automation and an AI phone answering service. If you want those, the monthly cost is buying software and operations, not a website, and the comparison on this page is not the one you should be making. ### Where the maths turns At $299 a month, five years is $17,940 before the ordering add-on, and before the second location. A $3,000 build pays for itself in eleven months against that figure and then costs nothing. Even at their $179 starter tier, the crossover is inside seventeen months. Per-location pricing is where this compounds. A second site is another monthly charge forever; on a custom build it is usually a set of extra pages, quoted once. ### What a custom build does better Structured data, mostly. We ship a linked graph on every page, so your menu, your hours, your services and your reviews are machine-readable in the form search engines and AI assistants actually consume. Platform products tend to emit the minimum that works across all their customers, because that is the sensible engineering choice when you serve thousands of restaurants on one codebase. And speed. A site that is finished files on a CDN is structurally faster than one assembling pages from a database on request, and that gap shows up in Core Web Vitals, which is a ranking input you do not get to argue with. ### Questions **Do I lose the menu photos and reviews if I leave?** Ask them directly, and ask in writing. Menu content you uploaded should be exportable, but review and follower data accumulated on their platform generally is not portable in a useful form. That is worth knowing before you build five years of it. **Can a custom site do item-level menu pages?** Yes, and with better structured data than most platforms emit - each dish can be its own page with Menu, MenuSection and MenuItem markup so search engines can read it. What it will not have is the follow-and-notify social layer, which is a product rather than a markup choice. --- ## Wix (General-purpose website builder) URL: https://altarisdev.com/compare/wix-alternative/ The alternative to Wix is a site you pay for once, but on cost alone Wix often wins: at about $39 a month, a $3,000 build takes over six years to pay back. The reasons to move are speed and structured data - not the monthly fee. If a brochure site is all you need, staying on Wix is a sound decision. Their published pricing: $17 to $159 a month, per site, per month, cheaper when billed annually. Checked 2026-10-31. Outside the headline plan: Business plans sit around $39 a month billed annually, or about $46 monthly. Ecommerce features, third-party apps and removing platform limits push it higher. ### Point by point **Cost, honestly** - Wix: About $39 a month, which is $2,340 over five years. - Altaris: $3,000 once. On cost alone, Wix is cheaper for the first six years. **Speed** - Wix: A page assembled at request time, carrying the builder runtime. Core Web Vitals are a known weak point. - Altaris: Finished files on a CDN. No builder runtime to download, and nothing assembled at request time. **Structured data** - Wix: Basic markup, with more available through apps and manual code injection. - Altaris: A linked JSON-LD graph per page, validated before launch, covering your services, hours, FAQs and reviews. **Moving somewhere else later** - Wix: There is no meaningful export. Whatever you build on Wix stays on Wix. - Altaris: Honestly, much the same: we host and run what we build, so moving elsewhere means a rebuild either way. The difference is the bill, not the portability. **Changing things yourself** - Wix: Excellent. Drag, drop, publish, no developer needed. - Altaris: Content yes, structure no. A new kind of page is development work. ### When to choose them instead - Your budget is under a thousand dollars. This is the honest answer and it is not a close call - a builder subscription is the right tool at that budget, and anyone telling you otherwise is selling. - You need to be live tomorrow. A custom build takes about a week at the very fastest; Wix takes an afternoon. - You want to redesign it yourself on a whim. Drag-and-drop editing is a real feature and a custom site does not give you it. - The site is temporary or seasonal. Paying once for something you will replace in a year makes no sense. ### The honest arithmetic first Most "Wix alternative" pages open by telling you Wix is bad. It is not. At around $39 a month on an annual plan it is $2,340 over five years, against $3,000 for a custom build, which means on cost alone **Wix is cheaper for about the first six years**. If someone is pitching you a custom site primarily as a way to save money on your Wix subscription, the numbers do not support it. Put your own figures into the calculator on our pricing page and you will see the same thing. ### So why move at all Two reasons, neither of which is the monthly fee. **Speed.** A builder assembles your page when it is requested and ships a runtime to do it. A custom site is finished files on a CDN, with no builder runtime to download and nothing assembled when the request arrives. That gap is structural rather than a matter of optimization effort, and Core Web Vitals is a ranking input. **Structured data.** This is the one that actually moves results. Every page we build ships a linked JSON-LD graph describing your business, services, hours, FAQs and reviews in the form search engines and AI assistants consume. On a builder you get the basics, with more available through apps and manual code injection if you know to do it. ### The decision, plainly If you need a presentable site, cheaply, this week, and search is not a channel you compete in - stay on Wix. We will tell you that on the call rather than after you have paid us. If you are competing for search traffic against people doing this properly, speed and structured data are where that is won, and a custom build does both far better than a template. ### Questions **Is Wix actually bad for SEO?** No, and the claim that it is has been out of date for years. Wix sites rank perfectly well for most local businesses. The real limitation is narrower: you have less control over page speed and over the structured data you emit, and both of those matter more in competitive search results than they do in easy ones. **When is it worth moving off Wix?** When search is a real channel for you and you are up against competitors doing it properly, when speed is costing you conversions on mobile, or when the site has become central enough to your business that renting it feels like the wrong arrangement. Not simply because the monthly fee annoys you - on cost alone it takes over six years to come out ahead. **Can you move my existing Wix content over?** Yes. Wix has no clean export, so in practice the text and images are moved across by hand and the structure gets rebuilt properly on the way. That is usually an improvement rather than a cost, because the page structure is the thing most worth redoing. --- # Commercial terms Paid once, never monthly. There is no monthly fee of any kind: not to the studio, and not for hosting, which the studio sets up and runs as part of the service. No commission is taken on orders or bookings, which run through the client's own payment account. Published prices are $1,500 for a small site and $3,000 for a multi-page site with a page per service. Sites with online ordering or booking, and unusually large builds, are quoted per project. The only recurring cost is the domain itself, roughly $11 a year. Costs the studio does not absorb and does not hide: hosted mailboxes on the domain, standard card processing rates on online orders, and development work for changes larger than content. Small content changes - wording, prices, photos - are done free on request. The studio makes no ownership claim and the client does not administer anything: hosting is run by the studio, there is no dashboard and no client login, and the studio does not provide a copy of the build for the client to host elsewhere. Moving to another developer means a rebuild. An optional care plan exists for clients who want agreed response times; nothing requires one. A one-time build is not always the cheaper option, and the studio says so: against a low monthly spend the payback period can exceed five years, in which case staying on a subscription costs less. Cost of ownership: https://altarisdev.com/no-monthly-fees/ Pricing: https://altarisdev.com/pricing/ Terms: https://altarisdev.com/terms/ Privacy: https://altarisdev.com/privacy/ # Note on claims No page-speed figures are published on this site at present. Earlier figures were removed when they could not be reproduced reliably on re-measurement; they will return only with a stated method and date. Where a load time is quoted it means time-to-full-HTML-response, not a Lighthouse score. Every case study published here is earlier work for clients in the United Kingdom. The studio now builds for clients in the United States and has not restaged the portfolio to disguise that; the work is offered as evidence of how it builds, not of where its clients are. The studio is in Kosovo and works with clients in the United States; it does not claim a US office. The contracting entity is InnovX L.L.C., registered in the Republic of Kosovo, company number 812114164.