DEV Community: xg704863664

What 49 pages of niche content taught me about writing for search

xg704863664 — Sun, 04 Oct 2026 16:52:41 +0000

I have written 49 pages of niche reference content in the last two weeks. Almost everything I assumed about writing for search was wrong in some small way. These are the corrections that actually changed the pages.

The first sentence is the whole page

The single highest-leverage edit I make to any draft is rewriting the sentence after the H1.

Draft: "Herbal remedies have been used for centuries to treat a wide range of ailments..."

Published: "Most sore throats are viral and settle in 3–7 days. These remedies reduce the pain while that happens."

The second one does three things the first does not: it gives a number, it sets an expectation, and it tells the reader whether this page is for them. That is the sore throat page, and the same rewrite pattern appears on every page I have published since.

The test I use: read only the H1 and the first sentence. If that pair does not answer the query, the page is not finished.

Counterintuitive beats comprehensive

The pages that get read are the ones that contradict a common belief. Not contrarian for its own sake — genuinely correcting something people are doing wrong.

Examples from my own site:

Peppermint makes reflux worse. It relaxes the valve at the top of the stomach. It is the most recommended herbal tea for digestion and the wrong one for heartburn.
Do not heat a chicken coop in winter. Sealing it traps moisture, which causes frostbite at temperatures well above freezing. Ventilation matters more than warmth — the full reasoning is here.
Spraying the ants you can see is the wrong move. They are 1–10% of the colony; killing them makes the colony produce more, and you lose the trail that would lead you to the nest.

Each of those could have been written as neutral advice. The reflux one is on the acid reflux page, which is also the page where I had to admit that the most-recommended herb for a problem is the wrong one. Written as a correction, they are memorable and they are what people link to.

The answer is a number, or it is not an answer

Vague advice is unquotable. "Provide adequate space" is not useful. "2–3 sq ft per bird inside, 8–10 sq ft in the run" is useful, checkable and linkable.

I now go through every draft and hunt for the sentence that should contain a number but does not. There is almost always one.

Caveats belong on the page, not in a disclaimer

The thing that separates a useful page from a sales page is that the useful page tells you when not to use the thing.

Licorice for reflux: use DGL, and not at all if you have high blood pressure.
Elderberry syrup: never for children under one, because of the honey.
Rosemary: almost every dead plant was overwatered, not frozen.

This costs you nothing and it is the main reason people trust a page enough to link to it.

Length follows from the structure, not a target

I stopped aiming for word counts. What I aim for now:

A direct answer in the first sentence
A table for the numbers
The reasoning behind the numbers
The exceptions and caveats
FAQ entries that match what people actually search

That lands between 450 and 700 words for most topics. The pages that run longer do so because the topic has more exceptions, not because longer is better.

Internal links are not decoration

Every page links to two or three related pages, in context, with anchor text that describes the destination. Not "click here" and not a bare list at the bottom.

The raised bed depth page links to the soil calculator because the next question after "how deep" is "how much soil". That is the whole principle: link to the next question.

What I would tell someone starting today

Write the hub page first. I wrote 21 pages before creating the page that ties them together, which meant the crawl path between them did not exist for weeks. Everything else — the numbers, the caveats, the first sentence — is refinement. The structure is the thing that decides whether any of it is found.

Most of my content pages are secretly tables. Here is the data shape that works

xg704863664 — Sun, 04 Oct 2026 16:46:09 +0000

Every content page I write starts as prose and ends up mostly tables. That was not the plan — it is what happened after watching which parts people actually used.

Here is the data shape that kept working, and the three ways tables fail.

Why tables win for reference content

A reader arriving from a search query has one question. If the answer is "2 to 3 square feet per bird", a paragraph makes them read three sentences to extract it. A table gives it to them in one glance.

Compare the two forms for the same information:

Hens need roughly two to three square feet of floor space inside the coop, and eight to ten square feet in the run. Crowding is the single biggest cause of pecking.

versus:

Space	Per bird
Inside the coop	2–3 sq ft
In the run	8–10 sq ft

