What this prompt does
This prompt generates a complete dental practice website spec and code scaffolding from six variables: practice name, services list, target patients, location, service count, and your target framework. The template is opinionated by design — it bakes in industry-specific anti-patterns (no graphic procedure imagery, no cold clinical grays, no bloated booking forms) and enforces a calming visual language of white, teal, and clean blue. That specificity is the point: you are not describing a generic medical site, you are describing a dental conversion funnel where visitor anxiety is the primary conversion blocker.
The output covers all nine sections sequentially: hero with visible phone number, service cards, interactive before/after slider, team bios, reviews integration, insurance checker, a lean booking form, Google Maps embed with LocalBusiness schema, and framework-specific code for the three highest-effort components. The prompt forces concrete deliverables rather than vague suggestions, which means you get implementable output rather than a mood board.
The [framework] variable is where real leverage lives — swap in React, Vue, Alpine.js, or Blade and the code output shifts to match your stack, keeping all nine sections and their content constant.
When to use it
- You are building or redesigning a dental clinic site and need a conversion-focused layout, not a blank canvas.
- A client has specific services (Invisalign, implants, teeth whitening) and you need structured content for each service card without starting from scratch.
- You need LocalBusiness schema markup generated alongside the HTML rather than writing it separately.
- You are an agency prototyping for a new dental client and want a first-pass spec to review in the discovery call.
- You are migrating a practice from an outdated site and need a modern component checklist with before/after gallery logic already specified.
- You want the booking form constrained by the anti-pattern rule baked into the template — the prompt explicitly blocks multi-field intake forms so the AI does not invent a 12-field version nobody fills out.
Example output
Practice: Riverside Family Dentistry
Services: General checkups, Invisalign, teeth whitening, emergency dental
Target patients: Families with children, adults seeking cosmetic work
Location: Austin, TX
Service count: 4
Framework: Alpine.js
--- HERO ---
Headline: "Comfortable Care in the Heart of Austin"
Subline: "Same-week appointments. Insurance accepted. Zero judgment."
CTA: [Book Your Visit] | Call: (512) 555-0192
--- SERVICES (4 cards) ---
1. General Checkups — "Twice a year keeps the drill away." | From $0 with insurance
2. Invisalign — "Straighter teeth, zero metal." | From $3,200
3. Teeth Whitening — "Four shades brighter in one visit." | From $299
4. Emergency Dental — "Seen same day, always." | Call for availability
--- BEFORE/AFTER SLIDER (Alpine.js) ---
<div x-data="{ pos: 50 }">
<input type="range" x-model="pos" min="0" max="100" />
<!-- before/after images positioned via clip-path: inset(0 {100-pos}% 0 0) -->
</div>
Pro tips
- Set
[target_patients]precisely — "families with children under 12" produces different copy tone and imagery guidance than "adults 30-55 seeking cosmetic work." The prompt feeds this variable into hero copy and service description emphasis, so a vague value like "everyone" collapses the specificity the template is built around. - If your practice does not publish price ranges, pass "price ranges: on request" in the services variable — a well-prompted AI model will typically suppress pricing from cards rather than inventing numbers, but always verify the output before publishing.
- Pair this with a Google Business Profile audit before deploying the LocalBusiness schema output; NAP inconsistency between the generated schema and your GBP listing is a local SEO liability the prompt cannot detect or correct.
- For the before/after slider, explicitly state
[framework]: React with Tailwind(not justReact) to get a properuseStateimplementation — an underspecified React instruction often produces a DOM-manipulation version that fights your component model. - Run the generated insurance checker section past the practice manager before publishing — insurance acceptance lists change frequently, and an outdated list on the site erodes patient trust faster than no list at all.
