Build log / Website Phase 1
Website Phase 1: 34 pages of serpdad.com, shipped on 21 Oct 2026.
This build log entry covers Phase 1 of the serpdad.com website: how we picked 34 pages from a plan scored with Ahrefs data, wrote them in parallel, checked every page with automated tests, and caught a production bug before launch that would have hidden three of them.
No traffic numbers in this entry. The pages are too new to report on.
What shipped. The pages that answer three launch questions.
Phase 1 had one job: answer the three questions a new visitor asks. What is SerpDad? Why trust it when it has no customers? Why switch from Surfer or Clearscope?
That gave us 34 pages, plus two redirects (/start/ and /login/). Some were new, some replaced pages from the old site. The homepage stayed as it was and now links to the new pages.
How we picked them, and which keywords we chose not to chase, is its own entry: how we chose the pages.
| Group | Examples |
|---|---|
| Product | Product hubs, page plan, AI visibility, bring your own keys, integrations, workflows |
| Solutions | Agencies, in-house SEO |
| Compare | SerpDad vs Surfer, vs Clearscope, two alternatives pages |
| Templates and tools | Monthly SEO report, content brief, three free tools |
| Company and trust | About, refusals, security, build log, founding customers, contact |
| Conversion | Pricing, onboarding call |
How we wrote them. One plan, one brief, many writers at once.
A plan scored with Ahrefs data
Every candidate page had a search demand score from Ahrefs (US, 21 Oct 2026). Pages with real demand and low difficulty went first.
Written in parallel
The pages were written at the same time from one shared brief: the voice, the product facts, the copy rules and a fixed set of page components.
Each writer owned its files
No two writers touched the same page. Shared parts, like the header and the page layout, changed only in one place.
How we checked them. A test suite reads every page before it ships.
Copy rules are easy to agree on and easy to break. So the rules are tests, and a page that breaks one does not ship.
| Check | Why it exists |
|---|---|
| Exactly one H1 | One clear topic per page, for readers and for search engines. |
| Title up to 60 characters | Long titles get cut off in search results. |
| Description up to 155 characters | Same reason, for the snippet under the title. |
| No long dashes | A house style rule. Commas, colons and full stops do the job. |
| No ranking promises | A banned-word check. No tool can promise a ranking, so no page may. |
| No SEO plan keywords in titles or H1s | Marketing pages must not compete with the 791 pages our SEO plan owns. |
| FAQ markup matches the visible text | The structured data says exactly what the page says. |
| Every internal link resolves | No page links to a page that does not exist. |
| No forms, and a pre-launch switch | With pre-launch mode on, no page links to the app and every call to action becomes an email. |
The keyword check is the one we care about most. It is the same rule as our own product: one owner page per keyword, and no two pages chasing the same queries.
What the tests missed. A redirect bug, caught before launch.
Every test passed. The pages were still going to be hidden. The tests read what the app renders, not what the web server in front of it does.
Two redirect rules from the old site were still in the server config. One sent everything under /solutions/ to /product/. The other sent /tools/intent-checker/ to the app. Both would have hidden new pages: agencies, in-house SEO and the Intent Checker page.
Then a second problem: the server only read its config when it started, and a deploy left the running server alone. So even a fixed config would not have loaded.
- Removed the two old redirect rules
- Pointed the old /founding/ link at /founding-customers/
- Made every deploy restart the web server so a new config loads
- Checked the live URLs after the deploy, not just the tests
One more fix. /start/ now keeps your UTM tags.
/start/ is the sign-up link we share outside the site. It sends people on to sign-up. It used to redirect inside the page, and that kind of redirect drops the query string. So a link like /start/?utm_source=linkedin arrived with no source at all.
Now the web server does the redirect, and the query string goes with it. In a pre-launch build there is no redirect, and /start/ shows an email invite instead.
What we're not reporting. No traffic numbers yet.
These pages went live on 21 Oct 2026. Any traffic number now would be noise, so this entry has none.
When Search Console has enough data, a later entry will report it in our fixed format: impressions on these pages went from X to Y, and we can't prove the pages caused it.
Plan your own pages the same way.
Run your first 1,000 keywords free.
Your first plan is free up to 1,000 keywords, with briefs for the top 5 pages. No card needed.