Same content. The table is scannable, quotable, and — this matters — it survives being read on a phone at 7am by someone standing in a garden centre.

The shape that keeps working: two columns, one axis

The tables that perform best have a single axis of variation. Depth of a raised bed:

Depth	What grows well
15 cm	Lettuce, herbs, radish
30 cm	Carrots, peppers, tomatoes

That is the full depth chart, which also covers what to do if your bed is already built at the wrong depth.

One column is the thing the reader controls; the other is the consequence. Three columns work if the third is genuinely supplementary:

Food	Pantry	Fridge
White rice	2 years	—
Brown rice	3–6 months	6–12 months

The full version of that one has five columns and a search box, because storage times have a genuine third dimension (sealed vs not).

Failure mode 1: tables that are really paragraphs

If a cell contains a sentence with "however" in it, it is not tabular data. It is a paragraph wearing a table costume, and it reads badly.

The test: can you read the table by scanning only the first column? If not, the axis is wrong.

Failure mode 2: tables that break on mobile

A 700px table on a 390px screen forces the whole page to scroll horizontally. The fix is one wrapper:

<div class="table-scroll"><table>…</table></div>

.table-scroll { overflow-x: auto; -webkit-overflow-scrolling: touch; }

Do not shrink the font instead. Scrolling one element is fine; scrolling the page is not.

Failure mode 3: no caption or context

A bare table assumes the reader already knows what the columns mean. One sentence above it removes that assumption:

Storage times assume an airtight container in a cool, dark place. Heat roughly halves every number here.

That sentence is doing more work than any row in the table.

The markup that matters

Use real <thead> and <th>. It costs nothing and it gives screen readers the column association, so a cell is announced as "8–10 sq ft, in the run" rather than just "8–10 sq ft".

<table>
  <thead><tr><th>Space</th><th>Per bird</th></tr></thead>
  <tbody><tr><td>Inside the coop</td><td>2–3 sq ft</td></tr></tbody>
</table>

I did not do this on my first twenty pages and had to go back through all of them.

Where prose still wins

Tables are for lookup. Prose is for reasoning. The most useful pages I have end up as both:

A table for the numbers
A short paragraph for why the numbers are what they are
A section for the exceptions, which are almost never tabular

The companion planting chart is the clearest example. The chart is a table. But the useful part is the paragraph after it explaining that most of the pairings are folklore and only the structural effects (shade, support, trap cropping) are reliable. That paragraph could not be a table.

A quick test before publishing

Read only the H2s, then only the first column of every table, then only the first sentence of every paragraph. If those three passes together do not answer the page's title question, the structure is wrong — regardless of how good the writing is.

A static site SEO checklist I ran on my own site (and what it found)

xg704863664 — Sun, 04 Oct 2026 16:43:01 +0000

I moved a 21-page static site from a subdirectory to a domain root last week, and it broke more things than I expected. Here is the checklist I ended up running, in the order that found actual problems.

1. Does the crawler see the same page a human does?

Fetch your page with a crawler user agent and compare the rendered text to what you see in a browser:

const UA = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)";
const r = await fetch(url, { headers: { "User-Agent": UA } });
const html = await r.text();
const text = html.replace(/<script[\s\S]*?<\/script>/g, "")
                 .replace(/<[^>]*>/g, " ")
                 .replace(/\s+/g, " ").trim();
console.log(r.status, text.length, text.slice(0, 80));

If the crawler text is much shorter than what you see, something is client-rendered and you have a problem.

Also check x-robots-tag. A header-level noindex will silently kill a page even when the HTML has nothing wrong with it.

2. Does every page render without JavaScript?

Disable JS and reload. For a content site, everything that matters — headings, paragraphs, tables — should still be there.

I write calculators as progressive enhancement for this reason. The page contains a real table of numbers; the JS only adds the interactive layer on top. The food storage lookup is a good example: without JS it is a readable 24-row table, with JS it filters as you type.

3. Is the sitemap actually valid, or does it just look valid?

Three things that caught me out:

