Formship

Guides

How help-center drift happens, and a 20-minute monthly check you can run yourself

Why help articles fall behind a product, where the wrong sentences usually sit, and a monthly check one person can run with a changelog and a search box.

Help-center drift is a help article saying something that a shipped change has made false. The page still loads and people still read it. It gives them the wrong answer.

Nobody decides to let this happen. It comes from how releases and docs are usually split between people, and it can be caught with a short check once a month.

How it happens

Most teams document new features well. A launch gets an article and a changelog entry. What gets missed is an older sentence somewhere else that the launch quietly contradicted. These are the usual paths.

  • A limit is lifted. An article says a feature is only on the top plan, or that a setting can't be changed. Later the changelog announces the opposite. The old sentence stays, because nobody searches the help center for the word "can't".
  • Something is renamed. The product now says Labels. Some articles still say Tags, and a user can't find the button the article names.
  • A step moves. Export moves from Settings to a File menu. The how-to still starts with "Go to Settings".
  • A plan or price changes. Plan names, prices and limits are repeated across many articles, and every copy has to change. There is a separate checklist for that.

In our own early field note, renames were the obvious case but the first shape was the common one: an article stating a limit after the changelog said the limit was gone. That sample was small and not random, so treat it as a hint about where to look.

Why it's hard to catch

The person who writes the changelog is often not the person who owns the help center. Each one does their part, and the gap sits between them.

Help-center search matches words. Searching for the feature that changed finds the new article you just wrote. It does not find the old sentence that now disagrees with it, unless you search for the old words.

Support agents who know an article is wrong can answer around it in tickets for months. Each ticket gets solved and the article never gets flagged.

The 20-minute monthly check

You need your changelog, your help center's search box (or Google), and a doc for notes. Block 20 minutes on the first working day of the month. The times below are a guide for a month with a handful of changes.

  1. List last month's changes (5 minutes). Open the changelog and copy every entry from the last month that changes how someone does something: a rename, a moved menu, a new or removed limit, a changed default, a plan change, a removed feature. Skip bug fixes and performance work. Skip brand new features too, since there is nothing older for them to contradict.
  2. Write down the old words (5 minutes). For each change, write the words an article would have used before it. If Tags became Labels, the old words are "tag" and "tags". If export left Settings, search for "Settings" together with "export". If a feature reached a cheaper plan, search for the old plan name next to "only", "available on" or "upgrade".
  3. Search for the old words (8 minutes). Use the help center's own search. If it is weak, use Google with site:help.example.com "old phrase", swapping in your help center's host. Open each hit and read the sentence around the match. Ask one question: would a user who follows this sentence today get stuck or get the wrong answer?
  4. Log it and fix it (2 minutes, plus the fixes). For each wrong sentence, note the article URL, the sentence as it reads now, the changelog entry and date that made it wrong, and the sentence that should replace it. Fix the easy ones on the spot. Send the rest to whoever owns those articles.

Things that make it faster

  • Search for negatives. Sentences with "only", "not available", "can't", "requires" or "upgrade to" go stale when a limit moves.
  • Read the tables. Plan comparison tables and lists of limits hold a lot of old values, and they are easy to skim past.
  • Keep the log. After a few months it shows which parts of the product drift most. Those articles deserve a look after every release that touches them.
  • Ask support. A one-line message to the support team, "which articles do you answer around?", often surfaces drift that search misses.

What this check misses

It only finds drift from changes you announced. A change that never reached the changelog won't show up. Search also can't read screenshots or videos, so an old menu in an image stays until someone looks at it. A clean month means nothing obvious turned up. It doesn't mean every article is current.