CiteKit editorial standards
CiteKit Editorial Standards
The editorial standards used to keep CiteKit tools, examples, guides, and templates useful, transparent, and safe for an advertising-supported site.
Purpose and audience
CiteKit is written for SaaS founders, marketers, and SEO teams who need practical AI search visibility workflows. The site is not a news publication, paid review directory, or automated article farm. Each page should help a user complete a specific task: audit visibility, write a clearer answer block, generate schema to review, check crawler access, or draft a comparison page with evidence.
- Every guide must connect to a real workflow or tool output.
- Every tool page must explain what the output means and what it cannot prove.
- Every template must include evidence requirements, not only an outline.
- Advertising must never be positioned as a tool button, download action, or recommendation.
Originality standard
A CiteKit page should add something beyond a common definition. Acceptable original value includes a repeatable checklist, sample audit, scoring method, structured prompt log, before-and-after copy, implementation caveat, or limitation that prevents misuse. Pages that simply restate generic SEO advice should be rewritten or removed before monetization.
- Do not publish pages whose main purpose is to target a keyword without a useful workflow.
- Do not copy competitor lists, definitions, or examples from other sites.
- Use fictional examples when showing patterns, and label them as examples.
- When a claim depends on a platform policy or Google guidance, link to the source in the text or keep the claim conservative.
Review and correction process
The site owner reviews tool logic, public examples, and policy-sensitive pages before deployment. Corrections are accepted by email. A correction request should include the URL, the inaccurate claim, and a source that supports the correction. Significant updates should change the page content, not only the date, because freshness without substance is not useful.
- Last-reviewed dates are used on method and example pages where the process may change.
- Generated outputs are examples and require human review before publication.
- Policy-sensitive statements avoid guarantees about rankings, citations, or AdSense approval.
- Privacy and terms pages are updated when analytics, advertising, or data handling changes.
Publication checklist
A page should not be published only because it targets a query. Before publishing, the page should identify the user task, explain the method, include an original example or reusable artifact, link to the next practical step, and state the limitation that prevents overclaiming. If the page cannot pass that review, it should stay in draft until a real workflow or example exists.
- The page has a clear SaaS GEO task, not only a keyword.
- The page includes a checklist, table, prompt set, report format, template, source note, or browser output.
- The page links to a related tool, workflow, guide, template, example, or source note.
- The page avoids guarantees about AI answers, rankings, traffic, revenue, or AdSense approval.
- The page remains useful when no ad units are visible.
Removal and consolidation rules
CiteKit should remove or consolidate content that does not help the site become more useful. A thin page should not be kept because it has a target keyword. If two pages solve the same task, the weaker page should be merged into the stronger workflow. If a guide repeats generic advice without a CiteKit-specific artifact, it should be rewritten around a real example or deleted before monetization expands.
- Merge pages when they answer the same task with similar advice.
- Remove pages that cannot produce a reviewable artifact or source-backed decision.
- Rewrite pages that read like automated summaries rather than applied SaaS GEO guidance.
- Keep update logs tied to real changes, not cosmetic date refreshes.
Advertising standard
CiteKit is intended to become advertising-supported, but ads should be secondary to the tool and guide experience. During AdSense review, the site keeps only the required review script and ads.txt authorization. Visible ad units are not rendered until a real display ad unit is approved. After approval, ads should remain clearly labeled and away from Generate, Copy, Download, or navigation controls.
- Do not ask users to click ads.
- Do not make ads look like tool controls.
- Do not add more ad slots to a page just because traffic increases.
- Review each new ad placement against the surrounding task flow before publishing.
Ad placement checklist
Every ad placement should be reviewed against the page task before it is enabled. A placement is safer when it appears after explanatory content, between non-interactive sections, or in a clearly separate desktop sidebar. It is higher risk when it appears near a Generate button, copy action, download action, saved-report control, checklist item, log-builder row, navigation link, or a result panel that users are trying to copy.
- Keep ads away from Generate, Copy, Download, Save, checklist, log-builder, and navigation controls.
- Do not show blank ad boxes, placeholder labels, or review-only advertising text to users.
- Do not use wording that tells users to support the site by clicking an ad.
- Remove placements that make a page feel less useful or harder to complete.
Use this with a tool
Turn this page into a concrete review by starting with the visibility checker, schema generator, or crawler checker.