A BOM at the start of the file. Check the first bytes — they should be 3c 3f 78 (<?x), not ef bb bf.
The wrong content type. It should be application/xml, not text/plain.
The wrong URL. If your property is a subdirectory and you submit sitemap.xml, make sure you know what it resolves to. Fetch the resolved URL yourself rather than assuming.

const buf = Buffer.from(await (await fetch(url)).arrayBuffer());
console.log(buf.slice(0, 3).toString("hex"));  // 3c3f78 = good

4. If you move URLs, do the old ones redirect?

A meta refresh plus a canonical is the only option on a static host with no server config:

<link rel="canonical" href="https://example.com/new-path">
<meta http-equiv="refresh" content="0; url=https://example.com/new-path">
<meta name="robots" content="noindex, follow">
<script>location.replace("https://example.com/new-path");</script>

The noindex, follow combination is the part people miss. You want the old URL dropped from the index but its link equity passed on, and noindex without follow throws that away.

5. Is there a hub page linking to everything?

This was my biggest structural mistake. I had 21 pages, all reachable from a nav bar, but no single page that linked to all of them with context. Google had indexed exactly one page — the homepage — and had not followed through to the rest.

A hub with a one-line description per link fixed the structure:

<li>
  <a href="/companion-planting-chart.html"><strong>Companion Planting Chart</strong></a><br>
  <span class="d">A practical table of what to plant together, and the pairings that are folklore.</span>
</li>

You can see the result on the hub page — 46 guides, each with a description rather than a bare link.

6. Is anything actually answering the query in the first sentence?

This is content advice, but it is measurable. Open your page and read only the first sentence after the H1.

If it says "Herbal remedies have been used for centuries..." you have written an introduction, not an answer. Compare:

Most sore throats are viral and settle in 3–7 days. These remedies reduce the pain while that happens.

That is the sore throat page. The answer is in the first line; everything after it is detail.

7. Are the tables usable on a phone?

Reference tables are the most common thing to break on mobile. A table that is 700px wide on a 390px screen forces horizontal scrolling for the whole page unless you wrap it:

<div class="table-scroll"><table>...</table></div>

.table-scroll { overflow-x: auto; -webkit-overflow-scrolling: touch; }

Cheap, and it stops the layout breaking on the device where most of your traffic will arrive.

What I would do in a different order

If I did it again: build the hub page first, then write content. I wrote 21 pages and only later created the page that ties them together, which meant the crawl path did not exist for weeks.

The other thing I would not skip is the crawler-UA check. It takes two minutes and it is the only way to know for certain that what you published is what a crawler receives.

Three interactive calculators, zero dependencies: a static-site pattern

xg704863664 — Sun, 04 Oct 2026 16:37:11 +0000

Static sites have one obvious limitation: no server. So when I wanted to add calculators to a content site, the answer was not a backend — it was about 40 lines of vanilla JS per tool.

Here are three patterns I ended up reusing, with the real tools linked so you can see them working.

Pattern 1: unit conversion with a formula

The first tool is a raised bed soil calculator. The whole thing is one formula — volume = length × width × depth — plus unit conversion and rounding.

var U = { cm: 0.01, m: 1, ft: 0.3048, in: 0.0254 };

function run() {
  var f = U[document.getElementById("unit").value];
  var L = parseFloat(document.getElementById("len").value) * f;
  var W = parseFloat(document.getElementById("wid").value) * f;
  var D = parseFloat(document.getElementById("dep").value) * f;
  if (!(L > 0 && W > 0 && D > 0)) return;
  var m3 = L * W * D;
  // ...render
}

The part that matters is the guard clause. Users will type 0, -, or nothing, and a calculator that renders NaN looks broken.

Live version: Raised Bed Soil Calculator

Pattern 2: rule-based sizing

The second tool takes a count and applies rules. A chicken coop needs 2–3 sq ft per bird inside and 8–10 sq ft in the run, plus one nest box per five hens.

The interesting design decision is exposing the rules as a dropdown rather than hardcoding one standard:

