How to Prepare for Your Alesta Domain Baseline

Prepare for an Alesta domain baseline by choosing the canonical public domain, naming the decision the baseline should inform, checking that important pages are accessible, and assembling a small set of approved company facts. The baseline can start from public evidence, but your review determines whether the extracted identity, competitors, and strategy context are correct.

What you need

Before you begin, identify:

• the public production domain;
• the person who can confirm company and product facts;
• the person who understands the website or engineering context;
• the marketing decision you want to inform;
• important markets, languages, and subdomains;
• known access controls or recent migrations;
• a short list of customer-named alternatives, if available.

You do not need to prepare a complete marketing strategy. The purpose of the run is to establish and correct the starting context.

Step 1: Choose the correct domain

Use the canonical public site, not:

• a staging or preview URL;
• an authenticated application route;
• a tracking redirect;
• a campaign microsite that does not represent the business;
• a regional domain without noting the intended market;
• a documentation host when the main company domain is the subject.

If the company uses several public domains, choose the one tied to the current decision. Record how the others relate to it.

Domain scope worksheet

Canonical domain:
Primary market and language:
Important subdomains:
Separate brands or legal entities:
Recent redirects or migrations:
Public app or documentation hosts:
Known pages outside public access:

Step 2: Name one decision

Complete this sentence:

We are building this baseline to decide whether to [decision] for [audience, page, product, or market] before [date or commitment].

Examples:

• rewrite the homepage before increasing acquisition;
• validate the competitor set before a positioning workshop;
• choose technical SEO investigations for the next quarter;
• align the public product story before a launch.

Avoid "improve all marketing." A specific decision makes the findings easier to rank.

Step 3: Confirm public access

Open the site in a private browser window and check the main paths without relying on employee authentication.

Confirm:

• the canonical domain resolves;
• redirects reach the intended origin;
• the homepage and important public pages load;
• content is not accidentally behind login or a geographic block;
• robots.txt and other controls reflect the intended public policy;
• the production site is not serving a maintenance or error page;
• the page does not require an unsupported interaction to reveal its primary content.

Do not weaken security or access controls to make an audit pass. Record private surfaces as outside scope.

Step 4: Assemble an identity card

Prepare a short reference that a reviewer can use after the run:

Approved company name:
One-sentence description:
Primary audience:
Primary offer:
Product category or frame:
Current plans or availability constraints:
Main public CTA:

The identity card is not fed in to force the result. It helps the team compare what the website communicates with what the company believes.

When the two differ, investigate whether the site is outdated, the approved description is untested, or the extraction is wrong.

Step 5: Note important page roles

List one current URL for each relevant role:

• homepage;
• primary product or service;
• pricing or offer;
• documentation or implementation;
• customer proof;
• key educational content;
• policy page when it affects trust or data use.

Alesta's current baseline uses a bounded crawl and content sample. The list helps the reviewer notice when an important role was not represented. It does not turn the baseline into an unlimited crawl.

Step 6: Prepare competitor corrections

Write down alternatives from actual customer or sales evidence if you have them:

• direct product;
• adjacent platform;
• service or agency;
• spreadsheet or internal tool;
• status quo or no decision.

Do not try to preapprove every competitor. Use the list to adjudicate Alesta's proposals after the run.

Step 7: Set data expectations

The public baseline can use available domain, performance, technical, on-page, and competitor evidence. Expect partial states.

Important limits:

• field performance data may be unavailable for a URL or origin;
• a bounded crawl does not cover every page or state;
• the system does not automatically know private analytics, CRM, revenue, product usage, or customer research;
• backlinks and observed AI mentions are not part of the inspected live free onboarding flow;
• a one-time onboarding baseline is not continuous monitoring;
• generated documents need human review.

Missing must remain missing. Do not interpret unavailable data as zero.

Step 8: Choose review owners

Assign people before the run:

Review area	Suggested owner
Company identity and strategy	Founder or marketing lead
Product capability and availability	Product owner
Website and technical evidence	Web or engineering owner
Competitors and buyer alternatives	Product marketing and sales
Claims and proof	Marketing plus legal where required
Final priority	Decision owner

One person may hold several roles in a small company. The responsibilities should still be explicit.

Step 9: Run the baseline once the site is ready

Enter the canonical domain, create the workspace, and let the onboarding analysis complete as far as available sources permit. Avoid making major site changes while trying to interpret one run because the evidence can span different retrieval moments.

If a source fails, preserve the status. Do not repeatedly change the domain to obtain a more favorable output.

Step 10: Schedule the review

Book a short evidence review with this order:

1. identity;
2. source availability and scope;
3. performance and technical evidence;
4. competitor set;
5. product and strategy documents;
6. one next decision.

The first week with Alesta guide provides the full sequence.

Preparation checklist

• Canonical public domain selected
• Market, language, and subdomain scope recorded
• One decision and deadline named
• Important public pages accessible
• Approved identity card available for comparison
• Current product and plan constraints noted
• Customer-named alternatives available if possible
• Review owners assigned
• Public-data limitations understood
• Review meeting scheduled

Common preparation problems

The site is mid-migration

If possible, wait until canonical routing and key content stabilize. If the decision cannot wait, record the migration state and treat findings as temporary evidence.

The app and marketing site use different domains

Choose the marketing domain for the public baseline unless the decision specifically concerns a public app surface. Record the relationship and private states outside scope.

The company has no approved one-sentence description

That is useful context. Ask leaders to draft independent versions and use the baseline to expose the public version. Do not hide disagreement.

The team wants a full site crawl

Use a specialized technical crawl and appropriate access in addition to the baseline. Alesta's public onboarding sample should not be represented as complete coverage.

What to do next

After the run, begin with correctness. Confirm what Alesta thinks the company is before reviewing generated strategy. Then follow the founder baseline scenario or the AI marketing audit guide for a wider decision process.