# Chapter 2 · Week one: check your site and save today's AI answers before you fix anything

> GEO Playbook · Dental & Aesthetics v1.0 · Canlah AI · CC BY 4.0 · Web page: https://canlah.ai/playbook/dental/week-one/
> Markdown edition for AI assistants, same content as the web page. Figures are code blocks (wireframe / mermaid / bars / steps / split); "→" links open the matching section on the web, and the same URL with .md is its Markdown edition.

## 2.1 D1: the read-only audit and the other nine of the twelve questions

**What you'll do in this section**: On D1 you look but change nothing: get read-only access to the access logs, Search Console, Bing and the five business profiles in one go, then go through the nine of the "twelve pre-start questions" that chapter 0, 0.2 did not ask. When you're done, you'll have an access-request list and dental answers to the nine questions; the door, every profile and the facts page have not been touched at all.

**Hard gate: until the baseline is saved, do not change the door, any profile or the facts page.**

```steps Figure: Week one — measure before you change; don't touch the door until the baseline is saved
D1 | Read-only audit | Read-only access: logs, GSC, Bing, the five profiles
D1 | Finish the nine questions | Registration number, namesake doctors, Chinese and Indonesian buyers
D2 | Freeze questions, sign off | 30 questions: English 18 · Chinese 10 · Indonesian 2
D2–D3 | Web leg and full rounds | Run the web control leg first, add its domains
D4 | Freeze and noise band | Freeze the account-level Top 20, retest 3 rounds the same week
D4 | Brand-six run | Run all 36 in the same week, save it
D5 | Fix the door | Record the split day; check the WAF first
D5–D7 | Build the fact table | Fact table + `/facts`, check prices tier by tier against the ledger
```

Why measure before you change: the page-type mix, the four states per URL, and the question shapes that the baseline needs to measure all have to be measured on the shelf as it stands, before the door has been fixed. Fix the door first and freeze the baseline afterwards, and what you freeze is a shelf you have already disturbed yourself — the before/after comparison in week 13 no longer holds. In the build order the door comes first and the ruler comes fifth, but the ruler's job of freezing comes before everything. So on D1 you can do only three kinds of thing: request access, pull the logs (if none were kept, turn logging on that day) and record the current state. Change not a single word. What the six lines of the door's read-only audit and the crawler hit table look like is already written in （→ 通用版 2.1 五道闸总览与闸零：访问日志（只读）） and （→ 通用版 B.1 开门模板）; not repeated here.

Once the baseline is saved, you do three things in week one, in order: the door's five gates plus the `/facts` page; then the tiered itemised fixed-price pages; and last, the five business profiles, checking against the official registers, and the manufacturer locators. It's fine if the price pages and the profiles don't fit into week one and slip into week two, but you must not skip the baseline just to hit the week-one deadline.

Of the nine questions, six are answered differently for dental and aesthetics than in the General Edition; the other three (questions 5, 6 and 10) follow the General Edition:

| Question | If the answer is | What to do next |
|---|---|---|
| 1 · Legal name, licence / registration number | You can't get the registration number | Leave that cell blank in the fact table for now; fill it in before moving on |
| 7 · Whether the five profiles, GSC and Bing can give you read-only access | You can't get read-only access | The first two items can't be verified at acceptance; list this separately as a risk |
| 8 · Whether there's a namesake organisation or namesake doctor | Yes | The first batch switches to facts pages + profiles, not content pages |
| 9 · Whether you're using a platform that charges per enquiry, per lead or by fee-sharing on each sale | Yes, in use | Write it into the compliance memo and handle it per chapter 6, 6.2 |
| 11 · Whether there are Chinese-speaking buyers or Indonesian buyers | There are Chinese-speaking buyers | Write the 10 Chinese questions using the ratios in 2.2; for dental and aesthetics, write the 2 Indonesian questions anyway |
| 12 · Whether bookings come in by form, WhatsApp or phone | Phone | Observable tier; make the front-desk field "How did you find us?" mandatory; no question is dropped from the pool because of this |

For the wording of the remaining questions and how to read the answers, follow （→ 通用版 4.1 选点全流程与开工前十二问）. If you can only do three things, use the General Edition's 48-hour version of shortcut 2 for the baseline instead — see （→ 通用版 4.8 两条捷径与本章 checklist）; this 48-hour baseline must still be saved before you fix the door, and everything else stays the same.

## 2.2 The 30-question pool: English 18 · Chinese 10 · Indonesian 2

**What you'll do in this section**: Set the 30 questions using the language ratios for dental and aesthetics, rewrite price questions into a shape that a fixed final price can answer, and filter out pure symptom questions and educational questions. When you're done, you'll have a 30-question pool ready to be signed in person; once it's signed, it does not change for the whole quarter.

How the 30 questions split by language is fixed, so that two people can never count two different denominators:

| Language | Questions | Note |
|---|---|---|
| English | 18 | — |
| Chinese | 10 | Always include "新加坡" (Singapore); they also count toward the numerators of the location and price ratios, and do not add to the total of 30 |
| Indonesian | 2 | Mandatory 2 for dental and aesthetics: buyers from Jakarta, near-zero marginal cost |

