Why I rewrote my 19-product site in two weeks (and what I would do differently)

A site can look finished and still be structurally unable to sell, and the three failures that cause it are invisible on the page: a checkout redirect that hides the funnel, copy that reads like every other landing page in the category, and no surface for AI search to quote. None of them show up in a screenshot, which is why they survive so long.

The old version of this site shipped a year before the rewrite. Nineteen products, OG images, JSON-LD on the product pages, a Gumroad checkout. It looked fine. That was the problem: everything legible was correct, so the things that were wrong had nowhere to show up.

The new one shipped after three weeks of work. Same nineteen products, new stack, new tone, new checkout architecture, new content layer. Whether it sells better is a question the traffic answers, not the rebuild.

Here is what I changed and why.

What the old site got wrong (and what most "polished" sites get wrong)

The old site failed for three structural reasons: every buy button redirected buyers to another domain, the product copy was generic AI-template text, and there was no AI search visibility surface at all. None of these were visible on the page, and that is the point. A site review would have passed it.

1. The Gumroad redirect cost me trust I never recovered

Every buy button on the old site sent the buyer to modernwebseo.gumroad.com/l/<product>. A different domain. A different visual identity. A different cart layout. A different checkout chrome.

For a small share of buyers this is fine, because they know the platform and already have an account. For everyone else it is a hesitation moment, and on a $19 to $119 product a hesitation moment is where the purchase goes.

I could not see the bounce in any dashboard because Gumroad does not show me the people who arrive on the checkout and leave. They were a black hole. I was optimizing what I could measure (the product page) without seeing what was actually broken (the checkout transition).

2. The product copy was generic AI-template slop

Every product page opened with Transform your workflow with..., Unlock the power of... or Industry-leading solution for.... I had drafted them in ChatGPT eighteen months earlier, edited them lightly, and shipped.

The problem is not that AI drafted them. The problem is that I did not get them back to sounding like a real person had written them. Generic copy means:

• AI search engines have nothing distinctive to quote.
• Google's helpful content classifier has more reason to suspect generation.
• Buyers cannot tell the products apart by reading the copy.

I ran every product description through humanizer-v2 during the rewrite. Em-dash density dropped from ~14 per 1,000 words to ~3. Banned phrases such as transform, unlock and in today's went from frequent to zero. First-person voice appeared for the first time on the product pages.

3. Zero AI search visibility surface

The old site had product schema. It did not have:

• A Quick Answer block on any page (the GEO-citable structure).
• A real Person entity for the author.
• An llms.txt file.
• An AI-crawler-friendly robots.txt (the default Allow: / worked, but there was no explicit signal that I wanted to be cited).
• Any cornerstone blog content that AI engines could pull from.

I wrote a separate post on the GEO + SEO short list. The summary is that all five of those things are cheap to add and compound over time. None of them existed on the old site.

What the rewrite changed structurally

The ToolGenX rewrite built my own Iyzico checkout on the site to replace the Gumroad redirect, gave each product type its own page layout, added a compliant refund flow with consent logs, and shipped four cornerstone blog posts. Same nineteen products, but structurally a different site rather than a refactor.

Own Iyzico checkout, no redirect

I built the Iyzico Checkout Form into the site. It accepts the global card networks and adds Turkish lira, taksit and e-fatura for buyers in Türkiye. I had planned Stripe next to it, but Stripe does not onboard merchants based in Turkey, so Iyzico was the only gateway. The callback writes to Supabase, issues a license, increments the download counter, and sends a Resend confirmation email.

Update, September 2026: that on-site checkout is switched off for now. Product pages link to my Gumroad shop again, and the books sell on Amazon Kindle, where the platform handles payment. The Iyzico code is still in the repo for when sales justify turning it back on.

I wrote a longer comparison of the three checkout options for anyone making this decision themselves.

Per-type product page layouts (content-driven uniqueness)

Toolkit-style products and template-style products now get subtly different page layouts. Same React component, different section emphasis driven by a layout field on the product. Toolkit pages lead with workflow, template pages lead with file inventory. The visitor gets a page that matches what they are about to buy.

There are no two products with the same layout fingerprint. Even within "toolkit" or "template", the content forces uniqueness because the products are actually different.

Honesty as a design pattern

Every product page has a "What you do NOT get" block. The homepage has a "This is probably wrong for half of you" section. The About page has a timeline that includes failed projects, not just successful ones.

This is not a marketing gimmick. It is a filter. The right buyer wants a real read on whether the product fits their situation. The wrong buyer needs to be told quickly that it does not, so they leave before they buy and then ask for a refund. Honesty up front costs me some sales and prevents many more refunds.

