Guide

Dental website SEO: the technical foundations most sites get wrong

A plain guide for practice owners.

Rainey Dental Partners · October 8, 2026 · 12 min read

Dental website SEO is the quiet technical work that lets a practice be found. It covers which pages exist, what each page is called, how those pages connect, how fast they open on a phone, and what the site tells a crawler it may read. A beautiful site can still be invisible when that layer is thin. Patients search for a service and a place, and the page that answers has to be one a search engine is allowed to show.

This guide is that foundation, written for an owner who does not want a technical lecture. It is what to check, and what to ask the company that built the site. The later sections are the same list a practice can hand across the desk.

On this page.

What is different about dental website SEO in 2026.

The short version, before the detail:

The rest of this section is the detail, for whoever manages the site.

In 2026 a patient can see an answer before choosing a link. Google's AI Overviews and AI Mode documentation describes Overviews as a short summary on the results page, and AI Mode as the place for longer questions. Both are still Search: a page must be indexed and eligible to show a snippet, with no extra technical requirements. A direct answer on the practice's own page is what those features can quote. The patient side of this is in how dentists are losing patients to AI search.

The same questions now show up in ChatGPT, Claude, Perplexity, and Gemini. Whether they can read the site depends partly on robots.txt, the public file that tells automated visitors what they may fetch. OpenAI's crawler documentation keeps two jobs separate. OAI-SearchBot surfaces a site in ChatGPT search. A site that blocks it is left out of those answers, though a title and a link can still appear.

GPTBot is OpenAI's other robot. It collects pages that may train models. Blocking GPTBot does not, by itself, remove a site from ChatGPT search. A blanket block often closes the search robot along with the training one. The same checks, shorter, are in our checklist for showing up in AI search.

Anthropic's help page, names three robots. ClaudeBot collects pages that may train models, so blocking it is a training choice. Claude-SearchBot indexes pages for search answers, and Claude-User fetches a page when someone asks Claude a question. Blocking either of those can reduce whether Claude retrieves the practice.

Perplexity's crawler documentation says PerplexityBot surfaces and links sites in Perplexity search, and that it does not train foundation models. Google-Extended is a different switch. Google's crawler documentation says it is not a separate crawler. It is a robots.txt token for training future Gemini models and for grounding Gemini's answers, and Google states it does not affect inclusion in Google Search and is not a ranking signal.

AI Overviews and AI Mode follow Googlebot and the snippet rules, not the Google-Extended switch. An llms.txt file is an emerging convention, described at llmstxt.org: a short plain-text overview for language models, published beside robots.txt. Google's guide to generative AI features says Google Search ignores these files. Keeping one neither harms nor helps rankings in Google Search, including AI Overviews and AI Mode.

Google also shipped ordinary ranking updates this year. Its Search status dashboard lists core updates on March 27 and May 21, 2026, and spam updates in March, June, August, and September. Google's core update documentation says these changes are broad, and the standing advice is helpful, reliable, people-first content. On health topics, Google's people-first content guide describes E-E-A-T (experience, expertise, authoritativeness, and trustworthiness) and says E-E-A-T itself is not a specific ranking factor.

The map listing still sits beside the website. Google's Business Profile guidelines say the practice name should match the website and the sign. Google's local ranking tips say results rest on relevance, distance, and prominence, and that incomplete information makes a profile less likely to show. Use the same name, address, and phone on the profile and on the site. Each service patients search for should have a page waiting after the map.

One page for each service.

Patients search for veneers, an implant consult, Invisalign, or a dentist who can see them this week. A homepage that mentions every service in one paragraph gives Google one page for all of those searches. That page is usually the wrong one. Give each real service its own page, with a plain heading and a direct answer near the top.

That map of pages is the site architecture. Internal linking is how the pages point at one another, so a patient on the veneers page can reach the consult, and a crawler can find the same path. Orphan pages, the ones nothing links to, are easy for both to miss. Our technical standard starts from the same rule: every service gets its own page.

