Frontend: The site is invisible to search engines and social previews — no sitemap, robots or structured data

[Emmy123222]

Goal this serves — Donors finding the platform at all

Why this matters

A public donation platform depends on being findable. Someone searching for a reforestation project to support should be able to arrive at a project page from a search engine. Today they cannot, because nothing tells search engines the pages exist.

The same gap affects sharing: a donor posting a project link gets no title, description or image preview, which measurably reduces click-through on exactly the channel that grows a donation platform.

Evidence

$ git grep -lIiE 'next-seo|sitemap|robots' -- frontend
(no matches)
$ ls frontend/public/
(no robots.txt, no sitemap.xml)

Project pages are server-rendered on demand — _app.tsx forces server-side rendering so the CSP nonce reaches every script — so the content is available to crawlers. Nothing declares it. There is no canonical URL handling, no Open Graph or card metadata, and no structured data describing projects or the organisation.

Why this is hard

A sitemap over dynamic content must stay current. Projects are created and change status continuously, so the sitemap has to be generated rather than committed, and must reflect visibility rules — unlisted or rejected projects must not appear.

Structured data invites scrutiny. Marking up a project with donation and organisation metadata makes claims machine-readable, which means unverified impact figures would be published in a form aggregators consume. What is safe to expose depends on provenance.

Preview images need generating. A useful share preview is project-specific, which means generated images, which means caching and invalidation.

Interaction with the CSP. The existing nonce-based policy is strict, and metadata and image generation must fit within it rather than loosening it.

Suggested approach

Generate the sitemap from live project data, honouring visibility rules, and serve it alongside a robots policy that reflects which routes should be crawled.

Add per-page metadata with canonical URLs, and structured data for projects and the organisation — restricted to claims the platform can stand behind.

Generate share images per project with a caching strategy, and verify the result against real crawler and social-platform validators rather than assuming correctness.

Acceptance criteria

• A sitemap is generated from live data, honours visibility rules, and excludes unlisted and rejected projects.
• A robots policy is served and reflects which routes should be crawled.
• Every public page has title, description and canonical URL metadata; duplicates under different URLs resolve to one canonical.
• Structured data is emitted for projects and the organisation, restricted to claims the platform can stand behind.
• Share previews render correctly, verified against real social-platform validators.
• Generated preview images are cached with a defined invalidation strategy.
• All additions comply with the existing nonce-based CSP without loosening it.
• Crawlability is verified with a real crawler against a deployed build, not only in unit tests.
• Unverified impact figures are not exposed as machine-readable factual claims.

Scope

Roughly 5,000–7,000 lines, including tests.

Relevant files

• frontend/pages/_app.tsx
• frontend/pages/projects/[id].tsx
• frontend/middleware.ts
• frontend/next.config.mjs

Related

Structured data should distinguish verified from unverified impact claims — see the impact provenance work.