Global refund flow with consent logs

The refund flow now satisfies the strictest applicable law, EU Consumer Rights Directive 2011/83/EU Article 16(m), which means it satisfies every other jurisdiction by default. Dual checkbox consent at checkout. Consent text plus IP, user agent and timestamp, logged for six years. The withdrawal button in the buyer's account has been required since 19 June 2026 under Directive (EU) 2023/2673.

This is not optional and the old site did not have it. The new site does.

Content gravity

Four cornerstone blog posts shipped with the rewrite. One hub (this one), three spokes. Every post has a quickAnswer field, 3-5 FAQ items, Article + Speakable + FAQPage schema, and links to the products it naturally references. The blog index is at /blog.

This is the part that takes longest to bear fruit. Indexation is fast, since search and AI engines re-crawl within days. Citation share takes months, and the structural work behind it is described in the GEO paper that reports up to 40% higher visibility for content shaped this way.

Why "it looks fine" is the dangerous review

The thing I keep coming back to is that the old site passed every check I knew how to run. Lighthouse was green. Schema validated. The copy had no typos. Friends said it looked professional, and they were being honest.

That is exactly the failure mode. Every one of those checks measures something legible, and all three of the real problems were illegible: a redirect that hid the funnel, copy that was fine sentence by sentence and interchangeable as a whole, and an absence of the thing AI search quotes. Absences do not fail audits. Nothing shows up red for a page that is merely unremarkable.

For scale: published ecommerce conversion averaged 2.23% in August 2026, and that is with returning buyers propping the average up. A new shop sits well under it, which means the signal you are trying to read is small and easily swamped. A site that looks fine and converts poorly gives you almost nothing to work with, because looking fine is not a variable you can move.

So the review question that would have saved me a year is not "is anything wrong with this page". It is "what would I be able to see if this were failing", and the honest answer for the old site was nothing at all.

What I would do differently

If I rebuilt ToolGenX again, I would change four things, in order of regret: write the cornerstone blog posts before the site, ship real product images from day one, build the refund flow before the checkout flow, and either commit to Turkish plus English or strip the locale scaffold entirely.

1. Write the cornerstone blog posts first

I built the site, then wrote the posts. Should have been the opposite. The posts force you to articulate who the buyer is and what they are trying to accomplish, which then makes the product copy easier to write because you already have a voice and a framing.

Doing it the other way meant I had to rewrite product copy after the blog posts revealed the voice. Cost me roughly a week of extra editing.

2. Use real images from day one

The new site ships with text-only product cards and a wordmark logo (no image yet). Phase 5 will add real product hero images and a favicon. This is fine for launch but it means I am missing OG image optimization and product card scannability.

Should have either commissioned a designer for a couple of days or generated + curated AI images with a tested prompt library before launch.

3. Build the refund flow before the checkout flow

I built the Iyzico checkout, then realised I needed the consent logging table, then realised I needed the withdrawal button, then refactored both. If I had built the legal evidence schema first, meaning the consent log, the withdrawal requests table and the dual-checkbox UI, the checkout integration would have plugged into it cleanly.

This is a "boring before exciting" pattern that I keep relearning.

4. Cut the locale skeleton further

next-intl is installed and ready for additional locales. I shipped only English, with the routing scaffolded for future TR/AR/ES. In retrospect I should have either committed to TR + EN day one (Turkish-market reality) or stripped i18n entirely until I needed it. The current "scaffolded but unused" state is a maintenance tax for a hypothetical future.

I will likely add TR within the next month, which retroactively justifies the scaffold. But if you are in my position, you should make the call explicitly instead of leaving it ambiguous.

The 90-day plan

The 90-day plan after the rewrite is pure distribution. Shipping the rebuild was the easy part, and the next 90 days decide whether the catalog actually sells. The plan runs in three four-week blocks, publishing first, measurement second, and an honest verdict on the conversion data last:

• Weeks 1-4: Ship 1-2 blog posts per week. Same channel (long-form writing on the site, syndicated to Medium and dev.to).
• Weeks 5-8: First measurable AI citation tracking. Set up monthly checks in ChatGPT, Perplexity, Gemini for our product names.
• Weeks 9-12: Read the conversion data. If sales are up, double down on what is working. If sales are flat, the answer is not the site, it is the offer.

The rewrite was a prerequisite, not a deliverable. The actual work is dragging the trust signals and content gravity into place over a long time. That is what the next 90 days are for.

Written from the inside of a small shop. The four lessons above are the ones I would tell a friend rebuilding their own site. If you want to dig into the specific technical choices, the solo founder guide and the GEO + SEO short list cover them in depth.