LLM Best Practices

Site-level slop

3 min read

View markdown source

Overview

A single page can pass every sentence-level rule in the anti-slop rules while the site as a whole reads as generated. Search engines judge at this level too: Google’s scaled content abuse policy targets many pages that add little value, however they were made, and Bing’s Webmaster Guidelines name scraped or lightly rewritten content without new insight. Check the corpus, not only the page.

The patterns below are invisible in a single-page review. Each one needs a cross-page check, and most can be scripted.

Write a page-specific opener for every page

The same first sentence on dozens of pages (“This page is the atomic definition”) is boilerplate the reader skips. On this site, scripts/lint-content.mjs fails the build when more than three pages share an ## Overview opening sentence. Open with the fact or rule that only this page can state.

Merge near-duplicate pages instead of keeping both

Two pages with the same outline in different words split signals and invite an engine to pick the wrong one. Bing has noted that LLM-based answers cluster near-duplicates and pick one representative, so the second page earns nothing. Merge them and redirect; see cannibalization.

Before creating a page, search existing titles for the same intent:

grep -rhi "^title:" content | grep -i "<topic>"

Keep one related list per page

A “Related concepts” list followed by a “Related” list with the same links doubles the length and adds nothing. Fold inline links into the prose and keep a single ## Related list at the end.

Let section headings follow the content

Every page with identical H2 names in identical order, regardless of topic, reads as a fill-in form. Keep the sections the schema requires (on this site, ## Overview and ## Related); let the rest follow the content, and open each H2 with the rule it covers.

Bump dates only with substantive edits

Bumping last_updated across hundreds of pages in one commit without body changes is a date sweep. Google’s helpful content guidance names changing dates to seem fresh, without substantially changing the content, as a warning sign. Update the date when the body meaningfully changed; see content-refresh.

A quick check for a sweep in the history:

git log --shortstat --format='%h %ad %s' --date=short | grep -B2 -E "[0-9]{3,} files changed"

Any commit touching hundreds of files where the insertions roughly equal the file count (one changed line per page) deserves a second look.

Backlinks