Build
A foundation I can keep changing
The static site gives me direct access to layouts, navigation, metadata, and structured data. Version history makes it possible to review a change and undo it when the previous version works better.
Case study / Double Atari / Ongoing experiment
The website is the experiment.
An AI-assisted rebuild became a live test of how design, content, SEO, AI search, and measurement can work together. The project is Double Atari itself, and it is deliberately not finished.
The starting point
A small creative spark became a different way to run a website.
The idea did not begin with a grand plan for an AI search lab. A friend showed me a Scrabble website he had built with AI, and its simple, fast experience made me curious. Could I use a similar approach to rebuild Double Atari while applying the things I work on professionally: content structure, search, analytics, and website strategy?
That question became a static HTML website, with AI helping move between ideas and implementation. The workflow combined code, GitHub version history, Cloudflare hosting, and a willingness to keep testing the result instead of treating the first release as the finished product.
I documented that beginning in How a Scrabble Website Inspired Me to Rebuild Double Atari. What interested me was not simply whether AI could produce a page. It was whether it could help me build a better process for deciding what the page should do.
The site still has a straightforward business job: explain Double Atari's work and help the right people start a conversation. The experiment adds a second job. It is a place to test methods, show the reasoning, and be honest about what the evidence does not yet establish.
That changes the definition of a successful release. A clearer service explanation, a readable mobile table, or a better way to verify an inquiry can be worth shipping even when it does not produce an exciting ranking screenshot. The website should become more useful with each pass, not simply accumulate more pages.
- Project
- Double Atari's own consulting website
- Status
- Self-initiated and ongoing
- Foundation
- Static HTML, CSS, GitHub, and Cloudflare
- Scope
- Strategy, design, development, content, SEO/GEO/AEO, and measurement
The work
Not just AI-written content. An AI-assisted operating process.
The useful part is connecting research, implementation, and review. AI helps move work forward, while the decisions and responsibility stay with me.
Explain
Content with a specific job
Services, articles, and case studies answer different questions. I have expanded service explanations, organized related articles, and made project stories more useful than a screenshot and a list of technologies.
Connect
A clearer path through the site
Descriptive internal links, consistent author information, FAQs, and structured data connect the pages. The intention is a site that is easier for visitors and search systems to understand, not a collection of isolated posts.
Measure
Questions before dashboards
Google Search Console, GA4, and SEMrush inform the next round of work. I separate search exposure, visits, engagement, and inquiry measurement rather than turning them into one vague “visibility” score.
Refine
Design that responds to use
The site has gone through changes to portfolio layouts, photography, headings, blog filters, navigation, and mobile tables. These are not cosmetic extras when they determine whether someone can actually use the content.
Document
A public record of the thinking
The blog and Search Lab explain the experiments, the workflow, and the limits. Creative projects sit alongside practical search and analytics work because curiosity is part of the process, not a separate department.
The feedback loop
Read the signal. Make a hypothesis. Ship a careful change.
Perplexity is part of how I connect the research tools to the website work. I use it to inspect Search Console patterns, review GA4 behavior, explore SEMrush opportunities, and turn those observations into questions about content and structure. The tool can help compare the evidence; it should not turn a weak signal into a confident story.
A query appearing in Search Console might suggest that an existing service page needs a clearer answer. It does not automatically justify another blog post. A page receiving visits but showing no recorded inquiries might need a better next step, or it might need its tracking checked before I judge the content.
The practical cycle is small: choose the question, save the baseline, define the change, review the implementation, and return to the evidence. I have used that cycle for titles, page copy, linking, FAQ content, schema, and the way the work is presented.
The most useful recent example is a website tracking audit article. Questions about the site's own reporting became an opportunity to explain why an event, an inquiry, and a qualified lead should not be treated as the same thing. That is a better use of a gap than hiding it behind a more flattering chart.
The content strategy decision guide applies the same thinking to publishing. Sometimes the next piece of work is a new resource. Sometimes it is a clearer version of a page that already exists. Sometimes the right decision is to leave a useful page alone long enough to learn from it.
What the experiment has produced
A working system, not a victory lap.
The tangible result is a functioning website and an ongoing way to improve it: service pages, a growing body of original writing, project case studies, a filterable blog, structured information, and a repeatable review process. The site demonstrates the same connection between strategy and implementation that I bring to client work.
That is not the same as claiming the authority problem is solved. Building stronger website authority has remained an open challenge. Publishing faster and cleaning up a site do not, by themselves, establish that other people trust it enough to reference it.
Still being tested: whether the work earns more relevant non-branded attention, credible mentions and links, repeatable AI-search visibility, and qualified conversations.
This case study does not claim a proven ranking lift, an increase in Authority Score, or a verified lead increase caused by AI. Those need their own evidence.
I also want to be careful with the reporting story. A wider search footprint can coexist with disappointing click-through. Zero recorded key events can coexist with incomplete measurement. Small samples can make a promising change look definitive when it is not.
The published progress report keeps those questions visible. It is a dated record of the experiment, not a set of numbers I want to repeat forever as if they still describe the current month.
What comes next
Five goals worth measuring, not just talking about.
The next phase is about evidence. These are goals and review questions, not promised outcomes.
Earn relevant non-branded attention
Track which service-related queries and pages gain impressions and clicks, then ask whether they attract the people Double Atari can actually help.
Become a useful source in AI search
Document a consistent set of questions, the engine and date tested, and whether the site is mentioned or cited. Keep observed citations separate from referral visits.
Build credibility beyond the site
Create resources and case studies worth referencing, collaborate with other practitioners, and record relevant mentions and links rather than chasing a domain count alone.
Connect visits to real conversations
Verify the inquiry path and distinguish contact clicks, accepted inquiries, qualified conversations, and customers. Improve measurement before using it to declare a result.
Make iteration better, not just faster
Record what changed, how much review it needed, and whether the result was easier to use. AI speed only helps if the finished work holds up.
The principle
Keep the questions open
A useful experiment can change direction. If a topic, layout, or workflow does not help, I want the evidence to make that visible rather than defend it because it was easy to generate.
What carries into client work
The transferable part is the method.
I would not recommend that every organization copy this website's technology. A team with publishing approvals, a large product catalog, or complex integrations may need a very different platform. The transferable part is the habit of connecting decisions to evidence and implementation.
Start with a clear business question. Make the website easier to understand. Define what a useful result would look like. Keep the changes reviewable. Then measure what happened without confusing activity with progress.
That is the connection between website audits, content strategy, GEO and AEO consulting, and analytics and reporting. They are more useful together than as separate checklists handed off without context.
The experiment also leaves room for collaboration. I would love to compare notes with people testing similar workflows, question the assumptions, or work together on a resource that helps others make better decisions.