What I learned while building the systems.
Architecture, implementation choices, measurements, and limits from real releases.
Recent engineering notes
Start with the newest published notes. Earlier engineering decisions and their original dates remain available below.
Implementation screenshots as release evidence
A screenshot is useful when it identifies a real implemented surface and keeps its limits attached. The implementation uses neutral publishing fixtures plus captures from two read-only demos, serves them through responsive picture sources, and gives each chosen page one stable image for metadata and sitemap discovery.
3 renderer outputs · 2 read-only demo captures · WebP plus PNG fallback · explicit dimensions
Read the note
Give every acquisition page one operating job
More indexable copy does not create acquisition by itself. The homepage, industry solution, reusable system, working case, demo, and engineering note need different jobs, explicit proof boundaries, and one measurable path to contact.
1 primary Operations path · all 7 systems remain crawlable · every published note remains linked · content-owned sitemap dates
Read the note
Tracing an approved page through a static release
A static page is not proven by the final HTML alone. Its source, approval decision, canonical route, release version, and later crawl observations need to remain connected. The current system implements that path, but it does not yet retain a sanitized end-to-end timing series from one release.
8 renderer architectures · exact 50,000-page capacity test · no invented stage timings
Read the noteHow to verify a search crawler beyond its user-agent string
Do not identify a search crawler from its user agent alone. Start with the request the server observed, obtain the source IP through a trusted origin or locked proxy, then apply the provider’s documented IP-range or reverse-and-forward DNS check. Until that passes, label the crawler user-agent-claimed—not provider-confirmed.
HTTP requests, not visitors · family classification before provider confirmation · trusted origin IP required
Read the noteHow to preserve first-touch attribution without cookies or third-party SaaS
Record the first observed landing and source once inside a property-scoped visitor-day, then keep later pageviews and goals separate so they cannot overwrite it. Permanent rollups preserve the chosen dimensions after raw cleanup, but this does not identify one person across devices or prove that the source caused a conversion.
Write-once landing source per visitor-day · later goals stay separate · permanent source rollups
Read the noteEarlier decisions and evidence
Each note keeps its implementation evidence, limitations, and original publication date together.
Adding acquisition controls after a static release
Publishing was only the first boundary. I added site-level controls for acquisition tactics, budgets, experiments, delivery records, and crawl/index observations so each release can be operated and compared instead of merely launched.
24 versioned techniques · immutable experiment records · IndexNow and XML-RPC automated
Read the noteKeeping source intake private until a directory release is approved
The public directory already ran as an immutable Rust release. The next problem was accepting source changes without putting unreviewed records or a live database back on the public request path.
4 source adapters · durable review and media queues · default-off quota-bound publishing
Read the noteHow to delete raw analytics events without losing historical reports
Create and verify the historical rollups you intend to keep before deleting a raw event. Preview eligible rows, delete them in bounded resumable batches, and checkpoint or vacuum only after cleanup succeeds. Only dimensions designed into the rollups survive.
Approximately 3 KB gzipped tracker · permanent rollups · opt-in 00:05 cleanup with dry run
Read the note