SEO Toolbox Site

The easiest trap in an SEO tool site: wanting "enter a domain, see how many pages are indexed". That needs a server to query the search engine, and a pure front-end can't do it — CORS plus anti-bot.

What the browser can compute on its own (build these first):

• TDK generator: enter a title and keywords, get back title / description / keywords plus length advice
• Sitemap generator: paste a URL list, get valid sitemap.xml
• Robots checker: paste a robots.txt, check whether you accidentally blocked /assets/ and whether Sitemap is declared
• Keyword density counter: paste body text, get term frequency and repetition
• Dead-link check: paste URLs and probe them in bulk (also CORS-limited — exporting curl commands is the sturdier shape)

What needs a server, or a redirect to a platform: index status, indexed page count, backlink count. Turn these into "generate a query link": build the site:domain search URL and let the visitor click through to Google or Bing. You never promise numbers you can't fetch, and the visitor stays on your page.

Every tool is the same skeleton: input area → handler → output area + copy button. Write one shell and each new tool is only a function.

// tools.js, sketched
const tools = {
  tdk: { name: 'TDK generator', run: (input) => { /* pure computation */ return text; } },
  sitemap: { name: 'Sitemap generator', run: (input) => { /* build XML */ return xml; } }
};

The details that decide whether people come back:

• One-click copy on the output, with a toast on success
• Persist input history in localStorage so it's still there next visit
• Give a "next step" line under the result, e.g. "put this sitemap in your site root"
• Say it explicitly: the input never leaves your browser. A pure front-end site can actually promise this, so put it on the page as a selling point

Don't fight data you can't fetch cross-origin. Fall back to an exported command or a query link rather than showing the visitor a fabricated result.

Conversion on a tool site happens the moment someone gets a result and is about to act on it.

Three ways to guide them:

1. Offer what's missing: someone generated a sitemap → "need a server to put files on?" → cloud provider link
2. What to do next: someone generated TDK → "want to check robots.txt while you're here?" → another tool on your own site (lifts page views and dwell time)
3. Substitute what you can't do: someone wants index status → "here's the query link, see live results" plus a downloadable indexing checklist

Keep the placement restrained: one line under the result, one in the footer, no modals. Someone on a tool site came to get work done — interrupt them and they close the tab.

Compliance: label promo slots "sponsored · affiliate" and give outbound links rel="sponsored noopener".

Without conversion tracking you will never know which tool anyone uses. Four events, all mandatory:

| Event | Trigger | Key props |
|---|---|---|
| tool_use | Someone opens a tool and computes | tool_id / scenario |
| tool_result | A result is produced | tool_id / ok |
| tool_copy | The result is copied | tool_id |
| aff_click | Promo guidance is clicked | ad_id / pos / tool_id |

This site uses one shared tracking SDK (Tracker.track in assets/js/pv.js); adding a data-track attribute reports automatically. Conversion definitions live in data/conversion.json.

Three numbers are enough: which tool is used most (decides where to add features), the copy rate (whether the result is useful), and the share of copies that click the promo (whether conversion actually happens).

Set a baseline before optimising: for the first two weeks only record, don't conclude. Wait for 30+ tool_use events before deciding which tool to cut.

Tool pages carry a lot of content and change often, which is exactly how you end up "indexed, but never re-crawled".

Four things at launch:

1. Every tool gets a directly reachable URL (/tools.html?tool=tdk or its own file), with canonical pointing at the main tools page
2. sitemap.xml includes the tools page, and lastmod moves when the content does
3. robots.txt allows /assets/ — block the JS and the tools won't run
4. Run bash scripts/seo-check.sh to self-check

Indexing observation (copy this site's approach):

• Keep data/index-observation.json: per URL record submitted_at / indexed / checked_at
• After every change run the observation script — it checks HTTP status, canonical and robots permission per URL, then writes that day's report
• Verify the Google side in Search Console's indexed report

Iteration: sort by tool_use, deepen the top 3, fix or delete the bottom 3. Don't spread effort evenly.