<select id="space">
  <option value="2,8">Minimum (2 + 8 sq ft)</option>
  <option value="3,10" selected>Comfortable (3 + 10 sq ft)</option>
  <option value="4,12">Generous (4 + 12 sq ft)</option>
</select>

var parts = document.getElementById("space").value.split(",");
var inside = parseFloat(parts[0]);
var run = parseFloat(parts[1]);
var coopSqFt = n * inside;

Encoding the rules in the markup rather than in JS means you can add a preset without touching the logic.

Live version: Chicken Coop Size Calculator

Pattern 3: client-side filtering as a "tool"

The third one is not a calculator at all — it is a search filter over a static table. 24 rows of food storage times, filtered as you type.

var rows = [].slice.call(document.querySelectorAll("tr[data-k]"));
function run() {
  var v = q.value.trim().toLowerCase();
  rows.forEach(function (r) {
    r.style.display = r.getAttribute("data-k").indexOf(v) >= 0 ? "" : "none";
  });
}
q.addEventListener("input", run);

The trick is the data-k attribute holding a pre-lowercased search key. It means you can search for text that is not visible in the row — synonyms, alternate spellings, unit names.

Live version: Food Storage Time Lookup

Why bother on a static site

Three reasons that turned out to matter more than I expected:

No build step. The JS is inline in the page. Nothing to compile, nothing to version.
Works with JS disabled. The content is a real HTML table or a real list of numbers. The tool is an enhancement, not a requirement.
Tools earn links. People link to "this calculator" far more readily than to "this article". For a new site with no authority, that is the whole game.

The bit that is easy to get wrong

Mobile. All three tools use a flex row with flex-wrap: wrap and a full-width input below 620px. Without that, the labels and inputs fight for space and the tool becomes unusable on a phone — which is where most traffic actually is.

@media (max-width: 620px) {
  .calc-row label { flex: 0 0 100%; }
  .calc-row input { width: 100%; }
}

If you have built tools like this on a static host, I would be curious what patterns you reused. The three above cover most of what I needed, but I suspect there is a fourth one I have not hit yet.

Your automation says it worked. Three ways it is lying to you.

xg704863664 — Sun, 04 Oct 2026 09:59:37 +0000

I spent a day chasing a problem that did not exist, because my scripts kept reporting success.

Here are the three failure modes I hit, all in the same week, all silent.

1. The check that matched the wrong element

I had a script that clicked a button, then verified the result by searching the page for a confirmation phrase.

The verification matched. The action had not happened.

Why: the page contained the confirmation phrase in help text elsewhere on the page. My check was:

if (pageText.includes('already requested')) return 'DONE';

But the page also contained a sentence like 'If you have already requested this, ...' in a tooltip. So the check passed on every run, whether or not anything happened.

The fix is to assert on a mutually exclusive state, not a substring:

if (pageText.includes('This page is not indexed')) return 'NOT_INDEXED';
if (pageText.includes('URL is on Google')) return 'INDEXED';
return 'UNKNOWN';

Substring checks are fine for reading. They are dangerous for asserting.

2. The element that was never in the viewport

Scroll-then-click is a classic. But the order matters more than people expect:

// WRONG - coordinates are captured before the scroll settles
const box = await getBox(selector);
await scrollIntoView(selector);
await click(box.x, box.y);   // clicks whatever is now at those coordinates

The fix is boring: scroll, wait, then read the bounding rect.

I clicked the wrong element four times in a row because of this, and each time the script reported that it had clicked the target.

3. The state that persisted between runs

This one is my favourite, because the tool worked perfectly and still gave me the wrong answer.

I was reading a dashboard. It reported zero. I assumed the data had been reset.

It had not. The dashboard persists your date-range filter server-side. A previous run had set it to Today. Every subsequent run was faithfully reporting today's data - which was legitimately zero - while I compared it against last month's totals from memory.

The tool was correct. The context was wrong.

Now every scraper I write logs the state it is reading under, not just the values:

console.log('period:', period, '| value:', value);
// period: Today | value: 0      <-- instantly obvious

The common thread

All three are the same mistake in different clothes: treating a successful execution as evidence of a correct outcome.