A specialty practice needs the same clarity. A periodontist, an implant practice, a cosmetic dentist, and an orthodontist each answer different searches, and each page should say plainly which one it is. Planning those pages around one practice, rather than a template, is what makes a site custom, and it is where good dental website design begins. What the page then does for a visitor is in what a dental website needs to convert new patients.

Titles and meta descriptions.

The title is the browser-tab line, and often the blue link in Google. The meta description is the short summary under that link. Both sit outside the main text, which is why they get rewritten in a hurry. Google's title link documentation says Google may write its own link text when a title is vague or stuffed.

A title that already matches how patients search is doing a job. Replacing a specific line, such as veneers in the practice's town, with a slogan removes the words patients type. The page then fits that query less well. Keep a copy of titles that already earn visits before anyone changes them. A simple written record of every title, like the one described in how titles and descriptions are protected, makes that easy.

Structured data, in plain English.

Structured data, often called schema, is a label in the page's code. People do not see it. It says this is a dental practice, here are the address and the phone, this page is this service, and these are the questions it answers. Google's local business documentation asks for the most specific LocalBusiness type, and on schema.org that type is Dentist.

Google's generative AI guide, linked above, says schema is not required for AI Overviews or AI Mode, and that there is no special schema for those features. It still helps a page qualify for richer details in ordinary Search, and it keeps a machine from guessing the hours. Ask which types are on the site, and have a person confirm the address, phone, and hours before they publish.

Speed, starting on the phone.

Core Web Vitals are three public measures of how a page feels to a real visitor. Largest Contentful Paint is how quickly the main content appears. Interaction to Next Paint is how quickly the page responds after a tap. Cumulative Layout Shift is whether the layout jumps while it loads.

Interaction to Next Paint replaced First Input Delay as a Core Web Vital on March 12, 2024, which web.dev announced that day. Current Web Vitals guidance, and the INP article, call a good experience an LCP within 2.5 seconds, an INP of 200 milliseconds or less, and a CLS of 0.1 or less. Read those at the 75th percentile of real visits, on phones and desktops. A test on office Wi-Fi is not that report.

Patients usually arrive on a phone, so the mobile version has to be fast. Ask for the Core Web Vitals report in Search Console, for the homepage and the main service pages. To see what fast, well-built sites look like beyond a score, browse a portfolio of dental websites or this roundup of strong dental websites.

What search engines are allowed to see.

robots.txt is a text file at the root of the domain. Google's robots.txt introduction explains that its crawlers read the file before they fetch pages. A canonical tag is a line in the page that names the one official address, so two similar URLs do not split the credit for the same page. A noindex instruction tells Google not to list that URL in search results.

Drafts, staging copies, and old previews should carry noindex, or stay blocked, so a half-finished site never sits beside the real one. Ask to see the live robots.txt, and ask whether the build address is closed to search engines. On our builds the in-progress site stays sealed until launch, which is the crawl control on the technical page. A one-line mistake is quiet. The site looks finished, and Google has been told the wrong thing.

The sitemap, and who should hold Search Console.

A sitemap is a machine-readable list of the pages the site wants found. Google's sitemap documentation describes submitting that list so Google can discover the URLs. Google Search Console is the free account where an owner sees which pages are indexed and which queries bring people in. The practice should hold owner access, and a company can be a user.

Access in the company's hands is not the same thing as the practice being the owner. The guide to whether you own your dental website covers that login, and why it matters during a move. We register the sitemap at launch and keep the Search Console connection open, which is how we keep Google's map of the site current.

Keeping your SEO through a redesign.

A redesign is the usual way a practice loses rankings it already earned. Pages get removed. Addresses change with nothing telling Google where they went. Titles that matched real searches become slogans. The history Google had learned can disappear over a weekend.

A permanent redirect, the kind called a 301, is the instruction that an old address has moved to a new one. Google's documentation on 301 redirects describes that signal. Redirects are only half of the job, because the title and the substance of the page have to move as well. That substance is what Google had trusted.

