---
title: "Sources"
description: "The first setup step: giving Blogged enough evidence about your product for everything downstream to be grounded."
updated: "2026-08-28"
verifiedAgainst:
  - apps/web/lib/server/onboarding-status.ts
  - packages/shared/src/onboarding-evidence.ts
  - packages/shared/src/scans.ts
  - apps/web/lib/server/bootstrap-security.ts
  - apps/web/lib/firebase-app-check.ts
---

Nothing in Blogged runs on a description of a product it has not seen. The first
step exists to gather that evidence, and it is the only step with no
prerequisite.

## Three ways to provide evidence

<Tabs>
  <Tab label="Scan your website">
    Give the URL of your product site. Blogged reads the public pages and pulls
    out what the product is, who it is for, how it is positioned, and the visual
    identity used later at the theme step.
  </Tab>
  <Tab label="Write a description">
    Describe the product yourself. This is the route for a product with no public
    site yet, or one whose site does not say what the product actually does.
  </Tab>
  <Tab label="Upload files">
    Add documents: a product brief, a deck, a positioning doc. Readable files
    count as evidence in their own right.
  </Tab>
</Tabs>

You can combine all three, and combining them produces the best result.

## What completes the step

The step completes when there is **enough evidence**, from any combination of
those three, rather than when a scan specifically has finished.

<Callout variant="note">
  This distinction is load bearing. Gating on the scan would make the written
  description and the uploaded files decorative, because neither could ever get
  a Project past the first step.
</Callout>

## If the scan does not finish

A scan can fail on a site that blocks automated readers, or one that renders
everything client side behind an interaction. That is not a dead end: write the
description, upload what you have, and continue. You can add the site again
later from Project settings.

Blogged identifies itself when it reads a page. See
[BloggedBot](/reference/crawler) for what it accesses and how to exclude a site.

## If setup never opened at all

A [Free grant](/billing/free-grant) is issued before your workspace exists, so
two checks run ahead of this step rather than inside it.

<PropertyList>
  <Property name="A verified email address">
    Signing up with an email address and a password sends a verification email
    first, and the workspace is created after you have clicked it. Signing in with
    Google needs nothing extra: the address is already verified.
  </Property>
  <Property name="A browser that can store one identifier">
    Free signup writes a single device identifier into your browser's site
    storage. A browser or extension configured to block all site storage for
    Blogged cannot complete signup, and the message says the browser could not be
    verified rather than blaming your details.
  </Property>
</PropertyList>

<Callout variant="warning" title="Changing your email address later stops generation">
  Verification is not only a signup gate. While a Project runs on the Free grant,
  the routes that cost money to run check that your current address is still
  verified. Changing the address on your account puts it back into an unverified
  state, and drafting, images and topics are refused until you verify the new one.
  Nothing is lost, and verifying is the whole fix.
</Callout>

## Next

The evidence unlocks the [theme step](/onboarding/theme).