SITE-RULES — Personalisation + SEO (agreed 3 Oct 2026)

Goal: every student sees a site that fits them (their centre, exam, batch), while Google can read every public page and the links we build push our rankings up. Decided with Ravneet so nothing new has to be built around it later.

1. Two layers. Never mix them.

Public layer — same content for every visitor and for Google.

  • Home, the six bot pages, centre pages, exam pages, blogs, videos, shop pages.
  • Fully readable HTML, own title and description, preview image, structured data, in the sitemap.
  • NEVER show Google something different from what visitors see (that is cloaking and gets penalised).

Personal layer — only for the logged-in student.

  • Their timetable highlights, mocks, rank, books, deadlines, Oracle's greeting.
  • Lives inside the student home (/app), which is noindex (hidden from Google).
  • On public pages it may appear only as a small strip that loads AFTER the page (client side). It is never part of the HTML Google reads.

2. One design, many real addresses

One page template is reused for every centre and every exam. Only the content and address change.

Address What it is
/thane /vashi /dadar /borivali /online Centre hub: this week's timetable, faculty, centre details, demo form
/thane/timetable (same for each centre) Full-week timetable for that centre
/cat /cet /snap /nmat /cmat Exam hub: syllabus, mocks, classes for that exam
/mocks /arena /teaching /books /admissions The five bot pages (generic, for everyone)
/app Student home. Private, noindex

These addresses sit INSIDE the Universe: same pill nav, same six bots, same look. The centre page shows Guruji as its host ("Guruji · Thane"). There is no "going out and coming back": it is one site.

3. The Thane student journey (the example)

  1. A Thane student (known from login, or a remembered centre on a returning visitor) taps Guruji on the home lineup.
  2. The usual jump animation plays, then he lands on /thane, not the generic /teaching. He sees the Thane timetable.
  3. Tapping the timetable opens /thane/timetable. Still inside the Universe.
  4. A visitor who is not known yet taps Guruji and lands on /teaching, which shows centre cards (Thane, Vashi, Dadar, Borivali, Online) linking to the centre pages.
  5. The same idea applies to exams: a student whose target is SNAP gets /snap as the link under mocks and classes.

How the link changes: the link is simply computed from the student profile (centre, exam). It is a normal link. We never force-redirect anyone, and never redirect Google.

4. Rules that protect ranking

  1. Every public address needs its own real, unique content. No empty or copied pages. Do NOT create combinations like /thane/cat unless there is something genuinely different to say there.
  2. One address per piece of content. If the Thane timetable also appears inside /app, that copy is private (noindex) and points to /thane/timetable as the real one (canonical).
  3. Bots are real links (<a href>), not buttons, so Google can follow them. The jump animation is added on top of the link.
  4. Student visits are a bonus, not the ranking engine. What really lifts /thane: many internal links to it, fresh content (timetable changes weekly), students sharing the link (backlinks), searches for our name, a correct Google Business listing.
  5. Keep one domain (cetking.com) so all the authority stays in one place. Old WordPress addresses get permanent redirects (301) when pages move.
  6. Pages must be fast: build public pages ahead of time and cache them; fetch the personal bits separately.

5. SEO checklist (every public page)

  • Own <title> and meta description; one <h1>
  • Preview image (WhatsApp/Google card) showing the bot and the page
  • canonical address
  • Structured data: Organization, LocalBusiness/EducationalOrganization for centres, Event for classes, Course for courses
  • Listed in sitemap.xml; robots.txt blocks /app and /api
  • Real links between pages (home → bots → centres → timetables and back)

Status on 3 Oct 2026: none of the above exists in code yet except the home page title and description. First job.

6. What a student profile must hold

centre, mode (centre / online), batch, target exam(s), joined or not, mentor, and the student's own names for the bots. Every piece of content (class, recording, book, notice, mock) carries the same tags: who it is for (centre, exam, batch). One rule decides what each student sees. Adding a new feature later means adding tags, not new plumbing.

7. Per-bot personal view (inside /app)

  • Guruji: their centre's timetable, their batch's recordings
  • Rocky: assigned mocks, last result
  • Arena: their rank
  • Sutra: books issued, reading progress
  • Purva: their target colleges' deadlines
  • Oracle: whole-brain summary and morning nudge

Two kinds of personalisation: by rules (profile tags, cheap and fast) and by AI (companions talk to each student differently; cost depends on the plan tier in config/companions.config.ts).

8. Who sees what

Visitor Sees
Google / anyone Public layer only
Visitor with a remembered centre Public layer + soft suggestion "Your centre: Thane"
Lead (not joined) Public layer; can pick a centre to preview
Joined student (logged in) Public layer + personal strip + /app
Staff Use CK Backoffice (no companion)

9. Open decisions (ask Ravneet)

  • Timetable data lives in the "Cetking Learn" Supabase; Universe uses "Cetking One AI". Either read it through a safe server link, or keep student records in one place. Not decided.
  • Confirm the domain is cetking.com (spoken as "ceticking" / "ceteaching" in voice notes).
  • Login (OTP) must be in Universe before the personal layer can go live; today it is only on the old WordPress site.

Source: GitHub cetking-one/docs/SITE-RULES.md. Edit the file there; this page updates on the next release.