A click that dispatches is not a click that lands. A text match is not a state assertion. A number without its context is not a fact.

The practical rule I now follow: for every action that matters, find an independent signal that it happened - a fetch, a timestamp, a status from a different system. If the only evidence is the thing that did the action, you do not have evidence.

I write practical growing and preserving guides at Herbal Home Remedies and Small-Space Growing - the automation above exists to run that site without me watching it.

Shipping a static content site on GitHub Pages: the parts nobody documents

xg704863664 — Sun, 04 Oct 2026 09:24:11 +0000

I built a 20-page static content site on GitHub Pages - no local git checkout, no build step, no framework. Everything went through the web UI and a scripted browser.

Here is what actually mattered, including the parts that cost me hours.

1. The branch is the deploy

There is no deploy button. Push to the branch configured in Settings -> Pages and GitHub rebuilds. The practical consequence nobody mentions: after a commit, the live URL 404s for 30-90 seconds while it rebuilds.

If you verify a file immediately after committing it, you will get a false negative. I hit this verifying a Search Console token file - first check 404, second check (a minute later) 200 with the right contents.

2. `/new/main` only works for files that do not exist

The web editor URL github.com/<user>/<repo>/new/main is the natural way to create a file programmatically. But if the file already exists, the flow does not silently overwrite - it errors, and if you are driving the UI blind you may not notice.

Editing needs a different route: github.com/<user>/<repo>/edit/main/<path>, then select-all and replace.

This cost me a stale sitemap.xml that I thought I had updated for several hours.

3. IndexNow is the fastest indexing lever you have

IndexNow is a simple protocol: host a text file containing a key, then POST your URLs.

# 1. key file at https://example.com/<key>.txt  (contents: the key)
# 2. POST:
curl -X POST https://api.indexnow.org/indexnow \
  -H 'Content-Type: application/json' \
  -d '{"host":"example.com","key":"<key>","keyLocation":"https://example.com/<key>.txt","urlList":["https://example.com/page/"]}'

Bing, Yandex, Seznam and Naver consume it. A 202 Accepted means it was queued.

Gotcha: the key file must be reachable before you submit, or the submission is rejected. Verify it returns 200 first.

4. Search Console verification for a subdomain-hosted site

If you are on *.github.io, you cannot do DNS verification. Use the HTML file method instead - you can commit the token file to the repo root.

The file contents are exactly:

google-site-verification: google<token>.html

And remember point 1 - check it is live before clicking Verify.

5. Request indexing has a daily quota and a silent failure mode

URL Inspection -> Request indexing pushes a URL into the priority crawl queue. In my case Googlebot arrived 14 minutes later.

Two things to know:

There is a daily quota (around 10 URLs). Exceeding it returns a quota message.
Check that the request actually registered. If your automation checks the wrong element, you can keep requesting indexing for days and never notice that nothing happened.

I lost two URLs to exactly that. I only found out by auditing crawl status page by page.

6. FAQPage structured data for question-shaped queries

If your content answers specific questions, add FAQPage JSON-LD. It is cheap and it targets the long tail:

<script type="application/ld+json">
{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[
  {"@type":"Question","name":"How much space does one chicken need?",
   "acceptedAnswer":{"@type":"Answer","text":"About 2-3 square feet inside the coop."}}]}
</script>

Keep the answers short and literal - they are competing for a snippet, not for a full read.

7. What I would do differently

Commit the sitemap last. Every page you add invalidates it.
Do not trust a UI action you cannot verify. Every state change needs an independent check (a fetch, a crawl status, a log line).
Indexing is not ranking. Getting crawled took minutes; getting indexed is taking days; ranking is a different problem entirely.

The site in question

The result is a set of practical guides on herbal remedies, small-space growing and keeping a few chickens - Herbal Home Remedies and Small-Space Growing. The content is deliberately plain: amounts, temperatures, and the caveats the sales pages leave out.

If you are doing something similar, the whole thing is a single repo with static HTML - no build, no dependencies, and it deploys from a commit.