Your first SEO baseline: step by step before the work begins

The first SEO baseline becomes the reference for every later comparison. If it uses the wrong domain, stale evidence, or an unclear page scope, later reports can be precise and still tell the wrong story. This guide turns the baseline principle into a practical setup sequence.

Step 1: name the project and canonical website

Confirm the exact public website, including protocol and preferred hostname. Decide whether www and non-www addresses redirect consistently. Do not connect a staging environment or an old domain by accident.

Record the project owner and the business context. The baseline identifies a technical project; it does not transfer account authority or billing responsibility.

Step 2: define the pages in scope

List the highest-priority pages and the maximum crawl scope available under the plan. Include representative templates such as the home page, services, categories, products, articles, and contact pages where relevant.

Document excluded areas. Pages behind authentication, blocked paths, and URLs beyond the configured limit are not covered. A baseline should be honest about partial visibility.

Step 3: confirm public access

Open the canonical pages without an authenticated session. Check redirects, response codes, robots rules, and obvious server errors. A crawler must be able to request the content it is expected to compare.

If a security service blocks automated requests, resolve the access pattern safely rather than weakening protection for the entire site.

Step 4: install and connect WordPress evidence

If the product requires a WordPress plugin, install the official artifact, bind it to the correct project, and verify the connection. The plugin should use scoped credentials and must not expose secrets in the interface or logs.

Use the plugin action to synchronize evidence immediately before activation. Confirm that the evidence timestamp is fresh and that the reported hostname matches the project.

Step 5: review tracking choices

Understand which WordPress events and active-time signals are supported. If active-time tracking can be disabled, decide who owns that preference. Explain that missing time will not be estimated.

Make sure the team knows that recorded activity, public observations, and actor attribution are separate fields.

Step 6: activate the project

Activation establishes the baseline slot and project lifecycle. Review plan capacity, page limit, expected scan cadence, and any cooldown or switching rules before confirming.

Avoid repeated clicks or parallel setup sessions. The activation flow should be idempotent and show a clear pending state while the scan is being prepared.

Step 7: validate the first scan

When the baseline completes, inspect more than the total count. Confirm:

• the canonical hostname and website URL
• the number and identity of covered pages
• the timestamp and reporting time zone
• successful, unavailable, and failed parameter statuses
• fresh WordPress evidence where required
• no unexpected redirects to another environment
• no raw internal keys or sensitive values in customer-facing output

The first scan is a baseline, so it may not contain a change report. That is expected. Changes become observable when a later comparable scan exists.

Step 8: record known exceptions

Write down planned migrations, scheduled campaigns, temporary pages, dynamic elements, and source limitations. This context will help explain later differences without rewriting the baseline.

If an important source was unavailable, consider correcting the setup before accepting the baseline. Do not convert an unavailable result into “not detected.”

Step 9: schedule the first comparison

Confirm when the next scan is expected and who will review it. For a weekly cadence, choose a predictable day and explain that provider timing or retries can affect the exact completion time.

Before a manual pilot test scan, synchronize WordPress evidence again so the report does not use a stale snapshot.

Step 10: agree on the review questions

Use the same questions for the first comparison:

1. Which pages changed?
2. Were the changes expected?
3. Which values have clear before-and-after evidence?
4. Was source coverage complete?
5. Is attribution supported or only suggested by timing?
6. What needs confirmation in the next period?

This turns the baseline into an operational process.

Common setup errors

Do not use a screenshot as the only baseline. Do not mix production and staging. Do not accept stale plugin evidence. Do not expand the page scope silently after the first scan. Do not assume a successful connection means every supported event has historical data.

If measurement definitions change later, version the change and mark the comparison boundary. Historical reports should remain readable and immutable.

Conclusion

Your first baseline should be boring in the best way: correct website, clear scope, fresh sources, stable definitions, visible coverage, and a known next scan. It does not need to judge the site. It needs to preserve a trustworthy starting point.

Read How to create a credible SEO baseline for the underlying principles, then use weekly SEO monitoring to maintain the timeline.