SEO / Search Platforms
Core 30 Structure
Core 30 is Tekton’s AI SEO Mastery-aligned local website structure. It aligns a client’s verified GBP categories and services to an evidence-backed hierarchy of category pages, service pages, essential company pages, local proof, and internal links. The name is a structural concept, not an exact quota. A typical site may have roughly three to five category pages, 20 to 30 service pages, plus essential business pages, but the justified total may be lower or higher.
For any client with two or more GBPs, the controlling SOP is Multi-Location Core 30 Structure. Do not blend it with retired multi-location rules.
Who owns it
Section titled “Who owns it”The Website / SEO Specialist owns the Core 30 page map, source validation, evidence review, and approval of implementation tradeoffs. SEO QA verifies training alignment, client facts, URL preservation, schema scope, and approval gates.
- Lock the source hierarchy. Use current AI SEO Mastery training first, then the approved Tekton SOP, then verified client facts and ranking evidence, then Tekton implementation conventions. Label training-backed rules, Tekton conventions, and client-specific decisions separately.
- Build the Service Truth Map. Record verified GBP categories, GBP services, actual offered services, primary and secondary locations, NAP, hours, service areas, existing pages, and source confidence. Unsupported services and locations stay out of the plan.
- Inventory and preserve existing assets. Review current rankings, backlinks, organic traffic, conversions, GBP landing-page usage, intent, index state, and internal-link equity before changing, merging, or redirecting a URL. Preserve valuable established URLs by default.
- Design category and service hierarchy. Create justified parent category pages and child service pages from the verified service model. Do not add thin pages or omit necessary pages to hit exactly 30.
- Assign one clear target per page. Each public route needs a defined service/category intent, location role, title/H1 direction, source facts, proof requirement, and internal-link role. Avoid near-duplicate city-name-swapped pages.
- Handle multiple locations through the approved SOP. Record every GBP website URL and run relevant local rank maps before changing landing-page assignments. One location normally retains the homepage; additional locations may use dedicated mini-homepages. Location folders are optional. Every stack contains only services actually offered there, every GBP has its own valid phone under the training method, and each LocalBusiness entity appears only on its matching GBP landing page.
- Build internal links around hierarchy and context. Category pages link to relevant child services, child pages link back to parents and contextually useful siblings, and natural in-copy links supplement navigation cards. Multi-location child pages stay inside their location silo unless evidence supports a cross-location link.
- Expand geography only after topical relevance. Re-run rank maps after category and service coverage is established. Prioritize genuine local opportunities, often where positions around four to six suggest realistic top-three movement. Use real neighborhoods, landmarks, conditions, projects, or directions and avoid thin geo pages.
- Separate planning from implementation. An approved page map is not approval to change live URLs, GBPs, redirects, canonicals, indexing, schema, DNS, or production systems. Route exact implementation packets through the required approval gate.
- Verify generated and live output. Build the site, inspect rendered HTML, parse schema, verify canonicals and sitemap membership, crawl links, confirm titles/H1s, check that no sibling-location schema or NAP leaked, and compare the final state to the approved packet.
Definition of done
Section titled “Definition of done”- The Service Truth Map and page ledger are complete and source-backed.
- Page totals are justified by services and evidence, not by an exact quota.
- Valuable existing URLs are preserved unless a reviewed and approved change is supported.
- Every route has one clear intent and contains differentiated, client-specific proof.
- Multi-location work passes the approved landing-page, rank-map, phone, NAP, URL-preservation, schema, and silo gates.
- Generated-output QA passes for metadata, headings, schema, links, sitemap, canonicals, crawl state, and route inventory.
- Strategy approval and live implementation approval are recorded separately.