Resource library
AI Search Visibility Resources
Use source-backed references, prompt packs, and selection maps that help SaaS teams turn CiteKit tools into repeatable GEO audit work.
Direct answer
CiteKit resources are practical reference pages that support the tools: they explain which workflow to run, which prompts to reuse, how scorecard dimensions are weighted, which crawler sources to check, and which platform notes limit the claims a GEO audit can make.
Resource directory
Start with the tool selection map if you are choosing a workflow. Use the prompt library when you need repeatable answer-engine tests. Use the crawler directory and source notes before changing robots.txt, schema, or advertising-sensitive pages.
GEO Tool Selection Map for SaaS Teams
A practical map that explains which CiteKit tool to use for each AI search visibility problem, audit stage, and evidence gap.
Open resourceAI Search Prompt Library for SaaS GEO
A reusable library of AI search visibility prompts for testing SaaS category, alternatives, pricing, integration, and citation questions.
Open resourceAI Visibility Scorecard Rubric
The scoring rubric behind CiteKit's AI Visibility Scorecard, including dimension weights, 0-5 evidence standards, and follow-up review guidance.
Open resourceAI Crawler Access Directory for GEO Audits
A source-backed directory of major search and AI crawler signals that SaaS teams should review before testing AI search visibility.
Open resourceAI Visibility Test Log Builder
A browser-based workspace for recording AI search prompt runs, brand mentions, cited URLs, competitor mentions, and next actions.
Open resourceAI Visibility Troubleshooting Guide
A symptom-based troubleshooting guide that maps AI search visibility problems to likely causes, CiteKit tools, evidence checks, and recovery actions.
Open resourceAI Search Visibility Glossary
A practical glossary for SaaS teams that explains AI search visibility, GEO, citations, crawler access, schema, answer snippets, and proof signals in plain language.
Open resourceSources and Platform Notes
The public documentation and policy notes CiteKit uses when explaining AI search visibility, structured data, crawler access, helpful content, and advertising-safe tool pages.
Open resourceResource path by problem
Use the library from a specific problem instead of reading every page in order. Each resource is designed to produce a durable review artifact that can be copied into a report, issue tracker, or client handoff.
| Observed problem | Start here | Next action |
|---|---|---|
| A product page is not mentioned in AI answers | Prompt library and visibility log builder | Run 5-10 repeatable prompts, log cited URLs, then compare the missing answer patterns with the page copy. |
| Generated answers cite competitors but not the brand | Scorecard rubric and troubleshooting guide | Score entity clarity, citation proof, and answer readiness before rewriting sections or creating comparison pages. |
| Search or AI crawlers may be blocked | Crawler access directory | Review robots.txt, sitemap, canonical, noindex, and user-agent rules before changing page content. |
| The team needs a structured audit deliverable | Tool selection map and SaaS GEO audit workflow | Choose the right tool path, generate the combined report, then save the Markdown version for review. |
| A stakeholder wants proof behind recommendations | Sources and platform notes | Attach official references and limitations so the recommendation does not sound like a ranking guarantee. |
How these resources improve site quality
| Resource type | User value | Low-value risk it avoids |
|---|---|---|
| Prompt packs | Reusable manual tests and logging structure | One-off screenshots and vague AI visibility claims |
| Log builder | Editable prompt run records with CSV and Markdown exports | Unstructured screenshots and unverifiable visibility notes |
| Scorecard rubric | Transparent dimension weights and 0-5 review standards | Black-box scores with no evidence trail |
| Crawler directory | Source-backed access decisions for robots.txt and WAF reviews | Copied robots snippets with no context |
| Selection map | Clear path from observed problem to tool output | Disconnected utilities with no workflow |
| Source notes | Public references and limitations behind tool guidance | Unsupported claims about rankings, citations, or approvals |
Resource-to-artifact map
A useful GEO audit should leave behind evidence, not only a recommendation. This map shows what each resource should produce before the work is considered ready for review.
| Resource | Artifact to keep | Review question |
|---|---|---|
| Prompt library | Prompt set grouped by category, alternatives, pricing, integrations, and citation checks | Can another reviewer repeat the same tests without guessing the query wording? |
| Visibility log builder | CSV or Markdown log with date, model surface, brand mention, cited URLs, competitors, and next action | Does the log separate observed evidence from planned fixes? |
| Scorecard rubric | Baseline score with dimension notes and a 30-day improvement queue | Can the team explain why a dimension was scored 0, 3, or 5? |
| Crawler directory | Crawlability checklist with robots, sitemap, canonical, noindex, and firewall notes | Was technical access checked before content changes were blamed? |
| Sources and platform notes | Reference list for policy, crawler, schema, and helpful-content boundaries | Are claims tied to public documentation instead of internal assumptions? |
Recommended path
If you are preparing a SaaS page for AI search visibility, review the crawler directory first, then run the full workflow, then use the prompt library to log follow-up tests after page updates.
What to keep after reading
For an internal audit, keep the current URL, the date reviewed, prompt text, answer excerpts, cited URLs, source notes, and a short owner-approved action list. For a client or public report, remove private product data, mark fictional examples clearly, and avoid claims that promise ranking, citations, traffic, or AdSense approval.
The safest handoff is a short Markdown report: one direct finding, one evidence table, one source note, one limitation, and one next test date. That format makes the work usable for SEO, product marketing, and engineering without turning generated output into unreviewed website copy.