The laptop-model problem: 99 pages about one keyboard shortcut

In our corpus of 3,038 competitor pages, one cluster is 99 pages long and every page answers the same question.

• how to screen record on an Acer Aspire laptop
• how to screen record on an Acer Nitro laptop
• how to screen record on an Acer Predator laptop
• how to screen record on an Acer Swift laptop
• how to screen record on an Acer TravelMate laptop

Then Alienware, by sub-model. Then Asus, by sub-model. Then Dell, by sub-model. Then Surface, by sub-model.

Screen recording does not vary by laptop model

This is the entire argument and it takes one sentence. Recording your screen on an Acer Swift and recording it on an Acer TravelMate are the same operation, performed with the same operating system, using the same key combination or the same application. There is no honest version of these two pages in which they differ.

The measurements agree. Across the cluster:

• Median length: 590 words, in a tight band from 575 to 604
• 100% of each page’s headings are shared with the majority of its siblings, after blanking out proper nouns
• 55% of each page’s text appears verbatim on at least one sibling
• Zero links to any source outside the company’s own domain

The 100% figure is the one to sit with. We measure structural sameness by taking each page’s headings, replacing every proper noun with a placeholder, and asking how many of the resulting shapes its siblings also use. A number in the twenties is normal for a templated section. A hundred means every page is the same skeleton with the nouns swapped, which is the definition the spam policies use.

Why anyone builds this

Because the queries are real. People do search “how to screen record on a Dell Inspiron”. Search demand exists at the model level even when the answer does not vary at the model level, and a keyword tool will hand you that list sorted by volume.

The reasoning is: the query exists, therefore the page should exist. It feels like serving the user. It is actually the multiplication pattern with better intentions, and it is close to the canonical example in Google’s own guidance on scaled content.

The same mistake is available to us

We should be careful here, because our own plan had a version of this in it.

Our volume archetype is tutorials, addressed as tool and task. That shape is fine when the task genuinely differs per tool: recording a walkthrough in Linear really is different from recording one in Figma, because the interfaces, the object names, and the number of steps to get anywhere are different.

It stops being fine the moment we start generating the cross-product. Eight tasks times sixty tools is 480 pages, and somewhere in that grid are dozens of pairs where the answer does not actually vary. The multiplication is available to us exactly as it was available to them.

Our defence is not restraint or good intentions. It is that our schema will not produce a page without a recorded click path and observed notes from a real run, and you cannot observe a run you did not do. If two tutorials would end up identical, it is because the two runs were identical, and in that case we should not have run the second one.

The cost is that we will publish far fewer pages than 480. The benefit is that every one of them had to be earned by somebody sitting down and doing the task.