The page is done. It says who you are and what you do, and now it needs a way for someone to actually get in your diary. The assumption at this point is usually that you have run out of road — a booking system means availability, timezones, double-booking, reminder emails, and none of that happens in a file sitting on a static host. That assumption is right about the calendar and wrong about the page. Scheduling tools solved the hard half years ago and then published it as an embed, precisely so it could be dropped into sites they do not control. What is left for you is one snippet and a decision about where the page should live once a stranger's meeting is riding on it.
Try it now
Drop a file — get a private link in seconds. No sign-up.
Drop an HTML, ZIP, PDF, PNG or JPEG file, or click to choose.
One file, or a ZIP bundle. Max 3 MB.
Up to 3 MB, link self-destructs after 7 days. Sign up free to keep links forever, password-protect them, and store more.
Pick the scheduling tool first, because it owns the difficult part. Cal.com, Calendly, SavvyCal and Google Calendar's appointment schedules all publish an embed — a script or an iframe you paste into your HTML. Behind it sits the thing you should not build: reading your real availability, doing timezone arithmetic correctly, refusing a slot two people clicked at once, and sending the reminder that stops the no-show. Check what each one charges and how many bookings it allows on the tier you would be on — those numbers move, so read them on the day rather than trusting an article.
Paste the embed into your page, and know why it works. The snippet talks to the provider's servers from the visitor's browser, so nothing runs on your side — the page stays a static file. Our viewer keeps that path open on purpose: third-party scripts, iframes and outbound API calls all load, because a page you wrote should behave the way it does on any other host. What a page with no backend still cannot do is keep a secret or enforce a rule of its own; a booking embed needs neither, which is exactly why it fits.
Then upload the page — the .html file, or a ZIP of a built folder — and you get a link back in seconds. This matters more here than on a page nobody acts on: your hours change, your offer changes, and the link is already in someone's calendar invite. Replace the contents at the same address instead of minting a new URL, with every upload kept as a numbered version. The link is unguessable and no-index by default, so a page for one client stays that way; make it search-indexable instead if it is meant to be found. On Studio ($14.99/mo) it runs on your own domain, which reads differently on a page asking someone to commit their time.
Yes, and it is the ordinary way to do it rather than a workaround. Scheduling providers ship an embed — a script tag or an iframe — designed to be dropped into pages the provider has no control over, which is the whole point of the format. The visitor's browser talks to the provider; your page does nothing but hold the snippet. The distinction worth carrying is between a page that hosts a form and a page that processes one: the first is static and always was, the second needs a server. Booking is the first.
The calendar, and you should be glad it is not yours. Real availability has to be read from a live source, times have to be converted correctly across zones and daylight-saving changes, two people clicking the same slot within a second of each other have to be resolved, and a reminder has to leave at the right hour whether or not anyone is awake. That is a real system with real failure modes, and every one of them is visible to the person who turned up at the wrong time. Rent it. What you keep is the page.
It depends on what the booking is attached to rather than on a feature list. Cal.com is open-source and self-hostable, which matters if you want the data on your side. Calendly is the one most recipients will already recognise, which lowers the friction of the click. SavvyCal leans on letting the invitee overlay their own calendar, which is pleasant when you are booking peers rather than customers. If your whole working life is already in Google Calendar, its own appointment schedules avoid adding another account entirely. Any of them embeds the same way, so this is reversible — swap the snippet and re-upload.
Yes. The viewer's content policy allows third-party scripts, iframes and outbound calls over HTTPS, which is what an embed needs — the deliberate position being that a page you wrote should behave the way it does anywhere else you might have put it. If an embed does not appear, the cause is almost always inside the snippet rather than the host: a placeholder link left in from the docs, or a script tag pasted into the head when the provider expected it where the widget should render.
Yes, and that is the default. Every link is unguessable and carries a no-index tag, so a scheduling page meant for one client, one cohort or one campaign does not surface in search. Add a password when the slots themselves are sensitive — it is free on every plan. If instead you want the page found, a document can be opted into search-engine indexing explicitly; the point is that it is a decision you make rather than one made for you.
Most scheduling tools can collect it themselves, and that is usually the shorter path because the booking and the charge stay in one place. If you would rather run the payment separately, the same reasoning applies to it as to the calendar — a hosted payment link or a client-side checkout works on a static page, and we wrote that up in full. Neither route needs a backend from you.
No card to try, no sign-up to get a link. Sign up free to keep links forever, password-protect them, and store more.