Services

Apps Studio

SEO review: apps/studio

Date: 2026-07-01

Indexability decision#

apps/studio should be blocked from public indexing. It is an authenticated/admin Studio surface for local or platform project management, not a public marketing/content app. Public search value is low, while indexed auth, organization, project, billing, API, and integration routes would create noisy SERPs and expose operational route structure.

Evidence:

  • Repository app catalog identifies apps/studio as “Local Supabase service studio,” not a public content surface (README.md:25-39).
  • The app has a large authenticated/admin pages-router surface: 180 non-API page files and 91 API route files were found under apps/studio/pages/apps/studio/app/api during this review.
  • Platform root redirects users into the authenticated organization area (apps/studio/next.config.ts:56-72); self-hosted root redirects into a default project dashboard (apps/studio/next.config.ts:108-109).
  • Representative pages are account, organization, project, billing, auth, database, storage, and integration dashboards (apps/studio/pages/account/security.tsx, apps/studio/pages/org/[slug]/billing.tsx, apps/studio/pages/project/[ref]/index.tsx).

Findings by severity#

High#

H1. No app-wide noindex control for an admin/studio surface#

The app sets global document/head metadata, but it does not emit either a robots noindex meta tag or an X-Robots-Tag response header.

Evidence:

  • Global head only sets title, viewport, description, one OG image, and googlebot=notranslate (apps/studio/pages/_app.tsx:167-172). notranslate is not an indexing block.
  • Global headers include security/referrer/cache headers but no X-Robots-Tag (apps/studio/next.config.ts:500-528).
  • No robots.txt or sitemap route/file was found under apps/studio during the audit.

Recommended fix:

  • Add a global X-Robots-Tag: noindex, nofollow, noarchive header for apps/studio, or add an equivalent global <meta name="robots" content="noindex,nofollow,noarchive" /> in pages/_app.tsx.
  • If any intentionally public unauthenticated callback/install routes must remain crawlable, keep the default blocked and explicitly document route-level exceptions.

Medium#

M1. Metadata is too generic for routes that are currently indexable#

Because indexability is not blocked, route metadata quality matters. Today the default metadata is app-wide and generic, with only partial page-title overrides in layouts/pages.

Evidence:

  • Default title and description are global (apps/studio/pages/_app.tsx:124, apps/studio/pages/_app.tsx:168-170).
  • Some layouts/pages override only <title>, for example project and organization layouts (apps/studio/components/layouts/ProjectLayout/index.tsx:218-219, apps/studio/components/layouts/OrganizationLayout.tsx:60-61).
  • The default social metadata only defines og:image; no global og:title, og:description, og:type, canonical, or Twitter card tags are present near the global metadata (apps/studio/pages/_app.tsx:167-172).

Recommended fix:

  • Prefer resolving H1 by blocking indexing globally.
  • If product requirements ever allow indexing for specific unauthenticated pages, add per-page title, description, canonical, Open Graph, and Twitter metadata for those explicit pages only.

Low#

L1. Manifest and favicon assets are present and linked, but they are not an SEO substitute#

The app has a good favicon/manifest baseline, but those assets do not control crawling/indexing.

Evidence:

  • _app.tsx renders MetaFaviconsPagesRouter with includeManifest (apps/studio/pages/_app.tsx:194-196).
  • The shared favicon component emits the manifest link when enabled (packages/studio-common/MetaFavicons/pages-router.tsx:84).
  • The manifest describes the Studio app and starts at / (apps/studio/public/favicon/manifest.json:2-10).

Recommended fix:

  • Keep the existing favicon/manifest setup.
  • Pair it with explicit noindex controls from H1.

L2. Heading semantics are acceptable for an admin app, but should not be relied on for search snippets#

Key dashboard/auth layouts render visible h1 headings, which is positive for accessibility and in-app semantics. Since Studio should be noindexed, this is not a primary SEO concern.

Evidence:

  • Auth layout renders the page heading as <h1> (apps/studio/components/layouts/SignInLayout/SignInLayout.tsx:145).
  • Project home surfaces render project names as <h1> (apps/studio/components/interfaces/ProjectHome/TopSection.tsx:63, apps/studio/components/interfaces/Home/Home.tsx:124).
  • Scaffold title primitive renders an h1 (apps/studio/components/layouts/Scaffold.tsx:69).

Recommended fix:

  • No immediate SEO-specific change required after noindex is added.
  • Continue using one meaningful page-level heading in newly added Studio pages for accessibility and internal orientation.

Structured data#

No public content pages were identified that warrant structured data. Given the admin/studio purpose and recommended noindex posture, do not add JSON-LD unless a future explicitly public, indexable landing page is introduced.

  1. Add global noindex/nofollow/noarchive control for apps/studio.
  2. Decide and document any route-level crawl exceptions, if product requirements need them.
  3. Only for explicit public exceptions, add complete route-specific canonical, OG, and Twitter metadata.