SEO Foundation: fixing the plumbing without touching the brand
When the brand relaunched, the site looked right — but the technical foundation underneath was missing. Here's how I diagnosed it, fixed it, and proved each fix, without changing a pixel of the frozen brand.
01Initial state
A freshly rebranded marketing site with no technical SEO infrastructure. robots.txt and sitemap.xml didn't exist — requests for them returned the homepage HTML. www served a 200 instead of redirecting to the apex, splitting the site across two hosts. And there was no structured data — nothing machine-readable saying who this is. A full audit found 0 Critical, 2 High, 1 Medium.
02Constraints
- The brand was frozen. No changes to branding, layout, or copy — the foundation had to be fixed underneath a finished design.
- The live site is the source of truth — document what it does; don't redesign it.
- Some steps needed access I didn't hold — the server-level redirect (sudo) and Google/Bing verification (owner login). Those were prepared, not faked.
- A footgun: the static server returns the homepage for any missing path, so naïve file checks give false positives. Verification had to be done against reality.
03Objectives
Fix the crawl / index / canonical fundamentals; give the site a machine-readable identity; document every decision and change; and prepare the ground for authority growth — all without reopening the brand.
04Research
A full technical audit against the live site, where every finding was backed by a real command output rather than an assumption — confirming the missing files, the www duplication, and the absent structured data, and locating where DNS was managed for later verification. No speculative fixes: confirm the issue is real before proposing anything.
05Decisions
The durable calls that constrained the work — and still do: the brand stays frozen; optimize for operations, systems, automation, and AI and against legacy "virtual assistant / task-labor" terms; the Person is the primary entity; the canonical role is "Business Operations & Technology Partner"; and audit before implementing — design is written before code.
06Implementation
Small, reversible batches — never a big-bang:
- robots.txt + sitemap.xml as real files with correct content-types; the sitemap lists the single canonical apex URL.
www→apex 301 at the web-server layer — but staged as a script with a timestamped backup that auto-reverts if the config test fails, then applied by the owner (the privileged step).- Person + WebSite JSON-LD added as a pure insertion into the homepage
<head>— no visible content, metadata, or layout touched.
07Validation
Every change was verified against the live site: the JSON-LD parses in both source and served HTML; the @graph is exactly Person + WebSite; the WebSite's publisher resolves to the Person; the entity's facts (name, role, URL) are identical across the title, Open Graph, Twitter, schema, and docs; and after each change, robots / sitemap / redirect / canonical were regression-checked. Nothing was "done" until it was verified.
08Results — and you can check them yourself
A technically sound, structured, fully documented search foundation on a single canonical host. Unusually for a case study, the proof is the running site — verify it right now:
Independently verifiable
- robots.txt →
200 text/plain, and it points to the sitemap. - sitemap.xml →
200 application/xml, canonical apex URLs. - www.darceesellers.com → a single
301to the apex. - The homepage carries valid
Person+WebSiteJSON-LD.
Honest about what's not done. One item is deliberately left open and labeled: Google Search Console / Bing verification, which needs the site owner's login. I don't claim search-traffic or ranking results here — that measurement unlocks once verification is complete. The numbers I'd stand behind are the ones you can check above.
09Lessons learned
- Small, validated batches beat a big-bang. Every change was a pure, reversible increment, verified live before the next.
- Documentation-first made implementation mechanical. Auditing and designing before writing meant the build was unambiguous.
- Entity consistency beats excessive schema. A small, accurate, internally-consistent graph is worth more than a sprawling one with contradictions.
- Technical fixes are necessary but not sufficient. A clean foundation earns nothing on its own — content quality is what earns authority. (This library is that next step.)
- Surface constraints honestly. Two steps needed access I didn't have; the right move was to prepare exact, safe, ready-to-run steps and mark what was pending — never to claim completion.
10The reusable pattern: Map-Then-Build
The shape of the whole engagement is the reusable one: map the real current state, decide and design, build the path, validate live, document, and commit — doing the thinking and the building, and staging the risky, privileged changes for approval instead of forcing them. That's Map-Then-Build applied to a technical foundation; it's the same discipline whatever the domain.
Consultants hand you an audit. I hand you the fixed foundation — audited, built, validated, and documented — and I can prove every piece of it.