Roblox Homepage Ranking Auditor

Roblox Homepage Ranking Auditor

Objective

Determine whether an existing game-site homepage conforms to the RB Auto Golden Homepage model and has strong homepage structural ranking potential under a controlled assumption:

• new site;
• zero backlinks and zero domain history;
• no advantage from keyword search volume or game popularity;
• facts are evaluated separately from homepage structure;
• the audit compares what the homepage itself is designed to do, not current rankings.

The primary output is not “good SEO” or “bad SEO.” It is:

1. What player job the homepage owns.
2. What main engine creates non-generic value.
3. Which query families belong to / and which belong to child routes.
4. Whether the homepage directly answers, summarizes, routes, or merely names each intent.
5. An eight-dimension structural score out of 100.
6. Structural blockers, separate delivery gates, and minimal repair work orders.

When This Skill Applies

Use this skill when the user asks Codex to:

• audit a Roblox/game-site homepage for new-site ranking potential;
• judge whether a homepage matches the RB Auto golden model;
• review whether the homepage has a suitable main engine;
• detect a thin, templated, keyword-only, or generic homepage;
• inspect homepage versus child-page intent ownership;
• find homepage/internal-page cannibalization or duplicate calculators;
• produce a homepage score, verdict, and actionable repair plan;
• validate a newly generated RB Auto homepage before launch.

Do Not Use This Skill For

• backlink, DR, DA, domain-age, or brand-strength analysis;
• estimating current traffic or keyword search volume;
• generic full-site technical SEO audits;
• checking factual accuracy as part of the 100-point structural score;
• evaluating maintainability, future extensibility, or production cost inside the structural score;
• rewarding a page merely for adding “verified,” dates, sources, author bios, or social proof;
• redesigning the whole repository when only the homepage is under review.

Non-Negotiable Model Boundary

Keep these systems separate:

A. Homepage Structural Ranking Power — scored 0–100

Measures the homepage model itself:

• main-topic clarity;
• core-intent satisfaction;
• query coverage;
• information gain;
• content depth and specificity;
• topic structure;
• internal-link efficiency;
• search-intent boundary.

B. Fact Consistency Gate — PASS / FAIL / NOT_CHECKED

Checks whether facts, codes, data, labels, formulas, and child-page values are consistent. It never adds or removes points from the structural score.

C. Delivery and Runtime Gate — PASS / FAIL / NOT_CHECKED

Checks whether the rendered page, mobile experience, links, and tools actually work. It never adds points to the structural score.

D. Technical Eligibility Gate — PASS / FAIL / NOT_CHECKED

Checks whether the page is eligible to participate normally in search: successful response/build, indexability, canonical, crawlable content, and crawlable links.

A strong homepage model can receive a high structural score while publication remains blocked by factual, runtime, or technical failure. Do not merge these conclusions.

Required Audit Modes

Use the strongest available mode. Do not ask the user for information already present in the repository.

1. Combined mode — preferred: repository + built HTML/live URL + child routes.
2. Repository mode: inspect source, data, route map, and build output.
3. URL mode: inspect live rendered homepage and discover same-domain child routes.
4. HTML snapshot mode: inspect supplied/exported HTML; mark unavailable gates NOT_CHECKED.

Required Evidence Sources

Before scoring, inspect as many of these as exist:

• homepage source component;
• metadata definition;
• homepage data/content source;
• route manifest or sitemap;
• keyword/page mapping;
• page-generation plan or homepage contract;
• built/exported homepage HTML;
• at least the P0 child pages linked by the homepage;
• the complete tool route if a mini/full tool exists;
• browser/runtime behavior for interactive engines;
• current Git SHA and worktree status for repository audits.

Never score from a screenshot alone when source or HTML is available.

Required Resources

Read these before completing the corresponding step:

• references/golden-homepage-model.md: model, layouts, engines, and intent ownership.
• references/scoring-rubric.md: exact scoring anchors and thresholds.
• references/hard-blockers.md: blocker definitions and evidence requirements.
• references/audit-procedure.md: repository, HTML, URL, and runtime workflow.
• references/report-template.md: mandatory final report shape.

Use assets/rubric.yaml as the machine-readable source for weights and thresholds.

Workflow

0. Freeze the Audit Baseline

For a repository audit:

1. Record repository root, branch, HEAD SHA, and worktree status.
2. Do not modify source files in audit-only mode.
3. Record the exact URL, local route, or HTML file being audited.
4. Record the audit timestamp and evidence limitations.
5. If the worktree is dirty, continue read-only unless user requested repairs; never discard, stash, or overwrite unrelated work.

1. Locate the Homepage Truth Sources

Search the repository rather than guessing framework paths. Find:

• root route implementation;
• layout and metadata;
• content/data inputs;
• homepage-specific components;
• interactive tools;
• child-route definitions;
• sitemap/navigation/route manifest;
• research artifacts and keyword-to-page mapping.

Create a short source map with file paths and purposes.

2. Reconstruct the Intended Homepage Strategy

Infer or read the following, labeling every item as DECLARED, OBSERVED, or INFERRED:

game_archetype: rpg-build | simulator-roi | collection-team | trade-value | route-progression | risk-softlock | data-live | other
primary_player_job: one sentence
player_problem: one sentence
main_engine:
  type: build-planner | damage-calculator | value-comparator | trade-comparator | upgrade-roi | rebirth-planner | team-builder | starter-selector | anti-softlock-checklist | first-hour-route | live-stats | database | other | none
  mode: full | mini | route | checklist | data | none
  location: homepage | child-page | both | absent
layout_variant: tool-first | risk-first | route-first | data-first | mixed | generic

Rules:

• Choose one primary player job, not a list of all possible intents.
• Select the main engine by the game’s central player decision, not genre name alone.
• A first-hour route or anti-softlock checklist can be a valid main engine; it need not be a calculator.
• If the homepage has no defensible primary job or main engine, state that explicitly. Do not invent one to improve the score.

3. Build the Query-Family and Intent-Ownership Map

For every meaningful query family, assign exactly one canonical owner and one homepage treatment:

query_family: game-codes
canonical_owner: /codes/
homepage_treatment: primary | direct | summary | status | link-only | excluded
answer_depth: full | partial | status-only | none
evidence: selector, source path, or excerpt

Use these definitions:

• primary: the homepage is the definitive destination.
• direct: homepage gives a complete usable answer for a compact intent.
• summary: homepage gives a useful conclusion plus a reason to visit the child owner.
• status: homepage gives a current state, such as “3 active codes” or “none active.”
• link-only: contextual, descriptive route only; not counted as a direct answer.
• excluded: intentionally absent from the homepage.

Every query family must have one owner. Do not let both / and a child route own the same complete intent.

4. Run the Deterministic Evidence Scanner

Use the included scanner where possible:

python .agents/skills/roblox-homepage-ranking-auditor/scripts/audit_homepage.py \
  --url "https://example.com/" \
  --game-name "Example Game" \
  --child-url "https://example.com/codes/" \
  --child-url "https://example.com/tier-list/" \
  --output "artifacts/homepage-audit/homepage_machine_evidence.json"

For exported HTML:

python .agents/skills/roblox-homepage-ranking-auditor/scripts/audit_homepage.py \
  --html "out/index.html" \
  --game-name "Example Game" \
  --child-html "out/codes/index.html" \
  --child-html "out/tier-list/index.html" \
  --output "artifacts/homepage-audit/homepage_machine_evidence.json"

The scanner supplies evidence and warnings. It does not replace semantic scoring. Review every machine flag before accepting it.