The 10 Chinese questions are also fixed internally: 3 price-type, 3 scenario-type, 3 second-opinion-type, and 1 "who's best"-type. The Chinese questions must not be cut, because the Chinese landing page is the only lever that works as "build one page yourself → go straight into the named set"; if you can't fill all 30, cut the 3 bare-category-word questions first. For the rest of the ratios (location ≥60%, price ≥30%, bare words ≤10%) and how the second-person check and signing in person work, follow （→ 通用版 4.2 题池：三十句从哪来、怎么配、怎么签）; once signed, it does not change for the whole quarter — changing a question is changing the ruler.

```mermaid Figure: A candidate question passes three filters before it enters the pool
flowchart LR
  c["Candidate question"] --> q1{"A pure symptom question?"}
  q1 -->|Yes| out["Drop from the pool; not added to monitoring"]:::warn
  q1 -->|No| q2{"An educational question?"}
  q2 -->|Yes| out
  q2 -->|No| q3{"Asking about price?"}
  q3 -->|Yes| r["Rewrite so a fixed final price can answer it"]
  q3 -->|No| pool["In pool: English 18 · Chinese 10 · Indonesian 2"]:::hl
  r --> pool
```

The reasoning behind each of the three filters: a pure symptom question ("牙龈肿是怎么回事", what's going on with swollen gums) gets AI citing HealthHub and Mayo Clinic and almost never naming a clinic, so don't park it in the monitoring layer for now; an educational question ("是什么 / 要不要请", what is it / should I hire one) means the buyer hasn't reached the "who to buy from" stage yet; a price question phrased as "<项目> 在新加坡多少钱" (how much does <treatment> cost in Singapore) can go straight into the pool, but if the wording itself already presupposes a price range, rewrite it before it goes in.

> **Example** (dental and aesthetics) Buyers' own words in AI; all three pass the three filters:
> "新加坡哪家做隐形矫正好？" (which clinic in Singapore is best for clear aligner treatment?)
> "种植牙在新加坡大概多少钱？" (roughly how much does a dental implant cost in Singapore?)
> "A 诊所和 B 诊所哪个更适合我这种情况？" (which is a better fit for my case, Clinic A or Clinic B?)

Three things are not decided at this pool-entry step: a three-part symptom question (one that already carries a treatment option and a price) does not count as a pure symptom question; it stays in the pool, and how to handle it is in chapter 4, 4.2. Whether to turn a policy question into an execution question needs the baseline's four-state data, so that decision also waits for chapter 4, 4.2. And confirming the two Indonesian questions by an actual search happens when you write the Indonesian pages (chapter 5, 5.3).

## 2.3 Freezing the baseline, the noise band and the first brand-six run

**What you'll do in this section**: Run the web control leg once first and add in the domains unique to it, then freeze the account-level Top 20, retest three rounds in the same week to measure the noise band, and run all 36 brand-six runs in the same week as the baseline. When you're done, you'll have a frozen account-level Top 20, a noise-band round count, and a set of raw brand-six answers you can use as the baseline.

The rulers for dental and aesthetics follow the General Edition; you only fill in your own values in a few cells, and nothing is redefined:

```split Figure: The ruler's general discipline doesn't change; dental only fills in these cells
What the General Edition has you set || Dental value
Noise-band rounds || 3 rounds
How to split the denominator || Don't split it
Factual errors (count) || Don't split into columns
The fourth reference number || Landing-page phone extensions + asking in the clinic; reference column only
Acceptance tier || Mostly phone bookings → observable tier; front desk must record the source
Brand-six run || Run all 36 in the same week as the frozen baseline, same ruler as the monthly run
Web control leg || Run once before freezing; add in the domains unique to the web leg
```

What the figure cannot show: three "whys".

**Why the web leg has to run first**: a candidate pool taken only from the API leg has a systematic bias, and bias is not noise — adding more rounds cannot fix it. The complete method for running it has exactly one specification in the whole book, in （→ 通用版 4.4 网页对照腿与冻结基线（全书唯一完整规格））; how to do the coarse screen into piles and the full rounds is in （→ 通用版 4.3 粗筛分堆、满轮与品牌六问基线）. The frozen account-level Top 20 is the denominator for the entire quarter and does not change after that.

**Why the noise band has to be measured**: seats only count as up when the change is larger than the noise band; without that band, you cannot tell whether a rise or fall in week 13 is real or just sampling fluctuation. How to read it is in （→ 通用版 7.2 噪声带、页级信号与每月十步）.

**Why the brand-six run only counts these 36**: the baseline's "X factual errors" figure comes only from this one run of 36. Any 2-round × 1-engine quick run (such as the two passes in shortcut 2) is only used to fix errors the same day, ahead of the queue — never as the baseline. A quick run and the 36 runs are not the same ruler; if X came from a quick run, the before and after in week 13's "X → Y" would not be comparable. （→ 通用版 3.1 为什么排在写页之前 · 两小时清单） also reads this same set of raw answers.

The three rulers stay unchanged, the fourth reference number never counts as a criterion, the web leg runs first, and triage must not skip layers — these four rules are the general discipline and not a word of them changes; see （→ 通用版 7.1 复测的产出与量具）. How to read review counts and star ratings is in chapter 7, 7.1.

## 2.4 Fixing the door: five gates; for dental, the WAF is the main trap

**What you'll do in this section**: Once the baseline is saved, fix the door through the General Edition's five gates, checking the WAF allowlist first for dental and aesthetics; record the day you fix the door as the split day. When you're done, you'll have a merged robots.txt, one WAF allowlist rule, and a split day recorded in the work order.

**Hard gate: until the baseline is saved, do not change the door, any profile or the facts page.**

Tick the dental door audit checklist like this:

| Gate | Needed for dental and aesthetics? |
|---|---|
| Crawler hit table | Yes |
| The three nosnippet controls | Yes |
| robots.txt master template merge | Yes |
| WAF allowlist | Yes — and it's this section's main trap |
| The four identities match | Yes |
| CSR check | Not needed |
| Visible-text check | Not needed |
| Platform robots.txt verification table | Not needed |

Exactly how to fix the five gates — the three nosnippet spots, the four-step robots.txt merge, and the three WAF allowlist tasks — is all written in （→ 通用版 2.2 闸一只读体检：nosnippet、robots、WAF 各看什么）–（→ 通用版 2.6 改门：nosnippet、robots 四步合并、WAF 白名单）; not repeated here. The WAF is the key point for the dental door: writing `Allow` for ChatGPT-User in robots.txt is harmless but useless — the real switch is the WAF allowlist.
```mermaid id=door-triage-edge Figure: at the logs / robots / WAF layer, every symptom maps to exactly one fix
flowchart LR
  t["Door-layer symptom"] --> s1["OAI-SearchBot hits = 0"]
  s1 -->|fix| f1["Gate 1's three small steps, 2.6"]
  t --> s2["403 + 429 over 5%"]
  s2 -->|fix| f2["Allowlist it and move it out of the rate rules"]
  t --> s3["All 200 but only the homepage hit"]
  s3 -->|fix| f3["Sitemap, homepage internal links, IndexNow"]
  t --> s4["Admin paths showing up in search"]
  s4 -->|fix| f4["Redo the merge, get the count to N × 12"]
  t --> s5["No movement on the Apple profile"]
  s5 -->|fix| f5["Allow and verify Applebot first"]
  t --> s6["Blaming GPTBot being blocked for not being cited"]
  s6 -->|verdict| f6["Wrong call — don't use it as a criterion"]:::warn
```
```mermaid id=door-triage-render Figure: at the rendering / indexing / nosnippet layer — Google has seats while ChatGPT is zero: check CSR first, not the choice of questions
flowchart LR
  s1["Google has seats, ChatGPT is zero"] -->|check first| csr["CSR dependency"]:::hl
  s2["Four identities: c open, b not"] -->|verdict| csr
  csr -->|fix| ssr["Open an SSR or prerendering task"]
  s3["Four identities: b open, d not"] -->|verdict| waf["WAF, go back to the edge-layer figure"]
  s4["Seats drop after a redesign or plugin change"] -->|verdict| ns["nosnippet has come back"]
  ns -->|fix| m1["Revert all three to max-snippet:-1"]
  s5["Seats haven't moved, cause unclear"] -->|in order| five["Check five things, see below"]
  five -->|any one fails| door["It's a door problem, not the questions"]:::warn
```
These two troubleshooting diagrams are not only for the day you fix the door: check the door layer once every month without conditions, even when seats have risen (（→ 通用版 7.3 没动分诊与下月三个点）).

Whether fixing the door itself needs a written compliance sign-off comes in two halves:

```mermaid Figure: Fixing the door is technical SEO and doesn't need sign-off; text written into schema is reviewed as advertising content
flowchart LR
  fix["robots.txt, WAF, nosnippet, etc."] -->|"explicit in the regulator's FAQ"| ok["Not advertising; no sign-off needed"]:::hl
  ld["Price and rating fields in JSON-LD"] -->|"is content"| rule["Write per 1.2; never add a rating field"]:::warn
  day["The day you fix the door"] --> mark["Record as the split day"]
```

Basis: technical SEO itself is not advertising (**Statute text**; see Appendix A; for how this rule is used off-site, see chapter 6, 6.2). The price and rating fields in JSON-LD are reviewed as advertising content [Conservative line (not statute text)]. Write JSON-LD prices per chapter 1, 1.2; never add `aggregateRating` on any page (see chapter 1, 1.4 for why).

Schema only needs four things right: get `@type` right; point `sameAs` to the regulator's registration-number lookup page and the business profile pages, and write the UEN as `identifier`; make the published and modified dates genuine; and write only the fixed final price in the price field, never a `minPrice` / `maxPrice` range. These fields only work for Google's Knowledge Graph — AI's live fetches never read JSON-LD at all — so the same facts must first be written into visible HTML, see （→ 通用版 2.7 闸三闸四：收录通路与 JSON-LD 一次封版）.

The split day goes into the work order; at the week-13 settlement, every "before fixing the door vs after fixing the door" comparison is drawn against it, see （→ 通用版 7.4 守位与九十天结账）.