I measured the title and description of all 991 of our pages: 991 distinct, none over budget, and the tests say 47, 48, 59 and 60

CogniPrep publishes 991 pages. Most of them are generated from registries rather than hand-authored one by one, which is the arrangement that normally produces duplicate titles and descriptions at scale. So I fetched every URL in our own sitemap and parsed the head of each one.

991 URLs, 991 answered 200 titles 991 distinct 25 to 60 chars mean 52.6 descriptions 991 distinct 104 to 159 chars mean 146.8 

Zero duplicates on either field, zero titles over 60, zero descriptions over 160, and nothing under 104 characters either. I did not expect that, and the interesting part turned out to be why it happened, because it is not the tests.

Why the ceiling is exactly 60

The root layout owns a title template:

title: { default: 'CogniPrep - Psychometric Test Practice', template: '%s | CogniPrep', }, 

| CogniPrep is 12 characters. Every page supplies the %s part, and the longest one anybody has written is 48 characters. 48 plus 12 is 60, which is why the distribution has a hard wall at exactly the number a search result starts truncating at.

The top of the histogram, measured on the live HTML:

Four pages sit precisely on the line. Having a visible brand suffix turns out to be an accidental forcing function: the budget a writer feels is 48, not 60, because the suffix is already there in the template and they are typing into what is left.

One page in 991 has no brand in its title

title: { absolute: 'Civitas Senior Living Assessment Practice' }, 

absolute is Next.js's opt out of the parent template, and one employer page uses it. It is the only one in the repository, and the result is a 41-character title with no | CogniPrep on it, where the template would have produced 53 and fitted comfortably. Nineteen characters of unused budget and no brand, which is not a trade anybody would make on purpose.

The homepage is the other page without the suffix, and that one is deliberate: it uses the template's default, which is how you give a site root its own title.

So: 989 of 991 titles end in the brand, one is the home page, and one is a mistake that no test could see, because it is not a length problem.

Now the part that is a mess

There are 98 title-length assertions across 50 test files, and they are written five different ways:

Four effective ceilings: 47, 48, 59, 60. Two of them are the pre-suffix budget disagreeing with itself by one character, and two are the post-suffix budget disagreeing with itself by one character, and nothing in the repository says which of the four is the rule.

Descriptions are better behaved: 135 assertions, all of them toBeLessThan(160), which gives the 159 maximum the live measurement found.

The reason for the spread is how the tests were written. Each provider has its own registration test file, many of them produced on separate branches at different times, and each one asserts the limits for its own content. Nobody was copying from a shared constant, because there is no shared constant. There is a prose comment in a type definition that documents 48, and 74 assertions that say 47.

The pages on the line are the ones with no test

The four titles at exactly 60 characters are per-test pages under three providers. Their providers' registration tests do have title assertions, and here is one of them:

it('has a hub whose title and description fit the limits', () => { const title = /const TITLE = '([^']+)'/.exec(hub)?.[1] ?? ''; expect(title.length).toBeLessThanOrEqual(47); 

That reads the hub page's source as text and checks one constant. The per-test pages below that hub are not in the loop, which is exactly why they are the four allowed to reach 48.

Coverage by cluster is lopsided in the same way:

The 50 files that assert a title length are, with five exceptions, one per assessment provider. There is no blogs test, no cheating test and no employer test in that list: the single employer-page assertion lives inside one provider's file, for one page.

The unguarded clusters are clean anyway. 116 blog articles, 116 distinct titles between 39 and 59 characters, 116 distinct descriptions between 130 and 159, held there by nothing but the writer having the number in their head. Same for the 65 cheating guides and the 211 employer pages, whose descriptions run 117 to 159.

What actually produced the clean result

In order of how much work each one is doing:

1. The template. It makes the budget visible at the point of writing, and it makes the brand suffix free, so nobody spends characters on it by hand.
2. Registries rather than pages. A title that lives in a data file next to 50 sibling titles gets compared with its siblings. A title buried in a page component does not, which is how duplicates happen on sites like this.
3. The tests, third, and only in the clusters that have them. They are regression guards for the content somebody has already got right.

That is an uncomfortable ordering if you like tests, and it is the honest one. The fix is not more assertions in more files, it is one exported constant that 98 call sites can import, so that the next person who writes 47 writes the same 47 as everybody else. A rule enforced 98 times with four values is a convention wearing a test's clothing.

See it

Open any page and read the two fields. These four are the ones on the line at 60:

• cogniprep.app/games/asvab/arithmetic-reasoning
• cogniprep.app/games/asvab/auto-and-shop-information
• cogniprep.app/games/thomas/ppa
• cogniprep.app/games/watson-glaser/interpretation

And cogniprep.app/employers/civitas-senior-living is the one with no brand suffix, which you can confirm in one glance at the browser tab next to any other employer page.

The whole audit is a sitemap fetch, two regexes and a Counter. If you run a programmatic content site and have never counted your distinct descriptions against your page count, that is the half hour with the best chance of embarrassing you.