# Mode SEO Consultant Onboarding ## BLUF: the product decision and SEO's job **Modeinspect** (Mode after first reference) is an AI visual canvas for designers who design product UI and want to use AI. The approved core loop is: open or capture real product context; design a scoped UI change visually on the canvas; share a live prototype or reviewable direction; then move useful work toward engineering review. Engineering review remains part of the path. **SEO decision:** lead with the bounded job of designing directly in the real product—not generic prompt-to-app generation, a detached mockup workflow, or an engineering replacement. The clearest entry action is: **fix one real product UI issue**. Pages should connect that job to an observable workflow and an honest engineering-review boundary. **What must be true for SEO to count as product growth:** a relevant organic visitor can understand the intended job, enter a trustworthy product start, and eventually reach a separately defined strict activation in an own-project context. Visibility, rankings, sessions, and signups are useful signals; none alone proves product value or channel causality. ## How to use this brief - **Observed fact** is supported by a dated public check or a non-published validation/audit trail against a current approved internal product-truth source. - **Recommendation** is proposed work, not a product or market claim. - **Hypothesis** requires first-party search, conversion, or customer evidence before it determines roadmap or publishing priority. - Recheck time-sensitive product behavior, support scope, pricing, permissions, security/privacy, and availability immediately before publishing. - This brief is a consultant operating guide, not permission to publish, change production systems, or access private data. It intentionally excludes credentials, private identifiers, PII, raw analytics, customer records, and deployment detail. ## 1. Product truth: loop, use cases, terminology, and limits ### Core workflow and use cases Mode is for scoped work against product UI, code, components, and design-system context—not for replacing a team's codebase or engineering process. The approved workflow supports these product-story themes: 1. Work from real product UI and existing product context. 2. Make a scoped visual UI, layout, component, or design-QA change on the canvas. 3. Create a live prototype or reviewable direction for the change. 4. Move useful work toward engineering review. Safe use-case families are existing-product UI improvement, UI polish, design QA, component or layout adjustment, real-product prototyping, and designer-to-engineering review handoff. Describe the exact demonstrated workflow; do not turn one example into a universal promise. ### Preferred terminology - Use **Modeinspect** on first reference in titles, H1s, metadata, and comparison queries; use **Mode** as shorthand afterwards. - Prefer: *design directly in the real product*, *design in code*, *AI visual canvas*, *real product context*, *scoped UI change*, *product designers*, *live prototype* (when demonstrated), and *reviewable output*. - Use *PR* only when the specific source or proof visibly supports a PR path. Otherwise say *reviewable output* or *engineering review*. - Do not lead with *Figma replacement*, *generic AI app builder*, *blank-canvas tool*, or *prompt-to-app*. ### Claim boundaries Do not claim that Mode universally: - ships directly to production, bypasses engineering, creates merge-ready output, or guarantees a PR; - preserves every component, token, design-system pattern, or type constraint; - supports every codebase, framework, import path, permission model, or sharing configuration; - provides guaranteed speed, quality, productivity, conversion, or ROI; - has a particular security, privacy, compliance, billing, deployment, model-training, retention, or access-control posture. The active onboarding documentation contains a current support statement for Next.js React codebases and identifies other frameworks as not currently supported. Treat this as a product-confirmation gate before public support-matrix copy; do not generalize it to all React projects or stacks. ## 2. ICP, jobs-to-be-done, and fit ### Core persona Mode's core persona is **designers who design product UI and want to use AI**. Their titles include: - Product Designer - UI Designer - UI/UX Designer - Founding Designer - AI-Native Designer - Design Engineer - Design Systems Designer They work at: - **Company size:** 20–200 employees. - **Company type:** Software and technology companies with a user-facing digital product. - **Common categories:** B2B SaaS, B2C software, marketplaces, e-commerce, travel, and hospitality. - **Product environment:** Active codebase, reusable components, and ideally an established or emerging design system. - **Team environment:** Designers work closely with engineering and regularly experience handoff, implementation, or design-QA friction. ### High-fit jobs and triggers - Improve a real shipped screen or flow without rebuilding it from a blank canvas. - Explore a proposed UI change against existing components, layout behavior, states, and codebase constraints. - Make a visual or design-QA change that engineering can inspect. - Reduce the gap between design intent and an engineering-reviewable proposed change. Lower-fit intent includes unconstrained greenfield app building, static moodboarding, detached canvas-only exploration, teams with no real product/codebase context, unsupported stacks, and teams without recurring UI iteration or handoff pain. ## 3. Positioning, voice, and proof gates ### Message spine Use this sequence where it matches the page intent: 1. **Category:** design directly in the real product. 2. **Context:** work visually with the existing product and its code/component/design-system context. 3. **Difference:** this is not a detached mockup or generic prompt-to-app workflow. 4. **Trust boundary:** designers propose; engineers review. 5. **Activation prompt:** fix one real product UI issue. A safe short description: **“Mode helps product designers use AI to work visually on their real product, then move a scoped change toward a live prototype or engineering review.”** ### Voice and approved language Be direct, concrete, visual, and demonstration-led. Start with the product-workflow problem, show the real-product context, and state the review boundary. Prefer bounded verbs such as *helps*, *can*, *propose*, *inspect*, *share*, and *move toward review*. Avoid generic AI superlatives, adversarial competitor copy, unscoped *production-ready*, *pixel-perfect*, *real-time*, *what you design is what ships*, or any phrasing that makes engineering review appear optional. Use a named, dated, primary customer source only for the exact scope of its statement; never generalize it into universal proof. ### Evidence gates | Claim type | Minimum evidence before use | |---|---| | Core product framing | Current approved product source plus a current public Modeinspect page; keep the existing-product scope. | | Feature or workflow | Current first-party page or visible product demonstration; name the exact scope. | | PR or engineering output | Use reviewable-output language by default. Use PR language only where the cited proof supports it; preserve engineering review. | | Customer, productivity, ROI, or performance | Dated primary source with defined audience, method, window, and scope; do not generalize. | | Support, pricing, security, privacy, availability, or roadmap | Current approved public primary source and Product confirmation when time-sensitive. | | Social proof, sentiment, reach, or engagement | Dated, attributable public evidence set. Omit without it. | **Social-evidence gap:** Mode currently lacks substantial social-brand evidence for this brief. Do not imply established social sentiment, reach, engagement, community narrative, or independent social validation. Treat this as a gap and an opportunity to build attributable evidence—not as an existing proof layer. ## 4. SEO's role in the GTM motion SEO/inbound is one current growth lever alongside partnerships, influencers/UGC, and outbound. Its role is to capture relevant problem/category demand, clarify the first product job, and build bounded trust before conversion. It is not a traffic-volume project detached from first-use quality. Prioritize SEO work that helps a user reach a first useful reviewable outcome, removes a blocker to repeated useful work, or improves activation/retention learning. Do not treat channel plans or labeled initiatives as proof that SEO caused an outcome. ## 5. Public site IA, content inventory, and reusable assets ### Observed public inventory (checked 2026-08-11) The canonical marketing host is `https://modeinspect.com`. A public audit found a 21-URL marketing sitemap with these content families: | Family | Examples | Consultant use | |---|---|---| | Commercial/company | `/`, `/about`, `/enterprise`, `/pricing`, `/demo` | Establish category, evaluation, and conversion paths. | | Product/use case | `/ai-prototyping`, `/canvas-code`, `/design-qa`, `/developer-experience` | Build distinct, proof-led job clusters. | | Proof/trust/legal | `/customers/prelude`, `/security`, privacy and terms pages | Use the customer story only with attribution and exact scope; route trust claims through approval. | | Editorial/comparison | `/blog`, `/modeinspect-vs-cursor`, six observed blog articles | Refresh and connect educational/comparison content. | | Updates/feedback | `https://feedback.modeinspect.com/en/changelogs` | Treat as a separate public surface with explicit ownership and indexing policy. | Current public reusable references: [Homepage](https://modeinspect.com/), [AI Prototyping](https://modeinspect.com/ai-prototyping), [Design QA](https://modeinspect.com/design-qa), [Developer Experience](https://modeinspect.com/developer-experience), and the [Prelude customer story](https://modeinspect.com/customers/prelude). Revalidate each page and its rights/claim scope before reuse. ### Information-architecture implications - The public `/figma-to-code` URL returned 404 on 2026-08-11. Treat it as a repair/redirect/content-decision candidate, not evidence of prior traffic or rankings. - The blog and several important product/comparison routes need intentional contextual linking; sitemap-only discovery is weak architecture. - Public product documentation/help is not part of the observed marketing IA. Decide whether it is needed, where it should live, and how it relates to the separate feedback/changelog surface before building a large documentation program. - Use the homepage as the high-level real-product/design-in-code hub and the use-case pages as distinct spokes. Link comparison and educational pages to an appropriate proof-led use-case or demo page rather than to generic claim copy. ## 6. Technical SEO: dated facts versus recommendations ### Observed facts (public audit on 2026-08-11) - `www.modeinspect.com` returned HTTP 522 rather than redirecting to the apex host. - All 21 observed sitemap URLs returned HTTP 200 in the audit; this is a crawlability snapshot, not an indexing or performance guarantee. - Publicly reachable debug/backup routes were observed outside the sitemap, with live metadata behavior inconsistent with intended local metadata. Confirm production behavior before acting. - Self-referential canonicals and route-specific social metadata were incomplete across sampled non-blog pages. Some route titles appeared to duplicate the brand suffix. - Three sitemap pages had no incoming internal HTML link from another sitemap page in the audit: `/ai-prototyping`, `/canvas-code`, and `/modeinspect-vs-cursor`. - The sitemap uses deployment-time dates as `lastmod`; this is not a reliable content-change signal. - Blog and pricing structured data exist, but critical homepage FAQ markup was not present in the raw inspected HTML. No field Core Web Vitals data was available; do not claim scores. ### Prioritized recommendations **P0 — resolve before scaling content** 1. Make `www` path-preserving redirects to the apex host work and verify them at response level. 2. Remove debug/backup routes from production output or verify response-level noindex protection; do not rely on obscurity. 3. Establish canonical repository/deployment ownership and validate live/source parity before template remediation. 4. Add one correct self-referential canonical and route-specific Open Graph/Twitter URL to each intended indexable marketing page. **P1 — build the foundation** 1. Normalize title construction, descriptions, and accurate sitemap `lastmod` behavior. 2. Improve contextual internal links to product/use-case, comparison, blog, and changelog surfaces. 3. Validate critical structured data in delivered HTML; add only schema represented by visible, verified page content. 4. Establish field/lab performance measurement before making CWV claims; test third-party scripts, video/media loading, and edge-cache behavior. **P2 — govern the system** 1. Decide public docs/help IA and cross-surface ownership rules. 2. Define content, route, canonical, schema, and release-test owners. 3. Run a recurring public crawl for status, final URL, canonical, robots, sitemap drift, zero-inlink pages, metadata duplication, and performance regression. ## 7. Search landscape and content opportunities ### Observed category landscape The landscape spans five overlapping jobs: visual editing of a real React/codebase; code-backed/design-system-aware design; Figma-to-code or Figma-to-agent bridging; AI prototyping/app building; and design QA/review handoff. These are observable category phrases and vendor positioning—not keyword-volume or conversion evidence. Mode's prioritized competitor set is **Onlook, Noon, Wonder, Paper, Subframe, Magic Patterns, Tempo, Frontman, Puck, and Codux**. Treat these as the competitors Mode needs to care about in competitive research, comparison strategy, and SEO planning. Broader tools may be adjacent alternatives, but they should not dilute this set. Use current primary pages to frame buyer decisions and date every comparison. Do not claim product equivalence, superiority, or a competitor limitation without scoped, reproducible evidence. ### Priority hypotheses (strategic fit, not volume forecasts) 1. **Figma to code for existing product teams.** Repair or decide the 404 route before promotion; distinguish a real-product workflow only if Mode proof supports it. 2. **Visual editor for React / visual React editing.** Build only after Product reconfirms the exact support scope and the proof demonstrates the claimed workflow. 3. **Design QA in the codebase / visual polish review.** Pair a workflow guide with an annotated, review-safe example; do not use unverified time-saved claims. 4. **Design-system-aware AI UI / design with real components.** Explain components, tokens, variants, states, and review safeguards using a controlled example rather than generic promises. 5. **Comparison and educational content.** Prioritize genuine evaluation questions—Mode versus IDE-led/Figma-MCP, visual React editing, or code-backed prototyping—only where dated sources and Mode evidence allow a scoped comparison. Do not include keyword volume, difficulty, rankings, traffic estimates, market size, backlinks, customer outcomes, or competitor business metrics until licensed tools, Search Console, and appropriate evidence are available. ## 8. Measurement, KPIs, and access requirements ### Current aggregate context In the complete 30-day window from 2026-07-12 through 2026-08-10 (Europe/Prague), read-only aggregate analytics showed 3,082 eligible marketing sessions and 312 organic-search sessions (10.1% of eligible sessions). Organic sessions were concentrated on the homepage (84.9%). These are descriptive aggregates, not causal proof, ranking data, or a decision-grade funnel. No authorized Google Search Console, keyword/rank/backlink tool, CRM/customer evidence, or field-CWV dataset was available for this baseline. Aggregate downstream data also shows incomplete cross-domain/session continuity for some server outcomes. Outcomes below five are suppressed; do not infer page- or persona-level performance from sparse cells. ### KPI hierarchy | Layer | KPI | Source and use | |---|---|---| | Leading demand | Non-brand clicks, impressions, CTR, position, index coverage | Google Search Console; visibility and snippet decisions. | | Content acquisition | Eligible organic visitors/sessions by canonical landing page | Aggregate analytics; page/topic demand quality. | | Interim outcome | Matured organic signup rate | Aggregate analytics after defined maturity; use until strict activation passes QA. | | Primary outcome, future | Organic-sourced strict activations in own projects | Product + analytics after semantic and source-correlation QA. | | Retention/quality, future | Activated-user return and qualified-user measures | Only after each definition, window, and data grain is approved. | | Technical health | Indexed submitted-page ratio and good-CWV URL ratio | Search Console/CrUX or equivalent; diagnose search experience and index barriers. | Always display numerator, denominator, date window, timezone, maturity rule, filters, and suppression rules beside a rate. Keep Search Console clicks/impressions distinct from onsite sessions/visitors. Never join an individual's search query to product analytics. ### Access and data safeguards Before a decision-grade baseline, obtain read-only, least-privilege access or aggregated exports for: 1. Google Search Console performance, pages, index coverage, sitemaps, and CWV reports for the canonical property. 2. A canonical URL/content inventory: canonical URL, page type, topic cluster, owner, publish/update date, indexability, and redirect status. 3. An approved branded/non-brand query policy, including Mode/Modeinspect variants and generic-term ambiguity. 4. A signed-off conversion dictionary separating signup, demo completion, own-project onboarding, strict activation, meaningful return, and any future qualified-user metric. 5. Privacy-safe public-entry-to-server-outcome source correlation, plus aggregate PostHog reporting with bot/test exclusions. Do not provide raw persons, events, replays, full referrer/query-string URLs, code/repository data, prompts, customer exports, CRM notes, or credentials to a consultant by default. ## 9. 30/60/90 plan | Window | Priority actions | Must be true before advancing | |---|---|---| | Days 1–30 | Build a claim register; establish canonical URL/content and measurement inventories; validate the 404, host, indexability, metadata, and linking findings; choose a small topic set after first-party demand and conversion review. | Product validates support/workflow claims; Data confirms safe access and definitions; technical owner confirms deploy/canonical source. | | Days 31–60 | Revise a small set of proof-led category/use-case pages and supporting education; resolve the Figma route decision; link hub, spokes, proof, blog, comparison, demo, and pricing paths; begin weekly reporting. | Each strong statement is backed by an approved proof asset; public docs and tracking/canonical requirements are confirmed; no unsupported PR, framework, security, or outcome copy. | | Days 61–90 | Compare topic and landing-page cohorts using GSC visibility plus mature conversion quality; refresh or expand only evidence-backed clusters; create page-refresh and claim-revalidation rules. | Strict activation/source correlation is QA-passed for outcome interpretation; expansion follows observed demand and valid product proof, not invented volume or causal claims. | ## 10. Quick wins and first-week checklist ### Quick wins 1. Verify and repair the `www` to apex redirect failure. 2. Resolve public debug/backup index-safety and confirm live metadata/robots behavior. 3. Repair canonicals, page-specific social metadata, duplicated title construction, and misleading sitemap dates. 4. Resolve or redirect the observed `/figma-to-code` 404 before pursuing Figma-oriented content. 5. Add descriptive, contextual links to weakly linked use-case, comparison, and blog pages; decide whether thin/temporary pages merit indexation. 6. Establish GSC plus aggregate analytics baselines and separate demo onboarding, own-project onboarding, and strict activation before setting outcome targets. ### First-week checklist - [ ] Confirm Modeinspect-first naming and the approved message/claim register. - [ ] Receive approved read-only GSC and aggregate analytics access. - [ ] Confirm canonical marketing repository, deployment, DNS, and technical-remediation owners. - [ ] Recheck live sitemap, robots, canonical host, redirects, route statuses, and indexability before assigning fixes. - [ ] Revalidate public homepage, use-case, pricing, comparison, customer-story, trust, and changelog sources. - [ ] Reproduce the Figma-route and weak-internal-link findings before remediation. - [ ] Approve the SEO attribution, UTM, and event-definition plan with Data; never use internal UTMs or tag natural search visits. - [ ] Select one pillar and two supporting pages only after demand, claim, and proof gates are met. ## 11. Ownership, dependencies, and open questions | Need or decision | Recommended owner | Open dependency | |---|---|---| | Product facts and claim approval | Mode Product + Product/Engineering | What current support, sharing, GitHub/PR, and trust statements are publishable? | | Technical remediation | Web/Engineering | Which source/deployment is canonical, and who owns DNS/edge behavior? | | Measurement and baseline | Mode Data | Can GSC and aggregate attribution access be granted; are funnel semantics and correlation decision-grade? | | Query/competitor/customer research | SEO consultant + Mode Research | Which clusters have qualified demand, and what customer language/evidence supports them? | | Proof assets and content publishing | Content/Growth + Product | Which demo, customer story, or workflow evidence is approved for public reuse? | | Public docs/changelog/feedback governance | Product/Growth + Engineering | What should be indexed, cross-linked, and maintained across public surfaces? | ## 12. Public-safe source index Internal canonical Mode sources are deliberately not named or linked in this publishable note. Before any external use, the responsible Product owner must validate each product statement against the current approved internal product-truth source and retain that audit trail in a non-published workspace. This preserves source grounding without exposing internal Vault navigation or treating this note as authority for live product state. ### Public Modeinspect sources - [Homepage](https://modeinspect.com/) - [AI Prototyping](https://modeinspect.com/ai-prototyping) - [Design QA](https://modeinspect.com/design-qa) - [Developer Experience](https://modeinspect.com/developer-experience) - [Prelude customer story](https://modeinspect.com/customers/prelude) - [Marketing sitemap](https://modeinspect.com/sitemap.xml) - [Marketing robots](https://modeinspect.com/robots.txt) - [Public changelog](https://feedback.modeinspect.com/en/changelogs) ### External/category primary sources to recheck before comparison publishing - [Onlook](https://www.onlook.com/features) - [Noon](https://noon.design/) - [Wonder](https://wonder.design/) - [Paper](https://paper.design/) - [Subframe](https://docs.subframe.com/learn/introduction) - [Magic Patterns](https://www.magicpatterns.com/) - [Tempo](https://www.tempo.new/) - [Frontman](https://frontman.sh/) - [Puck](https://puckeditor.com/) - [Codux](https://www.codux.com/) Every external publication must recheck the listed current primary source and its date. This note records dated observations and recommendations only; it does not establish live product state or authorize publication.