The prompt to paste into Bolt
Put your intended live address in the bracket, then paste the whole prompt into Bolt’s chat. The audit comes first and edits wait until you reply, which keeps Bolt from spending tokens on changes you did not ask for.
I am about to publish this Bolt project at [https://www.example.com]. Carry out a launch audit for search engines. This is an audit, so do not edit any file until I reply "go ahead".
A. HOW PAGES ARE DELIVERED
1. Identify the framework and build tool in use, from package.json and the config files.
2. For each public page, say whether the finished HTML contains the page's main heading, body copy and navigation links before any JavaScript runs, or whether the page is an empty shell filled in by the browser. If you cannot tell from the code, say "unknown" and tell me which URL to test after publishing.
3. Say how page URLs are produced (file-based routes, a router library, hash routes) and whether every public page has its own path rather than a hash fragment or an in-page state.
B. PER-PAGE ESSENTIALS
4. For each public page give: URL path, title, meta description, one H1 and canonical URL. Flag any value that is duplicated on another page, still describes a template or is likely to be truncated in search results. Treat character counts as a rough guide, not a pass/fail rule.
5. Report the Open Graph title, description, image and URL for each page, and flag any pointing at a preview or bolt.host address.
C. SITE-LEVEL FILES AND DOMAIN
6. Say whether /robots.txt exists, what it allows and blocks, and whether it points to the sitemap.
7. Say whether an XML sitemap exists. List which URLs it contains and flag any that are private, redirected or on the wrong domain.
8. Find every hard-coded reference to a preview address, bolt.host, localhost or a placeholder domain.
9. Tell me which redirects the project needs so that only one version of the domain is used: http to https, and www or non-www. If these are set in hosting rather than code, say so and tell me what I must check there.
D. QUALITY CHECKS
10. List links that are dead, point to #, or are built as buttons with no real address.
11. List images missing alt text and images over about 500 KB.
12. Say whether a made-up address returns a real 404 status and a helpful page.
OUTPUT
Give a table with columns: item, finding, evidence (file and line, or "not available from the code"), confidence (Confirmed, Not confirmed or Needs live check) and priority (High, Medium, Low). End with a short, ordered list of the changes you propose, separated from the audit itself. Do not claim that any change will cause indexing or improve rankings.
WHEN I SAY "go ahead"
Make only the approved changes. Keep the design unchanged. Use UK English for any copy. Afterwards list each file changed and how.Bolt’s help centre has guidance on prompting effectively, including customising knowledge at account, project or team level. If you launch several sites, saving your standing SEO rules there is worth considering.
When to use it
Run it when you are about to publish or move to a custom domain, and again after any large rebuild. It suits sites with a set of marketing pages, such as a service business, a product site or a portfolio.
Bolt can publish to a free .bolt.host address, and its help centre says custom domains need a paid plan. That makes the domain section important: a site that launches with metadata pointing at the temporary address sends search engines mixed signals.
If your project is mainly a logged-in application, only the marketing pages matter for this prompt. See the site-structure prompt if you have not yet decided which pages should be public.
What the prompt checks
The four lettered sections give Bolt a clear order of work:
- A. Delivery. Whether the finished HTML carries the content, or whether visitors and crawlers receive an empty page that JavaScript fills in. Bolt is asked to say “unknown” rather than guess.
- B. Page essentials. Titles, descriptions, headings, canonicals and sharing tags, page by page.
- C. Files and domain. Robots, sitemap, leftover temporary addresses and the redirects that keep a single domain version.
- D. Quality. Dead links, heavy images and 404 handling.
The output format asks for evidence and a confidence level on every row. A finding supported by a file and line is far more useful than a general statement that the site “looks fine”.
Mixing the two invites Bolt to rewrite pages while it investigates. Waiting for “go ahead” lets you refuse changes to wording you have already approved.
What Bolt may still get wrong
- It cannot see the live response. Bolt reads project files. Redirects, headers and domain settings applied by the host may not appear there, which is why the prompt asks it to say when something sits outside the code.
- Rendering claims need testing. We have not verified which rendering approach every Bolt project uses, and it varies by framework. Whatever Bolt reports, open the published page’s source and check that the main heading and copy are present.
- Metadata can regress. A later prompt to restyle a page can overwrite its title or canonical. Re-run the audit after significant changes.
- It may overstate fixes. A sitemap that exists is not proof that Google has processed it.
- Nothing here guarantees indexing or rankings. It removes technical obstacles only.
Test the published site with Google Search Console’s URL inspection once the domain is verified. Why vibe-coded websites don’t get indexed explains how to interpret what you see.
A worked example
This is an illustrative scenario, not a client result. Imagine a Bolt-built portfolio for a freelance photographer, due to launch at https://www.harbourlightphoto.example.
Bolt’s audit table might report five public pages, a title of “Vite + React” on every one, and no sitemap. It might also flag that the home page’s sharing image uses a .bolt.host address, and mark the delivery question as “unknown, test the published home page”.
You reply “go ahead”, limited to unique titles and descriptions, a sitemap and the sharing image address. You then publish, view the page source on the real domain and confirm the heading and copy appear in the HTML. If the source shows an empty container, the next step is a conversation about rendering with a developer, not another prompt.
Next step: have the live site checked
The prompt audits files. A launch also needs the live domain tested for how it is crawled and whether pages are eligible for indexing. Our Bolt SEO service reviews the published site and gives you a prioritised list.
Book a site review and we will check the live pages for you, or send us a message if you would like to describe the problem first. You can also browse the rest of the resources hub.