How to Build a Public Speaker Website Without Code
To build a public speaker website without code, write the page for the person who books you rather than for the audience: talk topics, video of you on stage, past events, a downloadable bio and headshot, and one enquiry form. An AI builder produces that page in about a minute and publishes it to a real address.
Speaker sites fail in a specific way. They are written as personal biography when the reader is a programme director with eleven candidates and forty minutes. This guide is about building the version that gets you shortlisted.
What does an event organiser check first?
Organisers work through a mental checklist, roughly in this order, and they abandon a site the moment one item is missing and they have another tab open.
- Can I see you speak? Video of you on a stage, in front of an audience, in the first screen. Not a studio piece to camera. Thirty seconds decides it.
- What do you talk about? Two to four named talks with a title and a three-line description, not a list of themes. A title is bookable; "leadership and change" is not.
- Who has booked you before? Event names and logos. This is the credibility line and it does more work than any adjective about your style.
- Can I take your details right now? A downloadable bio in two lengths, a high-resolution headshot, and your correct name spelling. Organisers assemble programmes at eleven at night and will not email you for a photo.
- How do I ask about a date? One form or one email address, above the fold on mobile.
Notice what is absent: a blog, a newsletter, and a long biography. All fine to add, none of them on the path to a booking.
What should the prompt say?
The builder needs your talks, your proof, and the order of the page. Everything below is content only you have, so write it into the prompt rather than accepting placeholders.
Build a speaker website for [name], who speaks about [topics]
to [audience type].
Home page in this order:
1. Hero: name, one-line positioning, an embedded video of a
talk, and a "Check availability" button.
2. Speaking topics: [3 talks], each with a title, a 3-line
description, and the format (keynote / workshop / panel).
3. Past events: logo or name grid of [list events].
4. About: short bio, headshot, and links to download the
long bio, the short bio, and a high-resolution photo.
5. Testimonials: [2-3 quotes with name and event].
6. Enquiry form: name, organisation, event date, format,
audience size, budget range, message.
Sticky "Check availability" button on mobile.
Style: dark, one accent colour, large type, video-first.
The budget range field is the one people cut and should not. It filters out enquiries that were never going to happen and saves both sides two emails, and it signals that you are booked professionally rather than persuaded case by case.
Which version of the site fits where you are?
A speaker at three events a year and one at forty need different pages. The table compares the versions and what each one asks of you.
| Version | Fits | What it costs you |
|---|---|---|
| One page, everything on it | Speakers building a first credible presence | A quick build at 6 credits. Nothing to maintain, and it scales to about six talks |
| Page plus per-talk pages | Speakers with distinct talks aimed at different industries | A platform build: 12 credits for the first three pages, 3 for each after. Better for search, more to keep current |
| Site plus a media and press area | Established speakers with book launches and press coverage | The same build plus real asset hosting and someone to maintain it |
Most people should build the first row and stay there for a year. A single strong page that loads fast beats six thin ones, and the second row is worth it only when different industries genuinely need different landing pages.
Where should the video actually live?
Video is the highest-value element on the page and the easiest one to get wrong technically. Three options, and only one of them is usually right.
Embed from a video platform. Upload the talk to a hosting service and embed the player. It streams properly, it adapts to the viewer's connection, and it costs you nothing to serve. This is the default and it is the right default.
A short muted clip in the hero. Fifteen seconds of you on stage, autoplaying without sound, with the full talk embedded below. Very effective, but you need the clip cut before you build, because a builder cannot produce it for you.
Self-hosted video files. Avoid unless you have a reason. A large file served directly makes the page slow on the phone connection of the organiser deciding about you.
Say which route you want in the prompt. The generated page will have a player-shaped hole either way, and filling it with the right thing is your job.
How do enquiries reach you, and what happens next?
An enquiry form that renders but sends nothing loses bookings silently, which is the most expensive failure this page can have. Connect Resend and each submission arrives in your inbox. The wiring is covered in the guide to adding an AI website contact form.
Two edits repay themselves quickly. An automatic reply that confirms receipt and states your typical response time, because organisers are comparing responsiveness as well as content. And a second recipient address if an agent or assistant handles your calendar.
If you also collect an audience list, a signup field is a separate job from the booking form and should not share it. The pattern is covered in the guide to building a newsletter signup.
What happens after the email arrives matters as much as the form. Organisers work to programme deadlines, and a reply the same day frequently decides a shortlist that a reply next week would have missed. Keep a short template with your fee range, your travel requirements, and two questions about the audience, so answering takes four minutes rather than an evening.
Submit your own form once a quarter. Connectors get disconnected, addresses change, and a silent form is invisible until you notice that a busy season produced no enquiries at all.
What does it cost, and can you keep the code?
A single-page speaker site is a quick build at 6 credits, and each later change is a 3 credit edit. The free tier gives 5 starter credits, Pro is $25 per month with 200 credits, and Business is $99 per month. Hi-Fi mode doubles both numbers and is defensible here, since this page is judged visually within seconds.
Published projects get an address like yourname.zugo.run, and a custom domain is worth connecting before the site appears on a conference programme. Every build is booted in a sandbox first, and one that fails to render is reported as a failure rather than delivered as working, which lowers the risk of a dead page during a booking window without removing it.
The code exports to GitHub as a normal repository, so nothing here is trapped. If your work is visual as well as spoken, the guide to an AI portfolio website covers the gallery-led sibling of this page.
When will a website not get you booked?
Honest limits, because the site is the smallest part of a speaking career.
No video yet. Without footage of you speaking, the page cannot do its main job. Record a local talk on a phone with decent audio and use that. A rough real clip beats a polished promise.
Speaker bureaux and agencies. If most of your bookings come through a bureau, their profile is the thing organisers see and your site is a supporting document. Build accordingly and keep it short.
Heavy media requirements. Press kits with dozens of high-resolution assets, embargoed materials, and per-event downloads need asset management, and a generated page is not that.
The bookings themselves. A page does not create demand. Talks given, people met, and a topic worth a slot create demand, and the site converts the interest that already exists.
If you have a clip, three talks with real titles, and two past events to name, an evening is enough to have a page an organiser can act on. Write the first prompt at zugo.dev.