Services

Apps Www

SEO review: apps/www

Date: 2026-07-01

Scope: apps/www Next.js App Router metadata, canonical/Open Graph/Twitter tags, robots/sitemap behavior, structured data, headings/content semantics, public assets, and deployment headers. Existing user-changed files were not modified.

High severity#

1. robots.txt advertises a sitemap URL that the app does not publish#

Evidence

  • apps/www/public/robots.txt:5 declares Sitemap: https://www.assistance.bg/sitemap.xml.
  • apps/www/public/sitemap_www.xml:2 is the only sitemap-like file in public/ (urlset begins there); there is no apps/www/public/sitemap.xml and no App Router app/sitemap.ts.
  • apps/www/next.config.mjs:75 sets output: 'export', so only static files/routes generated at build time will be available.

Impact

Search engines requesting the advertised https://www.assistance.bg/sitemap.xml are likely to receive a 404, reducing crawl discovery for static marketing, service, pricing, runner, training, and case-study pages.

Recommended fix

Publish a real /sitemap.xml for apps/www and point robots.txt at it. Prefer a generated sitemap that covers current App Router routes and static content, or rename/copy sitemap_www.xml to sitemap.xml if it is intentionally complete.

2. Organization JSON-LD points at a missing logo asset#

Evidence

  • apps/www/lib/constants.ts:46 defines ORGANIZATION_LOGO_PATH = '/images/og/assistance-logo.png'.
  • apps/www/components/JsonLd.tsx:36 uses that path as the Organization.logo; apps/www/components/JsonLd.tsx:140 uses it for BlogPosting.publisher.logo.
  • File check found apps/www/public/images/og/assistance-og.png, but not apps/www/public/images/og/assistance-logo.png.

Impact

Structured-data consumers receive a broken logo URL, which can invalidate or downgrade rich-result eligibility for organization and article-like entities.

Recommended fix

Add the referenced logo asset at public/images/og/assistance-logo.png or update ORGANIZATION_LOGO_PATH to an existing crawlable logo image.

Medium severity#

3. Several metadata blocks hard-code the apex domain instead of the canonical www origin#

Evidence

  • Global metadata uses SITE_ORIGIN and metadataBase (apps/www/app/layout.tsx:42, apps/www/app/layout.tsx:54), and SITE_ORIGIN resolves production to https://www.assistance.bg (apps/www/lib/constants.ts:36-42).
  • Some pages bypass that shared helper and hard-code https://assistance.bg, including apps/www/app/about/page.tsx:12-14, apps/www/app/saas/page.tsx:31-33, apps/www/app/(pages)/company/page.tsx:11-13, apps/www/app/(pages)/customers/page.tsx:16-18, apps/www/app/(pages)/events/page.tsx:16-18, apps/www/app/(pages)/support/page.tsx:24-26, apps/www/app/(pages)/compare/[slug]/page.tsx:31-33, and apps/www/app/runners/[slug]/page.tsx:119-121.

Impact

Open Graph URLs/images and some per-page metadata disagree with the declared production origin. If the apex and www both resolve, crawlers may see mixed canonical signals and social previews may cache separate URL identities.

Recommended fix

Use pageMetadata() or SITE_ORIGIN consistently for page-level metadata. If the apex should be canonical, update SITE_ORIGIN, robots.txt, and headers together; otherwise migrate hard-coded https://assistance.bg metadata to https://www.assistance.bg.

4. Some indexable pages define Open Graph metadata without explicit canonical alternates#

Evidence

  • apps/www/app/about/page.tsx:5-14 defines title/description/Open Graph, but no alternates.canonical.
  • The shared helper does set a canonical (apps/www/lib/metadata.ts:23-26), and many newer pages use it, for example apps/www/app/page.tsx:21-27.

Impact

Pages without explicit canonical alternates rely on inherited/root behavior instead of asserting their own URL. This weakens duplicate handling for routes that may also be reachable through redirects, apex-vs-www variants, or campaign links.

Recommended fix

Convert hand-written metadata blocks for public marketing pages to pageMetadata() or add explicit alternates.canonical values.

Low severity#

5. Web app manifest copy still describes an old Postgres platform positioning#

Evidence

  • apps/www/public/favicon/manifest.json:2-4 names the app Assistance but describes it as The Postgres development platform.
  • Current site metadata positions the product as DevOps/SRE/cloud infrastructure services (apps/www/lib/constants.ts:43-45, apps/www/app/page.tsx:14-17).

Impact

This does not affect normal ranking directly, but installed-app metadata and some crawler previews can surface stale product positioning.

Recommended fix

Update the manifest description to match the current DevOps/SRE/Kubernetes consulting positioning.

Positive findings#

  • Root metadata includes metadataBase, default title/description, Open Graph image dimensions, Twitter card fields, and favicon/apple icon declarations (apps/www/app/layout.tsx:42-72).
  • The shared pageMetadata() helper emits absolute canonical, Open Graph, and Twitter image URLs from the same origin (apps/www/lib/metadata.ts:12-48).
  • The homepage includes both site-wide Organization JSON-LD via root layout and WebSite JSON-LD (apps/www/app/layout.tsx:97, apps/www/app/page.tsx:47).
  • Key service/resource pages add domain-relevant Service, BreadcrumbList, and FAQPage JSON-LD (apps/www/app/consulting/page.tsx:120-130, apps/www/app/infrastructure/page.tsx:157-167, apps/www/app/runners/page.tsx:127-140, apps/www/app/pricing/page.tsx:17-31).
  • Sensitive auth/dashboard entry points are explicitly noindexed where expected (apps/www/app/dashboard/sign-in/page.tsx:7), and deployment headers block indexing on preview hosts (apps/www/public/_headers:28-34).
  • Primary marketing and commercial pages use real <h1> headings in the rendered components, for example homepage hero (apps/www/components/Hero/HeroStatic.tsx:76), pricing (apps/www/app/pricing/PricingContent.tsx:33), services (apps/www/app/(pages)/services/ServicesContent.tsx:350), and case studies (apps/www/app/case-studies/CaseStudiesListClient.tsx:142).