> For the complete documentation index, see [llms.txt](https://suigar.gitbook.io/suigar-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://suigar.gitbook.io/suigar-docs/seo/guidelines.md). # SEO guidelines Last reviewed: 2026-07-13 These guidelines are meant to survive repeated SEO work. Keep them aligned with the current frontend implementation and official Google guidance. ## Goals * Help search engines discover, crawl, render, understand, and select the right Suigar pages. * Make search snippets and social previews clear enough that users know what they will get before clicking. * Preserve one canonical source for each public page and avoid wasting crawl attention on private, duplicate, callback, or development routes. * Improve user experience signals that overlap with SEO: fast loading, responsive interactions, stable layout, readable content, and mobile-first rendering. * Build a compounding AI SEO system where every audit, post, failure, and win improves the next generation pass. ## Operating Principles * One global rulebook, local overlays. Global rules live here; project-specific decisions live in `subprojects/`. * Evidence beats memory. Status claims must point to code, docs, Search Console, analytics, Core Web Vitals, or a dated audit. * Users first, crawlers second. SEO work should make pages clearer, faster, more useful, and easier to navigate. * Mainnet is canonical. Testnet, devnet, previews, dashboards, callbacks, and private flows must not compete with production public URLs. * Automation should tighten quality. AI may draft, audit, cluster, and monitor, but it must not scale low-value pages, unsupported claims, or duplicate content. * Every repeatable judgment should become a constraint. Add new editorial and technical rules to this directory when they are learned. ## Route Indexability * Index public acquisition, editorial, docs, and product pages that can stand alone from a logged-out visit. * Exclude authenticated account/profile pages, tokenized flows, payment/auth callbacks, redirect-only routes, development tools, private surfaces, and thin dynamic game/session pages. * Keep every concrete TanStack route classified in `frontend/scripts/sitemap-routes.mjs`. * Add new public routes to `sitemapRoutes` with source files that affect `lastmod` and static SEO metadata for raw HTML generation. * Add intentionally excluded routes to `sitemapExcludedRoutes` with a short reason. * Keep mainnet indexable and non-mainnet blocked. The current post-build SEO asset writer blocks non-mainnet networks with `robots.txt`, omits sitemaps, and still emits route HTML with `noindex,nofollow` so app routes remain functional. * Keep one sitemap file per canonical host/path scope. A `suigar.com` sitemap must list only `suigar.com` URLs, and a `house.suigar.com` sitemap must list only `house.suigar.com` URLs. * Every mainnet robots file must advertise exactly one same-site discovery URL. The app, blog, and docs robots files advertise `https://suigar.com/sitemap_index.xml`; SweetHouse advertises `https://house.suigar.com/sitemap.xml`. Child sitemaps must contain only URLs in their own canonical host/path scope. * For the blog, production canonical URLs belong under `https://suigar.com/blog`; testnet blog URLs must not be treated as canonical production content. ## Sitemap Freshness Contract * Child sitemap entries must include a truthful `` sourced from material page, metadata, structured-data, or internal-link changes. Never use build time as a freshness substitute. * Static site workflows that derive `lastmod` from Git must use full-history checkouts (`fetch-depth: 0`); a shallow checkout cannot prove an older page's material modification date. * The apex sitemap index must contain exactly the app, blog, and docs sitemaps and omit ``. Those surfaces deploy independently, so no single build can prove every child sitemap modification time. SweetHouse remains discoverable through its same-host robots file. An omitted optional value cannot become stale. * Omit `` and `` from every sitemap. Google ignores them and they create maintenance state without affecting crawl scheduling. * A page URL may appear in exactly one child sitemap. More-specific path scopes such as `/blog/` and `/docs/` own their URLs; the root app sitemap must not duplicate them. * The production-fetching audit in `scripts/seo/check-live-sitemap-system.mjs` is retained for manual diagnosis. Automatic deployment and scheduled execution stays disabled unless `ENABLE_LIVE_SITEMAP_AUDIT=true` is configured. ## Canonicals And Duplicates * Emit exactly one canonical URL for every route through `PageTitle`. * Canonical URLs must match `SEO_CFG.siteUrl` plus the route's preferred path. * If two URLs show the same content, prefer redirecting the duplicate. Use `rel="canonical"` only when redirecting is not practical. * Retired public routes should use server-side 301 redirects to the current canonical target. Do not rely on client-side redirects for URLs that search engines may crawl. * Do not use `robots.txt` as a canonicalization tool. * Sitemap URLs should be canonical URLs only. ## Titles And Descriptions * Every indexable page needs a unique title that names the page's actual job. * The title suffix is centralized in `SEO_CFG.defaultTitleSuffix`; do not hand-roll suffixes in pages. * Descriptions should be specific, action-oriented, and readable by users. Keep the strongest value prop near the start. * Avoid keyword stuffing, repeated phrases, all-caps hype, and unsupported claims. * Do not add `meta keywords`; Google does not use it for ranking. ## Structured Data * Prefer JSON-LD through `PageTitle` and `frontend/src/utils/seo.ts`. * Structured data must match visible page content. Do not mark up claims, offers, ratings, FAQs, or reviews that users cannot see. * Use the narrowest useful schema type: * Home: `Organization`, `WebSite`, `SoftwareApplication`. * Static public pages: `Organization`, `WebPage`. * Game pages: `Organization`, `Game`, `BreadcrumbList`. * Blog posts: `BlogPosting` or `Article` only after the visible author/date/headline/image data is reliable. * Keep `sameAs` social profiles accurate in `SEO_CFG.socialProfiles`. * Validate rich-result changes against Google's structured data guidance before relying on eligibility. ## Robots And Noindex * Use page-level `noIndex` for pages that may be crawled but should not be indexed. * Use `robots.txt` to prevent crawler access to private or irrelevant URL areas, not to remove already-indexed pages. * Remember that crawlers cannot see a page's `noindex` or canonical tag if `robots.txt` blocks the page from being crawled. * Keep `frontend/public/robots.txt` broad and intentional; production post-processing injects the correct sitemap URL. * Do not expose admin, private, config, callback, tokenized, or profile/account URLs in sitemap files. ## JavaScript And SPA Rendering * Critical metadata must render through `PageTitle` on the route itself and through static route HTML for indexed frontend SPA routes. * Build and deploy checks must preserve static route HTML as HTML, not immutable assets, because crawlers consume those files before React runs. * Important public content should be present without requiring login, wallet connection, animation completion, or delayed user interaction. * Use meaningful HTTP behavior where possible. Avoid soft 404 experiences for routes that should be gone or missing. * Links that search engines should follow must be real links with stable `href` values. * Keep public content readable when client data is slow, missing, or blocked. ## Content And Copy * Write for users first. SEO copy must still sound like Suigar. * Keep end-user wording simple for degens. Explain the benefit, the action, or the game in plain language. * Do not expose internals such as backend service names, RPC failures, stack traces, route implementation, or sponsor fallback mechanics. * Avoid legal, financial, or gambling claims that are not supported by the product and compliance posture. * Avoid guaranteed-profit wording. Prefer transparent odds, verifiable results, public receipts, instant payouts, VIP rewards, and on-chain settlement when accurate. * Put unique page value above generic casino/Sui repetition. * Blog content must add Suigar-specific value: product context, original analysis, implementation knowledge, on-chain casino mechanics, Sui ecosystem perspective, or useful player/partner guidance. * Do not publish posts because a keyword exists. Publish posts because the topic helps a real audience and Suigar has something specific to add. * Do not refresh dates unless the content changed materially. ## AI-Generated Content * AI can research, structure, draft, summarize, extract entities, generate metadata, and run critique passes. * AI output must be checked for accuracy, originality, helpfulness, source support, user value, and policy risk before publishing. * Use AI to add structure to original Suigar knowledge, not to manufacture empty pages at scale. * If automation materially produced a piece of content, keep internal notes in the source/claim ledger from [blog-generation.md](/suigar-docs/seo/blog-generation.md). Public disclosure should be considered when it gives readers useful context. * Metadata, alt text, structured data, and snippets generated by AI are content too; they must be accurate and useful. ## Internal Links * Important public pages should be reachable from crawlable links, not only from modals, wallet-gated UI, or client-only search. * Link high-value pages from relevant hubs such as home, games, bonuses, VIP, referral, and docs. * Use descriptive link text that explains the destination. * Keep redirect-only legacy routes out of the sitemap and point internal links at the preferred route. * Blog posts should link back to relevant game pages, docs, or product pages when the link helps the reader take the next step. * Docs and blog content should cross-link deliberately: docs explain mechanics; blog explains context, updates, strategy, and stories. ## Images And Social Previews * Every indexable page should have a useful Open Graph image. Use page-specific images when they improve clarity. * Image URLs in metadata should resolve to absolute URLs through `PageTitle`. * Keep `og:image:alt` meaningful and short. * Prefer stable public assets for previews. Avoid temporary, user-generated, or authenticated image URLs. * Check that social preview images render at small sizes and are not just decorative noise. * Blog cover images should have alt text when the image conveys information. Decorative images should be empty alt in rendered UI, but metadata previews still need meaningful context. * AI-generated images used in editorial content should have internal provenance notes and must not imply screenshots, results, partnerships, or product states that are not real. ## Performance And UX Budgets Use field data when available. Lab tools are useful for finding causes, but the target is real user experience. | Metric | Good target | | ------ | ------------------------------- | | LCP | no more than 2.5 seconds at p75 | | INP | no more than 200 ms at p75 | | CLS | no more than 0.1 at p75 | * Segment Core Web Vitals by mobile and desktop. * Prioritize LCP on acquisition pages: compress hero media, avoid render-blocking assets, and keep above-the-fold content direct. * Protect INP on game and dashboard pages: avoid long main-thread tasks, excessive animation work, and unnecessary re-renders. * Protect CLS everywhere: reserve dimensions for images, game canvases, embeds, banners, and dynamic account/payment UI. * Keep mobile pages usable without horizontal overflow or overlapping text. ## AI Search And Answer Surfaces * Treat search as more than classic blue links. Suigar pages should be understandable to AI answer engines, snippets, summaries, and entity extraction. * Define entities clearly: Suigar, Sui, SweetHouse, games, VIP, rewards, referrals, docs, blog, and partner surfaces. * Prefer concise answerable sections, stable headings, definitions, facts, and source-backed claims. * Avoid hiding core definitions in images, animations, wallet-gated panels, or jargon-heavy copy. * Keep `llms.txt`, docs, blog, and structured content aligned when public positioning changes. ## Validation Minimum checks for route/indexability work: ```bash pnpm run test:seo pnpm --filter @suigar/ui run check:seo ``` Optional production diagnosis: ```bash node scripts/seo/check-live-sitemap-system.mjs --site-url https://suigar.com ``` Use broader checks when the implementation changes: ```bash pnpm --filter @suigar/ui run typecheck pnpm --filter @suigar/ui run build:ci ``` Manual checks for material SEO work: * Inspect the rendered `` for title, description, canonical, robots, Open Graph, Twitter card, and JSON-LD. * Confirm `robots.txt` and `sitemap.xml` match the target environment. * Validate structured data with an official Google tool before claiming rich-result eligibility. * Use Search Console after deployment for indexing, canonical selection, crawl errors, and Core Web Vitals signals. * For blog generation, run the brief, outline, metadata, source/claim, internal-link, and AI critique checks in [blog-generation.md](/suigar-docs/seo/blog-generation.md). * Update [status.md](/suigar-docs/seo/status.md) when validation changes the maturity or next action for a channel. ## Anti-Patterns * Adding public routes without sitemap classification. * Adding a sitemap URL for a page that emits `noindex`. * Blocking a URL in `robots.txt` while expecting Google to read its canonical or `noindex`. * Reusing the same title/description across many pages. * Hiding the only meaningful page copy behind wallet login, tabs, animations, or client data that may fail. * Publishing thin pages whose only unique content is a keyword variant. * Marking up structured data that is not represented on the page. * Optimizing for crawlers in a way that makes the page worse for users. * Letting AI publish at volume without a clear Suigar angle, evidence, review, or feedback loop. * Treating blog posts as isolated assets instead of part of an internal-link, product, docs, and measurement system.