Audit your website SEO

Open SEO → Website SEO. Confirm the practice's primary domain under SEO → SEO overview → SEO configuration before running the first audit.

Run an audit

Click Run audit. SmileLine queues a bounded crawl of the configured public website. Manual audits respect the server cooldown and provider budget.

The headline cards show the latest on-page score, pages crawled, open findings and critical findings. Audit history keeps the status and crawl count for earlier runs.

An in-progress provider crawl is checked on a finite 15-minute cadence for at most 24 hours. If it still has no final result, the audit is marked failed instead of being checked indefinitely; start a new audit after confirming the site and provider are available.

Work through findings

Prioritised findings lists open, regressed and sent items. Each finding shows:

• its severity and number of affected pages;
• the affected page when one is available; and
• a retained implementation brief.

Observations remain immutable across audits, so a later scan can show whether a finding was resolved or regressed.

Send a developer brief

1. Find the issue you want your web developer to handle.
2. Click Send brief.
3. Choose a saved webmaster contact or enter the developer's email address.
4. Click Queue email.

The first time you use an address, SmileLine emails the developer to confirm it and the brief is not sent yet. The dialog tells you whether a new confirmation was sent or the address is still in its one-hour cooling-off period. Once they click the confirmation link, queue the brief again and it goes out immediately. Every later brief to that address sends straight away.

A confirmation attempt is consumed before SmileLine asks the mail provider to send it. This means an unavailable or ambiguous provider response still starts the cooling-off period. Each contact has three lifetime confirmation attempts. An address that uses all three without confirming remains visible but cannot be reset or deleted; use another address.

Each confirmation link is usable for seven days. After the one-hour cooldown, requesting confirmation again replaces the previous link with a fresh seven-day link only when that contact still has a lifetime attempt available.

The contact list is shared with Content Studio. It shows confirmed, awaiting-confirmation, confirmation-limit and blocked states. An authorised user can block a contact manually and can remove that manual block later. A block reported by the recipient or their mail server is permanent and cannot be removed.

Each practice can send 20 new webmaster deliveries a day and add up to 5 new addresses a day. Retrying the same failed submission returns its original delivery and does not use another daily delivery. A practice keeps at most 50 permanent webmaster contact rows; blocked and unconfirmed rows still use a slot.

SmileLine retries a queued brief for up to 24 hours. If it still cannot be handed off, the delivery is marked failed instead of retrying indefinitely; correct the address or provider issue and submit a new brief delivery.

SmileLine renders the current immutable fix steps together with:

• a bounded, copy-pasteable title, meta description and canonical-link starting point; and
• a Dentist and LocalBusiness JSON-LD example plus schema-check instructions.

The structured-data example is built with the same versioned schema builder SmileLine tests internally. It uses confirmed organisation and practice-location fields only—never patient data. If the primary domain or required address fields are incomplete, the brief withholds the JSON-LD and tells the developer what must be confirmed instead of inventing details.

The developer must compare the metadata, contact details, opening hours and markup with the live website before publishing, validate the deployed page, then rerun the SmileLine audit. Structured data does not guarantee a search feature.

SmileLine records every delivery attempt. Use Dismiss only when you intentionally want to remove a current finding from the working list.