Forem: tzhkai

I Spent 3 Months Getting Zero Organic Traffic — Then One Fix Brought 40 Users in 24 Hours

tzhkai — Wed, 06 May 2026 08:01:04 +0000

I Spent 3 Months Getting Zero Organic Traffic — Then One Fix Brought 40 Users in 24 Hours

I built a site with over 100 free browser tools — calculators, formatters, games, AI writing tools. I launched in January 2026. For three months, Google sent me exactly zero visitors. Not low traffic — zero.

Then, over the weekend, three fixes brought 40 real users in 24 hours. Here's exactly what was broken, what I fixed, and what I'll never skip again.

The Site (Before You Ask)

knexio.xyz — 100+ browser tools, no sign-up, free. I built it for AdSense monetization, which means Google's content quality standards are the gatekeeper. You don't pass the review unless Google actually trusts your pages.

Here's what the site had before I fixed anything:

✅ 300+ pages with unique content
✅ Sitemaps submitted to Search Console
✅ robots.txt correctly pointing to sitemap index
✅ Structured data (JSON-LD) on every page
✅ Schema.org FAQ markup
✅ Open Graph / Twitter card meta tags
✅ Fast load times (static site, no frameworks)
✅ About, Privacy, Terms pages
✅ Cookie consent banner (GDPR compliant)
✅ Canonical URLs on all pages

From a checklist perspective, I'd done everything right. Google did not agree.

The Audit: What Google Actually Saw

When I sat down to audit the site — not with a tool, but by reading every file like a reviewer would — three things stood out.

1. The Canonical Dead Loop

This was the silent killer.

My blog sitemap (sitemap-blogs.xml) linked to clean URLs:

/blogs/seo-checklist-for-new-websites/

But every blog page's <link rel="canonical"> pointed to:

<link rel="canonical" href="https://knexio.xyz/blogs/seo-checklist.html" />

And that .html URL? It returned a 308 permanent redirect back to the clean URL.

Googlebot would land on /blogs/seo-checklist/ → see canonical pointing to .html → follow redirect back to the clean URL → see canonical pointing to .html → give up.

The bot couldn't determine the canonical URL, so it refused to index any of my blog posts. 25 pages, invisible.

Fix: Strip .html from all canonical URLs. Match sitemap. One sed command, 24 files.

2. 43 Pages That Were "Thin Content"

I thought I had substantial content. Google's crawler counted H2 tags and came to a different conclusion.

My games directory had 33 pages with zero H2 headings. Not one. No "How to Play" section, no strategy tips, no rules explanation. Just a title, the game iframe, and an ad.

Another 10 tools had 1-2 H2s at most — not enough for Google to consider them "substantive." A single "What is this tool?" section doesn't cut it.

This is the exact pattern that triggers Google's "thin content" penalty — pages created primarily for displaying ads. AdSense reviewers actively flag this.

Fix: Added dedicated "How to Play," "Tips & Strategy," and "Why Use This" sections for every game page. Expanded thin tool pages to 3+ substantive H2 blocks. Total: 43 pages rewritten with unique, non-template content.

3. The EEAT Gap

Google's Search Quality Rater Guidelines emphasize E-E-A-T: Experience, Expertise, Authoritativeness, Trustworthiness.

My site had:

❌ No author name or bio on any page
❌ No "About" page that mentioned a real person with credentials
❌ No external trust signals (GitHub links, LinkedIn, etc.)
✅ Privacy policy (good)
✅ Terms of service (good)

The site looked anonymous. Anonymous = untrustworthy in Google's eyes, especially for a site applying for AdSense monetization.

Fix: Added a team narrative to the About page (real people, not a faceless brand), footer links to GitHub profile, and surface-level trust cues across the site.

24 Hours Later: Real Traffic

After pushing the fixes and requesting re-indexing in Search Console:

Metric	Before	After (24h)
Organic search clicks	0	27
Active users	0	41
Top country	—	United States (32 users)
Engagement events	0	526 (page scrolls, clicks)
Avg session duration	—	3 minutes

Not life-changing numbers. But after three months of nothing, seeing real humans from Google actually use your tools — that's a different feeling.

The top pages getting traffic:

AI Note-Taking Apps guide
Reading Time calculator
Blog directory
Word Counter
AI Coding Assistants guide

Not the tools themselves — the content pages. Google is sending people to the information, not the widgets.

What I Wish I'd Known on Day One

1. Sitemap ≠ Indexing

Submitting a sitemap doesn't mean Google will index your pages. It means Google might look at them. The canonical fix above meant Google actually could process what it found.

2. Content Count ≠ Content Quality

I had 300+ pages and thought I was done. Half of them were invisible to Google because they lacked the structural depth Google expects. It's not about word count — it's about having clearly labeled, distinct sections (H2s, not just paragraphs).

3. The Boring Pages Matter Most

I obsessed over tool features. Google cared about:

Is the canonical URL consistent?
Does the About page show a real person?
Does the Privacy page actually explain cookie usage?
Are there contact options?

