Sample deliverable · August 2026
A real Health Check. Run on this website.
In August I found out that the booking widget on this site — the only way anyone becomes a client — was broken. Not down. Broken only after certain navigation paths, in a way no error log recorded and no monitoring I had would have caught. I don't know how long it was like that, which is part of the problem.
I sell a Technology Health Check: $2,500, two weeks, and you get a written report on what is actually going on in your product. The awkward part of selling audits is that every report I write belongs to a client and is confidential. I can tell you the reports are good. I can't show you one.
So here is the next best thing — a real Health Check, in the format a client receives, run on the one codebase I can publish without asking anyone's permission. It found three defects. One of them had quietly disabled the only thing on this site that makes money.
A fair caveat about scale: this is a small static site, not a SaaS product with a backend, a database, and a team pushing code. Your system is bigger and your report would be longer. The method — symptom, root cause, business impact, fix, verification, and what should have caught it sooner — is the one I'd run on yours.
Summary
Findings
| ID | Finding | Severity | Impact | Effort |
|---|---|---|---|---|
| F-1 | The booking widget was dead after any internal navigation | Critical | The only revenue path on the site | One HTML attribute, ×3 |
| F-2 | Every page told Google its canonical URL was an address that redirects | High | 32 pages excluded from the index | One helper function |
| F-3 | The best-converting offer had no links pointing at it | Medium | Three pages unreachable, including the free offer | Two nav entries |
All three are fixed and deployed. Every claim below is checkable — view the page source, or check out the commit before the fix and reproduce it.
Scope
- Search Console coverage and indexing signals
- Rendered HTML of all 36 pages — canonicals, structured data, metadata
- Manual click-through of every conversion path, desktop and mobile widths
- Internal link graph and orphan analysis
- Build configuration and hosting rewrite rules
- Client-side navigation and script lifecycle behaviour
Out of scope
- Load and performance testing — this is a static site with no backend to stress
- Penetration testing or formal security assessment
- Accessibility audit beyond basic semantics
- Third-party vendor review
The booking widget was dead after any internal navigation
Symptom
Land on the homepage, click any internal link, arrive at the booking page — and the calendar never loads. The placeholder sits there reading "Calendar loads when you scroll here…" indefinitely. Land on that same page directly from a search result and it works perfectly. Which is exactly how I always tested it.
How it was found
Not by monitoring — nothing was down, nothing threw, no error reached any log. It surfaced during a manual click-through of every conversion path, which I only ran because I was auditing internal links for something else.
Root cause
- 01The site uses Astro's <ViewTransitions /> for client-side navigation. On a page swap, Astro replaces <body> and re-evaluates scripts.
- 02To avoid running the same script twice, it keys already-executed inline scripts on their textContent and marks them data-astro-exec. A byte-identical inline script never runs again for the rest of the session.
- 03Every inline script in this codebase is byte-identical across pages, because they are all rendered from the same shared components.
- 04So after the first page load, the Cal.com initialiser never ran again. The IntersectionObserver that lazy-loads the embed was never attached, so the placeholder never resolved.
- 05The same mechanism killed two more things: the mobile menu toggle (which binds a listener to a node that the swap detaches) and the GA4 page_view call — meaning the analytics that should have surfaced the drop were themselves broken.
packages/ui/src/components/CalEmbed.astro
<script is:inline><script is:inline data-astro-rerun>Business impact
A visitor who arrived on any page and then navigated internally could not book. That is most engaged visitors — the ones who read something first. Compounding it: on mobile the only persistent CTA lives inside the hamburger, which was also dead, so a mobile reader had no route to conversion at all. And because page_view stopped firing, every session looked like a one-page session in GA4, so the funnel data would not have revealed the problem either. I do not know how long it was broken. That is part of the problem.
Fix
Add data-astro-rerun to the three inline scripts, which tells Astro to re-execute them after every swap.
Verification
Reproduced the failure on the pre-fix commit, applied the attribute, confirmed the embed initialises after internal navigation on desktop and mobile widths, and confirmed page_view fires on client-side route changes.
What should have caught this sooner
A weekly synthetic check that navigates from the homepage to the booking page and asserts the embed iframe exists. Roughly fifteen lines of Playwright. The general lesson is sharper than the specific bug: I tested every page by loading it directly, which is the one path real users almost never take.
Every page told Google its canonical URL was an address that redirects
Symptom
Google Search Console reported 32 pages under "Page with redirect" — crawled, understood, and declined. An exact-phrase search for the domain returned exactly one page: the privacy policy.
How it was found
Search Console flagged the count. Confirming the cause took one curl: fetch a live page and read its canonical tag.
Root cause
- 01The site builds with Astro's build.format: 'file', which emits /fractional-cto.html rather than /fractional-cto/index.html.
- 02Firebase Hosting serves it with cleanUrls: true, so the public URL is /fractional-cto and the .html form 301-redirects to it.
- 03The SEO component derived the canonical URL from Astro.url.pathname — which at build time is the on-disk path, complete with the .html extension.
- 04So every page published a canonical pointing at a URL that redirects. Google follows it, finds a 301, and treats the whole thing as a conflicting signal.
- 05The homepage was unaffected, because its pathname is / with no extension. That is why it looked fine in every spot check.
packages/ui/src/components/SEOHead.astro
const canonicalURL = new URL(Astro.url.pathname, siteUrl).href;
// -> https://in2labs.dev/fractional-cto.html (301s to /fractional-cto)const normalizePath = (p) =>
p.replace(/\/index\.html$/, '/').replace(/\.html$/, '') || '/';
const canonicalURL = new URL(normalizePath(Astro.url.pathname), siteUrl).href;
// -> https://in2labs.dev/fractional-ctoBusiness impact
For a four-month-old domain trying to get discovered, this is close to invisibility. Not a ranking penalty — an indexing refusal. The site could have published perfect content indefinitely and stayed unfindable.
Fix
Normalise the extension out of the pathname before constructing any URL from it — canonical, og:url, and hreflang were all derived from the same value.
Verification
Checked the rendered canonical on every one of 36 built pages: zero contain .html. Re-submitted the sitemap and used Search Console's "Validate Fix" rather than waiting on an organic recrawl.
What should have caught this sooner
A build-time assertion that no canonical contains a file extension, and that every canonical exactly matches the URL in the sitemap. This is a five-line test that would have caught it on day one.
The best-converting offer had no links pointing at it
Symptom
The free technical review — the lowest-commitment, best-positioned offer on the site — had three inbound links, all small text below the fold. The contact page and the page holding every founder credential had zero. They existed in the sitemap, so Google could find them. No human could.
How it was found
Grepping the built output for href="/contact" returned nothing outside the sitemap. Then the same for the other pages.
Root cause
- 01The navigation was assembled early and never revisited as pages were added.
- 02Each new page was linked from wherever it was created and nowhere else — a link graph that grew by accident rather than design.
- 03Nothing in the build fails when a page becomes unreachable, so there was no signal.
Business impact
Every visitor was being pushed toward "book a 30-minute call" — a high-commitment ask — while the free, lower-friction version of the same conversation was effectively hidden. The credentials page that answers "is this person real," the exact question a referred visitor arrives with, could not be reached from anywhere.
Fix
Surfaced the free review in the header and footer, added contact to both, and pruned an outbound link that was sending qualified traffic off the revenue site from the primary nav.
Verification
Recomputed the internal link graph across all 36 pages. Zero orphans, and every page now has at least one contact route.
What should have caught this sooner
An orphan check in the build: every page in the sitemap must have at least one inbound internal link. Fails the build if not. Cheap to write, and it catches a whole class of slow decay.
The pattern
None of these threw an error
The site was finished. It deployed green. Every page loaded correctly when I opened it. And its only conversion path was dead, its pages were being refused by Google, and the analytics that should have shown me both were themselves broken.
That is the shape of the defects worth paying someone to find. Not the crash — the crash gets fixed on its own, because someone shouts. It's the failure that looks exactly like success from every angle you habitually check.
Which is also the honest argument for an outside read. I built this site, I know every line of it, and I still missed all three — because I tested it the way I built it, one page at a time, loaded directly. A second pair of eyes isn't smarter. It just hasn't formed your habits yet.
Want this run on your product?
That's the Technology Health Check: $2,500, two weeks, a report in this format covering your architecture, security, cloud spend, delivery process, and team. Credited against a retainer if you go on to one. If you're not sure yet, the 30-minute call is free and I'll tell you whether it's worth doing.