---
name: build-personal-brand-website
description: "Give people one place to check who you are and what you do."
category: Personal Branding
stage: —
definitive_article: /personal-brand
status: needs-work
---

# Build personal brand website

Give people one place to check who you are and what you do. This guide helps you build a site with real work, clear facts and a way to reach you. Start with the name you use and proof you can share.

**The path:** Facts + real proof → Site preview → Content and function checks → Approved launch

**Start when:** The person controls the chosen domain and needs a new or improved public home for their work.

## Inputs

- [Register or verify the name domain](https://local-service-spotlight.github.io/task-library/?task=register-personal-name-domain#task-register-personal-name-domain) with its actual owner and hosting plan.
- Approved bio, real headshots, work stories, permission for named proof, current social URLs and public contact path.
- [Goals, Content, Targeting: the result, source material and people served](https://blitzmetrics.com/gct-business-strategy/) brief, accepted build/deployment scope, current source or builder, and measurement requirements.

## Steps

1. Inspect any existing site, source owner, pages, mail setup and current links before planning changes. Improve the maintained site in place when possible. Separate the content build from domain registration, DNS changes, hosting charges and public launch authority.
2. Build the first screen around who the person is, what they do and useful proof for the intended reader. Use two or three plain sentences at grade five or below, a real photo or evidence-backed diagram, and one clear next step. Preserve the person’s authentic voice.
3. Build About, work/method, evidence and contact sections from verified source material. Explain each named result with its scope and source. Keep first person for the person’s own account, attributed quotes for others, and remove empty promises rather than inventing testimonials.
4. Use real photos and relevant usable video when available, with captions and context. Keep a missing video as an asset gap. Check embeds silently, muted at zero volume; a working embed is not proof that an unheard audio track is intelligible.
5. Add useful routes to the person’s verified profiles and related work. Apply [entity linking, choosing the right home for a named person or topic](https://blitzmetrics.com/entity-linking/) and the [SEO Tree, the map from proof pages to main topics and offers](https://blitzmetrics.com/seo-tree/). Prepare the structured identity markup through its dedicated task so a theme, plugin and custom block do not create competing Person identities.
6. Check a preview at desktop, laptop and mobile widths: readable first screen, useful visual, unclipped face and buttons, valid links, clear contact path and no horizontal overflow. Check HTTPS, indexing controls and the actual measurement plan before launch; a performance score is a measurement, not a universal three-second guarantee.
7. When launch is authorized, use the supported source/deployment rail and verify the normal public URL, saved content, media and contact behavior. Retain the exact revision and any failed gate. A preview remains a preview until the live domain passes.

## Definition of done (QA checklist)

Quality assurance (QA) means checking the actual result against its agreed requirements. Follow the [Article Guidelines](https://localservicespotlight.com/article-guidelines/).

- [ ] The first screen gives the intended reader useful facts, proof and a next step with a meaningful visual.
- [ ] Claims, media rights, author voice and entity links match evidence; the actual source is retained.
- [ ] Preview and live states, domain dependencies and function checks are recorded separately.
- [ ] The exact output, source revision, reviewer evidence and remaining owner action are saved.
- [ ] For any reader-facing output, the short grade-five opening states the reader’s useful outcome and supporting method or proof. The body delivers that promise; a useful authentic visual appears in the first screen. Retain exact text and quoted reviewer evidence.

## Example(s)

**Fictional teaching example. This is not a client result or proof of a completed run.**

A fictional builder has a name domain, three project photos and two approved customer quotes. The site preview shows those projects and a contact button. The old domain still hosts email, so the preview can pass design review while the web team prepares a separate domain change. Nobody calls the site live from the preview alone.

## Handoff and Content Factory context

[Add verified Person markup](https://local-service-spotlight.github.io/task-library/?task=implement-person-schema-with-sameas-links#task-implement-person-schema-with-sameas-links) receives the approved identity graph; [Set up the agreed public profiles](https://local-service-spotlight.github.io/task-library/?task=set-up-professional-social-profiles#task-set-up-professional-social-profiles) receives the site URL. The authorized launch owner receives the checked preview and exact remaining deployment work.

This task supports the [Content Factory: Produce, Process, Post and Promote](https://blitzmetrics.com/content-factory/). Identity, proof, access or coordination can support several stages. Use the real inputs and receiving owner above; this task does not create unrelated transcripts, clips or ads merely because the diagram has four stages.

## Start with an agent

Give the [AI worker](https://blitzmetrics.com/build-agents/) this recipe, the real inputs, desired result and actions already authorized. Ask for the saved output, sources, checks and next owner. A [skill is a written recipe](https://localservicespotlight.com/plugin/); loading one does not prove account access or perform the task. Use the [installation guide](https://localservicespotlight.com/install/) if reusable setup is needed. A ZIP is a source snapshot, not an access grant or automatic update.

Use the app’s actual supported tools and verified file/account access. Keep a missing human verification step with its real owner. Recurring work needs its own configured job, trigger, timezone and observed result; this guide creates no schedule. Before any media playback, mute the player and set its volume to zero. If silence cannot be verified first, use captions, frames, metadata or another silent check.

## Record the real execution

Open the run record when work begins. Keep one execution ID, starting recipe revision, real inputs and current state. Write the [meta article, the record of this execution](https://blitzmetrics.com/meta-article-prompt/) with actual steps, results, checks, failures and next owner. Writing is required; public release follows existing authority. Link it to this recipe and the [Task Library](https://local-service-spotlight.github.io/task-library/).

Reuse the same execution ID for internal checks, revisions, retries and meta writing. A blocked run stays open with its dependency and owner, without an invented finish time. Dated public examples and distinct verified execution counts remain separate. Propose the smallest source-backed recipe improvement when the actual evidence reveals a defect.


<!-- factory-layer:start -->

## Factory chain (do not treat this as isolated)

- **Phase:** —
- **Importance:** 3/5 `●●●○○` — frequency 3, revenue 3, gating 2 (supporting)
- **Suggested previous station:** —
- **Suggested next station:** —
These stations are generated neighbors, not verified prerequisites or handoffs. Follow the task’s actual Inputs and Handoff sections.
- **Handoff:** Save this task’s actual output, source, date and checks where the receiving owner can read them. Follow the Inputs and Handoff sections for its next step.

## Model routing (same factory, any engine)

- **This task's lane:** `any` — Any capable chat model (Claude, ChatGPT, Grok, Gemini). SOP following, drafts, checklists.
- **Single-engine path:** Use the capable AI app you already have. Check its required tools and access before starting. Pass the actual result and proof to the next task.
- **Optional multi-engine:** A tested local model may draft; a stronger model may review facts and voice. Use supported tools for approved actions. Pick models from observed quality and cost; a model name does not prove it can run this task.
- **Never** store the working state in one vendor's memory. Files in the Content Library are the bridge.

<!-- factory-layer:end -->
## Definitive article & links

- [Maintained source guide](https://blitzmetrics.com/personal-brand/)
- [This task in the Task Library](https://local-service-spotlight.github.io/task-library/?task=build-personal-brand-website#task-build-personal-brand-website)
- [Article Guidelines](https://localservicespotlight.com/article-guidelines/)
- [Definitive article and task recipe standard](https://blitzmetrics.com/definitive-article-guide/)
- [How recipes and run records fit together](https://localservicespotlight.com/meta-articles/)

## Review and evidence still needed

The inherited contributor status is `needs-work`. It is preserved, not promoted by this rewrite. That label alone does not prove document readiness, account access, an actual execution or a client result.

The fictional example teaches the method and does not fill a real-run evidence gap. A named semantic reviewer must check the actual opening, full method, sources and handoff. Check the useful opening visual in the normal rendered guide at the current required desktop and mobile sizes, including 1280 × 800 and 390 × 844. Source readability checks do not prove public presentation or task execution.