The tools were secondary to the trust infrastructure.

4. AdSense Approval Is a Content Review in Disguise

If you're building for AdSense, think like a quality rater. Every page needs to pass the "would I be satisfied if I landed here from search?" test. If a page is just a tool with a sentence of description and an ad, it fails. Google's reviewers see thousands of these, and they're trained to spot them instantly.

5. Analytics Lie Without Engagement Data

Raw visitor counts mean nothing. I had "traffic" from AI crawlers (GPTBot, ClaudeBot) showing up as Direct visits. Only when I saw scroll events and user engagement metrics did I know the traffic was real.

What's Next

AdSense review — literally just submitted. The fixes above were the pre-flight checklist
Tool content pages — building out the informational content around each tool (not just the tool itself) is where the organic traffic lives
Backlink building — GitHub Awesome lists, Product Hunt (launching May 6), community posts

Try it: knexio.xyz — 100+ free browser tools

GitHub: tzhkai/knexio

Built by KK Tian. I write about SEO, web tools, and the slow process of getting Google to notice your work.

How I Built a Privacy-First Markdown Editor with Astro + Cloudflare Pages

tzhkai — Tue, 05 May 2026 09:07:01 +0000

How I Built a Privacy-First Markdown Editor with Astro + Cloudflare Pages

I wanted a Markdown editor that loads instantly, previews in real time, and never asks for my email. So I built MarkdownMaster.

Here's the full story: the tech stack, the architecture decisions, and what I learned along the way.

The Problem with Existing Markdown Editors

Most online Markdown editors fall into one of three camps:

Heavy WYSIWYG apps — HackMD, Notion, etc. Cool features, but slow to load and require accounts
Ad-cluttered free tools — Works, but the UX is awful
Developer-only CLI tools — Great for terminal users, useless for sharing with non-technical teammates

I wanted something different: a clean, fast, privacy-first editor that works the moment you open the URL. No loading spinners. No cookie walls. No "sign up to save" nag screens.

The Stack: Why Astro + Cloudflare

After evaluating several options (Next.js, SvelteKit, plain HTML), I landed on:

Concern	Solution
Speed	Astro static generation → zero JavaScript runtime
Global latency	Cloudflare Pages edge network → <50ms TTFB worldwide
Markdown parsing	marked.js → battle-tested GFM parser
Syntax highlighting	Prism.js → 100+ languages, lightweight
Dynamic content	Cloudflare D1 → edge SQLite for blog content
Analytics	GA4 with cookie consent banner

Why Not Next.js?

Next.js is great, but for a content-heavy tool that doesn't need client-side state management, it's overkill. Every Next.js page ships 70-100KB of JavaScript even for static content. Astro ships zero.

Why Cloudflare Pages Over Vercel/Netlify?

