What the site is for
Answer one live Subnautica 2 blocker quickly: route confusion, base timing, material value, co-op flow, or update-sensitive trust checks.
Trust and maintenance rules
How Subnautica 2 Guide Hub reviews pages before asking readers to trust them.
This site is built as an independent English-language game guide project. The goal is not to publish the most pages possible. The goal is to publish pages that solve a real player problem, stay readable during play, and get revised when live guidance stops matching what readers are seeing in the current build.
Weekly review rhythm
Each Monday the review team follows a weekly cadence: 2-3 pages first, starting with higher-traffic pages before moving outward into slower evergreen pages and archive cleanup.
What the site is not for
Bulk-generated filler, copied wiki text, unsafe file or account-service content, vague list posts, or pages that exist only to create ad inventory.
How pages are reviewed
High-risk route, resource, and co-op pages are checked before slower evergreen topics whenever a patch changes how players should trust older advice.
How corrections work
The fastest correction starts with one page URL, one changed detail, one build context note, and one useful screenshot or route proof.
Source order
What this site trusts first.
Official posts and videos
Unknown Worlds posts, trailers, update videos, and official release pages are treated as the strongest source for release timing, feature naming, and stated system changes.
Practical route judgment
Guide wording is then shaped around how a player actually uses the information mid-run: route value, stop rules, batch payoff, and handoff into the next page.
Reader correction proof
Player reports are strongest when they identify one page, one changed result, and one practical screenshot or session detail that can be checked against live conditions.
How bylines work
Why pages use a public team byline.
Subnautica 2 Guide Hub uses the public byline Subnautica 2 Guide Hub team for guide pages unless a real, verified individual contributor is ready to be named publicly. The site does not use fictional staff names to make pages look larger than the actual operation.
The team label means the page follows the same public correction path, review date, source order, and patch-risk notes shown on the page. If an individual writer, reviewer, or contributor is added later, that byline should identify a real person or organization and should remain reachable through the contact path.
Review owner
Subnautica 2 Guide Hub Team is the public review owner for guide freshness, patch-risk labels, and visible maintenance notes.
Media review
Gameplay screenshots, diagrams, and official-source context are checked together so a page does not look polished while the guidance is drifting.
Corrections contact
Readers can reach editor@subnautica2.top with one page URL, one build note, one platform note, and one proof screenshot.
What gets updated first
Pages do not all carry the same risk.
| Priority | Page types | Why they move first |
|---|---|---|
| Highest | Routes, dangerous zones, landmarks, co-op saves, material loops | These pages can waste time or mislead players quickly if a patch changes map feel, recipe value, or multiplayer behavior. |
| Medium | Base timing, scanner systems, upgrade order, first-base follow-ups | These pages can drift after balance or utility changes, but usually age more slowly than route or co-op pages. |
| Lower | Broad opening principles, about pages, archive structure | These pages still get reviewed, but usually do not break player trust as fast as route-dependent advice. |
What we publish
Pages should narrow a decision, not just occupy a keyword.
- Answer-first guides that solve one practical in-game problem near the top of the page.
- Route pages with clearer stop rules, return logic, or landmark context when browsing alone would be too vague.
- Material and system pages that tie advice to one named payoff instead of generic farming lists.
- Update-sensitive pages that tell returning players what to re-check before trusting older route memory.
- Public correction paths so readers can challenge stale guidance instead of guessing.
Originality standard
A page is not ready if it only repeats common wiki facts.
Each published guide should add original editorial value for a player who is stuck mid-session. That means the page needs more than a definition, a copied feature summary, or lightly rewritten search wording. It should contain a practical answer, a reason the advice fits a specific situation, and a next-step path that keeps the player moving.
| Originality check | Minimum useful standard | What fails review |
|---|---|---|
| Player problem | The page names the exact blocker and gives a fastest safe answer near the top. | Broad keyword text that never tells the reader what to do. |
| Practical judgment | The page includes a route order, priority rule, stop rule, comparison table, or checklist. | Copied wiki-style descriptions with no decision support. |
| Revision value | Updates explain what changed for the reader and link to the next useful page. | Silent rewrites, cosmetic-only updates, or fake freshness cues. |
What we do not publish
These are deliberate trust boundaries.
- Copied or lightly rewritten wiki pages presented as original reporting.
- Mass-produced placeholder content created only to target search phrases.
- Unsafe files, account-service offers, unauthorized tools, or risky install paths.
- Invented patch details, fake dates, or unsupported claims presented as confirmed fact.
- Ad-heavy page shells with no real guide value above the fold.
Corrections and revisions
What a useful correction looks like.
The correction process is public so readers can see how fixes get made. Good correction reports usually include:
One guide URL
One changed section
One patch or build context note
One useful screenshot or route proof
Update notes
How update notes should stay useful.
A revision note should explain what changed for the reader, not only that a page was touched. Good notes mention the affected guide cluster, the player decision that became clearer, and whether the update was caused by a new official post, a correction report, a route review, or a content-quality check. If a page only received spelling or layout cleanup, it should not pretend that the gameplay advice was retested.
Pre-review site standard
What should be true before the site is submitted for ad review.
The site should feel like a useful English guide project before it ever asks advertising to support it. That means the most important pages are reachable without scripts, the public policy pages are easy to find, and guide content remains the main reason each page exists.
| Review area | Operating rule | Reader benefit |
|---|---|---|
| Access | Public guides should not require account creation, payment, or forced redirects. | Players can read the answer while they are actually mid-run. |
| Navigation | About, Contact, Privacy Policy, Editorial Policy, and Disclaimer should be reachable from every HTML page. | Readers and reviewers can verify who runs the site, how corrections work, and what is not official. |
| Content | Each article should solve one named player problem before adding broad background. | The page feels useful, not like a thin keyword shell. |
| Language | The public site should stay in consistent English unless a separate translated section is created. | Visitors do not hit mixed-language or machine-looking page fragments. |
Advertising and affiliate boundaries
Editorial work should stay readable even if monetization is added later.
The site may add advertising or affiliate disclosures in the future, but those should not change what the guide is trying to do: solve a player problem quickly and honestly. Ads, sponsorships, or affiliate links should never determine whether a guide says a route, craft, or system is worth doing.
If monetization is added, relevant disclosures should be visible on the affected page, and the site should remain accessible without account creation, forced downloads, or fake scarcity tactics.
Before ad review, the safer operating rule is simple: keep guide content visible, avoid floating ad overlays, avoid forced clicks, and keep commercial messages separate from correction or source notes. Readers should be able to reach the main answer, contact page, privacy policy, and editorial policy without friction.
Editorial help
What readers should be able to rely on here.
This page is the site\'s rulebook for sources, corrections, and update-sensitive pages. It should show how the site decides, not just what the site believes.
- Official sources come first for confirmed facts.
- Gameplay advice is treated as practical guidance, not permanent canon.
- Reader reports help pages get retested faster when a patch changes behavior.
- Writing policy language without showing how it changes the reader experience.
- Mixing editorial rules with contact or privacy detail.
- Leaving out the correction path on a public help page.
- Open Reader Reports for the maintenance trail.
- Open About for the site mission.
- Open Contact for corrections or business inquiries.