Engineering standard

Technical.

Most of what you pay a web company for is invisible. This page makes it visible: the behind-the-scenes work on every site we build, migrate, and maintain, so your rankings hold and your site keeps running while you run your practice.

Document
RDP / ES — 01
Discipline
Build · Migrate · Maintain
Applies to
Every site we manage
Status
In force

The seven disciplines behind every site we build

We take the responsibility of carrying a practice's web presence seriously. The disciplines below are not add-ons or tiers. They are the standard, applied to every site that leaves our shop.

A note on how we work: we use AI where it makes the work more thorough, checking thousands of details a person would have to sample. It works under supervision. Machines for coverage, people for judgment, and nothing ships without human review.

  1. 01Site architectureBuild
  2. 02Structured dataBuild
  3. 03PerformanceBuild
  4. 04The migration mapMigrate
  5. 05Crawl controlMigrate
  6. 06The sitemapMigrate
  7. 07Monitoring & upkeepMaintain

Part I — Build

How the site is put together

01

RDP / ARC

Structure

Every service gets its own page.

Patients do not search for your homepage. They search for veneers, implants, emergency dentist near me. So every service your practice offers gets its own page: written by a professional, structured with proper headings, and linked so both patients and search engines can move through the site naturally. The practice earns each of those searches on a page built to answer it.

Underneath, the site itself stays deliberately lean. No page-builder frameworks, no plugin stacks that break with every update, nothing between your patient and the page. That structural simplicity is why our sites are fast, and why they stay fast years after launch.

Where AI helps

Research coverage. Before a single page is planned, we analyze how patients in your area actually search and what your competitors rank for, at a depth a manual audit would only sample. Your architecture is drawn from that evidence, then designed and approved by people.

Common questions

Why does every service need its own page?

Because that is how patients search. Someone looking for veneers types veneers, not dentist homepage. A dedicated, well-written page for each service is how a practice earns that search instead of losing it to a competitor.

Do you write the service pages?

Yes. Professional copywriting and keyword research are part of every build. The pages arrive written, optimized, and reviewed, never as templates for you to fill in.

02

RDP / SCH

Structured data

We tell Google exactly what your practice is.

Search engines do not see your site the way a patient does. They read a hidden layer called schema markup: structured labels that say, in Google's own vocabulary, this is a dental practice, here is its address and hours, this page describes this service, these are the questions it answers. Pages Google can understand precisely are pages Google can present confidently, in map results, in rich listings, in the answers patients see first.

Because schema is invisible in a browser, it is one of the most commonly skipped pieces of technical work in our industry. We treat it as part of the build: practice-level markup, per-service markup, and question markup on pages like this one. View this page's source and you will find it practicing what it preaches.

Where AI helps

Schema has to be complete, page-specific, and valid against Google's requirements, which is exacting, repetitive work that machines do without fatigue. AI drafts and validates the markup for every page. A person confirms every fact inside it before it ships, because your hours and address are not things to guess.

Common questions

What is schema markup, in plain English?

A label, written in code, that tells search engines exactly what a page is: this is a dental practice, here are its hours, this page answers these questions. People never see it. Google reads it and rewards pages it can understand.

How do I know the schema on my site is right?

We validate it against Google's own requirements before launch, and a person on our team confirms the facts inside it, your hours, your address, your services, before it ships.

03

RDP / PRF

Speed

We build fast sites and keep them fast.

Google measures your site's real-world speed with a set of scores called Core Web Vitals: how quickly the page appears, how soon it responds to a tap, whether it shifts around while loading. Those scores affect rankings directly, and they decide whether a patient waits or leaves. We build to those measurements, not to how a site feels on the designer's laptop.

In practice that means every image converted to modern formats and sized for the screen requesting it, content delivered from servers physically near your patients, pages that load what is visible first, and no bloated plugin machinery dragging behind the scenes. Mobile first, always, because that is where your patients are.

Where AI helps

Tirelessness. Speed is not a launch-day achievement, it is a property that erodes if nobody watches it. Automated checks measure our sites the way Google does, on an ongoing basis, and flag regressions to our team before anyone else would notice them.

Common questions

Why does speed matter for a dental website?

Two reasons. Patients leave slow sites before they see them, usually within seconds, and Google measures speed directly when deciding what to rank. A fast site earns both the visit and the position.

Will my site be fast on phones?

That is where we aim first. Most patients find a practice on their phone, so every site is built and tested mobile-first, with images sized for the screen actually viewing them.

Part II — Migrate

How your rankings survive the move

04

RDP / MIG

Rankings

The migration map protects your rankings when your site changes.