A migration map is the list made before launch. It names every old URL, what it becomes, which title and which content carry forward, and where a redirect is required. A person should approve that list before the old site is switched off. If the site is simply offline in the gap, patients and Google both meet a dead address, which is the subject of what happens when a dental website goes offline.

Ask for that map in writing. The questions in choosing a dental website company include it, and the move itself is the subject of dental website hosting. Finished launches are in our case studies.

A checklist you can hand over.

Ask these in writing. A useful answer names a page, a file, or a person. A vague assurance that everything is handled is not an answer.

  1. Does the practice own Google Search Console? Yes. The practice should be an owner in Google Search Console, on an email the practice controls.
  2. Does every service have its own page? Yes. Every service patients search for should have its own page, with a heading and a direct answer, not only a mention on the homepage.
  3. Do the name, address, and phone match the Google Business Profile? They should. The practice name, street address, and phone on the website should be the same as on the Google Business Profile.
  4. What does our robots.txt block? Read the file. Ask whether OAI-SearchBot, PerplexityBot, and Claude-SearchBot are blocked, and whether Google-Extended was blocked on purpose.
  5. Are drafts and staging copies hidden from Google? They should be. Staging sites, drafts, and old previews should carry noindex, so Google does not list them beside the live site.
  6. Does each page name its official address? It should. Each important page should name its official URL with a canonical tag.
  7. What happens to our old URLs in a redesign? Every old URL needs a destination, a title decision, and a permanent redirect if the address moves. Ask to see that list before launch.
  8. Who watches rankings after launch? A named person. Someone should watch rankings after launch, and the practice should be able to open Search Console for the life of the site.
  9. Have our ranking titles been recorded? They should be, before anything changes. Ask for the current ranking titles before a redesign touches any title that already brings patients in.
  10. Is the site fast on a phone? Ask whether the homepage and main service pages meet Google's good mobile thresholds: LCP within 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.
  11. Will the old site stay online until launch? It should. The current site should stay online until the new one launches, so patients and Google move from a working site to a working site.
  12. Who approves the migration map? A person, by name. Someone should review the migration map before launch, and the practice should know who that is.

How we handle the move.

Before launch, our proprietary migration mapping tool inventories every page Google currently ranks for the practice. It cross-checks every old URL and ranking keyword against the new site, carries titles and content forward deliberately, and adds permanent redirects where anything moves. A person reviews and approves the map before launch. Ranking titles are marked protected, and the live site is checked against the record after every publish.

We watch rankings for 90 days after launch, and we keep watching search visibility through Search Console for the life of the site. The full standard is on our technical page. It is an account of every URL, reviewed by a person and watched after the site goes live.

Questions dentists ask.

What is dental website SEO?

Dental website SEO is the technical work that lets Google and other answer tools find a practice and understand its pages. It covers structure, titles, structured data, speed, crawl rules, the sitemap, and old addresses in a redesign. It sits under any later content work.

Does every dental service need its own page?

Yes. Patients search for a service, such as veneers or implants. A page for that service gives Google something specific to show, and it gives the patient a direct answer.

Will a redesign hurt my Google rankings?

It can. Rankings drop when pages disappear, when an address changes without a permanent redirect, or when a ranking title is rewritten. A migration map, reviewed before launch, accounts for every old URL.

Who should own Google Search Console?

The practice should. Search Console is the free Google account for indexing, queries, and the sitemap. A web company can be a user, and it should not be the only login.

Do I need a special file to appear in ChatGPT or Google AI Overviews?

For Google, no. A page needs to be indexed and eligible for a snippet, and an llms.txt file neither helps nor harms Google rankings. For ChatGPT search, allow OAI-SearchBot. A robots.txt rule for one system does not control the others.

What should I ask before a redesign?

Ask for a migration map. It should name every current URL, what happens to it, which titles carry forward, and where a permanent redirect goes. Ask who reviews the map before launch, and who watches rankings after.

Have the foundations checked.

Book a quick consult The technical standard