Free tier includes 500 builds/month (vs Vercel's 100 on hobby)
D1 database at the edge (no cold starts like serverless)
Workers for lightweight backend logic (affiliate links, A/B tests)
Built-in analytics without third-party scripts

Architecture

┌─────────────────────────────────────────────────┐
│                    Cloudflare                     │
│  ┌──────────┐  ┌──────────┐  ┌───────────────┐  │
│  │  Pages   │  │  Worker  │  │      D1       │  │
│  │ (static) │──│(affiliate│──│(blog content, │  │
│  │  Astro   │  │ injection)│  │ link templates)│  │
│  └──────────┘  └──────────┘  └───────────────┘  │
└─────────────────────────────────────────────────┘
         │
         ▼
    User's Browser
    ┌─────────────────────────────┐
    │  marked.js (GFM parser)     │
    │  Prism.js (highlighting)    │
    │  GA4 (analytics)            │
    │  All client-side. Zero API  │
    └─────────────────────────────┘

Key architectural decisions:

1. Everything Runs Client-Side

The editor is pure HTML + CSS + JS. When you type on the left, marked.js converts it to HTML on the right — all in your browser. No server round-trips, no API calls, no latency.

This also means your content never leaves your device. I don't have a server to store it on even if I wanted to.

2. Astro for Static Generation

The blog, docs, and landing pages are all pre-built HTML. No SSR, no hydration, no client-side routing. Just pure HTML served from Cloudflare's edge.

---
// src/pages/index.astro
import BaseLayout from '../layouts/BaseLayout.astro';
---

<BaseLayout
  title="Free Online Markdown Editor — MarkdownMaster"
  description="Free online Markdown editor with real-time live preview..."
>
  <section class="hero">
    <h1>Write Markdown. See It Instantly.</h1>
    <a href="/editor/">Start Writing Now →</a>
  </section>
  <!-- Features, etc -->
</BaseLayout>

3. Cloudflare Worker for Lightweight Backend

The only server-side code is a Worker that proxies requests from markdownmaster.site to the Pages deployment. It injects an affiliate button on HTML pages and passes everything else through untouched.

// Simplified Worker logic
export default {
  async fetch(request, env) {
    const response = await fetch(origin + url.pathname);

    // Only inject into HTML responses
    if (response.headers.get('content-type')?.includes('text/html')) {
      let html = await response.text();
      const links = await env.DB.prepare(
        "SELECT links_json FROM link_templates WHERE site_id = ?"
      ).bind("tool-markdown").first();

      html = html.replace('</body>', affiliateButton(links) + '</body>');
      return new Response(html, response);
    }

    return response; // Static assets pass through untouched
  }
}

4. Cookie Consent That Actually Respects Privacy

GDPR compliance isn't optional if you use GA4. But I hate those full-screen cookie walls that darken the page and force you to click through 12 toggles.

My solution: a slim bottom banner with one button.

// No framework, no npm dependency. Just vanilla JS.
(function(){
  if (document.cookie.indexOf('mm_cookie_consent=1') !== -1) return;
  document.getElementById('cookie-banner').style.display = 'flex';
  document.getElementById('cookie-accept').onclick = function(){
    document.cookie = 'mm_cookie_consent=1;max-age=31536000;path=/;SameSite=Lax';
    document.getElementById('cookie-banner').style.display = 'none';
  };
})();

The Blog: 17 Articles and Counting

I wrote 17 in-depth Markdown tutorials — from beginner cheat sheets to advanced topics like Mermaid diagrams and LaTeX math formulas. Each article is 2,500-3,500 words with real code examples.

Article	Topic
Markdown Cheat Sheet	Complete syntax reference
How to Write Markdown	Step-by-step beginner guide
Markdown for Developers	README, docs, wikis
Advanced Markdown	Footnotes, Mermaid, Math
Build a Blog with Markdown + Astro	Full tutorial

The blog serves two purposes:

SEO — long-tail keywords like "how to create markdown tables" bring organic traffic
Trust — Google's EEAT guidelines favor sites that demonstrate expertise with substantial content

SEO: What I Learned

Launching a new domain is humbling. You ship, you submit your sitemap, and... crickets. For weeks.

Here's what actually moved the needle:

1. Fix Canonical URLs Immediately

My blog pages had a canonical dead loop: the sitemap linked to /blog/post-name/ but the page's canonical tag pointed to /blog/post-name.html, which 301-redirected back to the clean URL. Google saw this and refused to index anything.

Fix: Align canonical with sitemap URLs. This single fix took my site from 0 to 7 organic search clicks in 24 hours.

2. EEAT Signals Matter

Google looks for "Experience, Expertise, Authoritativeness, Trustworthiness" signals. I added:

About page with my name, GitHub profile, and technical background
Footer links to the open-source repository
Privacy policy that honestly describes GA4 cookie usage
Cookie consent (GDPR compliance matters in 2026)

3. `.site` TLDs Have a Trust Problem

I learned this the hard way: Google's algorithms are skeptical of .site domains because they're commonly used by phishing sites. If I were starting over, I'd choose .com or .io. If you're stuck with .site like me, the EEAT signals above become even more critical.

What's Next

Open-source the editor component as a standalone package
Export formats: PDF, DOCX, HTML zip
Keyboard shortcuts: Full VSCode-style command palette
Collaboration: Real-time multiplayer editing via WebRTC (no server, still privacy-first)

Try It

markdownmaster.site — No sign-up, no tracking, no ads. Just open and write.

GitHub — Star the repo if you find it useful!

Built by KK Tian. I build fast, privacy-first web tools. Follow me on GitHub for more.

Forem: tzhkai

I Spent 3 Months Getting Zero Organic Traffic — Then One Fix Brought 40 Users in 24 Hours

I Spent 3 Months Getting Zero Organic Traffic — Then One Fix Brought 40 Users in 24 Hours

The Site (Before You Ask)

The Audit: What Google Actually Saw

1. The Canonical Dead Loop

2. 43 Pages That Were "Thin Content"

3. The EEAT Gap

24 Hours Later: Real Traffic

What I Wish I'd Known on Day One

1. Sitemap ≠ Indexing

2. Content Count ≠ Content Quality

3. The Boring Pages Matter Most

4. AdSense Approval Is a Content Review in Disguise

5. Analytics Lie Without Engagement Data

What's Next

How I Built a Privacy-First Markdown Editor with Astro + Cloudflare Pages

How I Built a Privacy-First Markdown Editor with Astro + Cloudflare Pages

The Problem with Existing Markdown Editors

The Stack: Why Astro + Cloudflare

Why Not Next.js?

Why Cloudflare Pages Over Vercel/Netlify?

Architecture

1. Everything Runs Client-Side

2. Astro for Static Generation

3. Cloudflare Worker for Lightweight Backend

4. Cookie Consent That Actually Respects Privacy

The Blog: 17 Articles and Counting

SEO: What I Learned

1. Fix Canonical URLs Immediately

2. EEAT Signals Matter

3. .site TLDs Have a Trust Problem

What's Next

Try It

3. `.site` TLDs Have a Trust Problem