This is the discipline we are most proud of, because it is where practices get hurt most often. Your current site has pages Google has learned to trust over years. A careless redesign throws that history away, and rankings built over a decade can vanish in a weekend. Most companies handle this with a handful of redirects and hope.

We run a migration map on every client before launch. We inventory every page Google currently ranks for your practice and account for each one deliberately: the URL handled, the titles and keywords carried forward, the content preserved or improved, permanent redirects where anything moves. Simple 301 redirects alone are not enough; the substance Google trusted has to survive too. Then we watch your rankings for 90 days after launch to confirm the move held.

Where AI helps

Completeness. A person auditing an old site checks the pages they think matter. Our tooling crawls everything, cross-checks every old URL and ranking keyword against the new site, and refuses to let anything fall through unnoticed. A person reviews and approves the finished map before launch.

Common questions

Will a redesign hurt my Google rankings?

Not when the migration is mapped. Rankings drop when pages Google trusts disappear or lose their content in a redesign. We inventory every ranking page before we build and preserve each one deliberately, then watch your rankings for 90 days after launch.

What happens to my old pages and links?

Every old URL is accounted for. Pages that earn a place in the new site are rebuilt and improved. Anything that moves gets a permanent redirect, so old links, bookmarks, and Google results all land in the right place.

05

RDP / ROB

Crawl control

We control what Google is allowed to see.

Every site carries a small set of instructions for search engines: a robots file that says what may be crawled, and canonical tags that name the one official address for every page. Done wrong, these quietly split your search authority across duplicate pages, or worse, let Google index a half-finished draft next to your real site.

While your new site is in progress, it stays sealed off from search engines entirely, so Google never sees drafts, duplicates, or work in review. On launch day the seal comes off in the same motion the site goes live, and Google meets your new site once, complete, at your own domain.

Where AI helps

Verification. Crawl rules fail silently; a site can look perfect while telling Google the wrong thing. Automated checks confirm before and after launch that every page carries the instructions it should, so a one-line mistake never gets the chance to become a rankings problem.

Common questions

Why is my in-progress site not visible on Google?

By design. While your new site is being built and reviewed, it is marked off-limits to search engines so Google never sees drafts or duplicates. The day it goes live at your domain, it opens to search engines cleanly.

What is a canonical tag?

A line of code that names the one official address of a page. When similar pages exist, it tells Google which one carries the credit, so your search authority stays concentrated instead of split.

06

RDP / MAP

Indexing

We keep Google's map of your site current.

A sitemap is the machine-readable index of every page your site wants found. We generate it, register it with Google Search Console at launch, and keep it current with every change we ship, so new pages are found and indexed in days, not whenever Google happens to wander by.

That Search Console connection stays open for the life of the site. It is how we see your practice the way Google sees it: what is indexed, what is ranking, what Google flagged, long before any of it would show up as a problem you could feel.

Where AI helps

Consistency. The sitemap, the crawl rules, and the pages themselves have to agree with each other at all times. Automated checks confirm they do after every single change, which is the kind of bookkeeping humans are honestly bad at and machines never tire of.

Common questions

Do you submit my site to Google?

Yes. Your sitemap is registered with Google Search Console at launch, and we keep that connection so we can see your site the way Google sees it.

What happens when pages are added later?

The sitemap is updated with every change we ship, so new pages are found and indexed quickly instead of waiting for Google to stumble on them.

Part III — Maintain

What happens after launch

07

RDP / CARE

Ongoing

After launch, we keep watching.

After every migration we watch your rankings for 90 days, because that is the window where a moved site proves itself. And for the life of the site, the quiet work continues: uptime and site-health monitoring, routine accessibility scans, secure connections kept current, and quality checks on everything we ship. DNS, hosting, redirects, and technical setup were handled at launch; keeping them healthy is handled forever after.

None of it arrives as homework for you. When something needs attention, we handle it and tell you what we did. Your job is running a practice. This page is the list of things you should never have to think about.

Where AI helps

Vigilance. Machines watch your site around the clock, in a way no team of any size could staff, and flag anything unusual to our people day or night. The watching is automated. The judgment about what to do, and the hands that do it, are human.

Common questions

What do you watch after launch?

Rankings for 90 days after every migration, search visibility through Google Search Console, site health and uptime, and routine accessibility scans. When something needs attention, we handle it and tell you what we did.

Do I have to manage any of this?

No. This page describes work we do so you never have to. If you love the details, we are happy to walk through them on a call. If you never think about them again, that is the point.

Everything on this page comes standard with every site we build and manage.

RDP / ES — 01

Build · Migrate · Maintain

In force

Want to walk through the details?

Bring your hardest technical question. We enjoy those calls the most.

Book a 30-minute call