The first twenty articles decide whether anybody comes back to the base, and choosing them from the product's feature list is the mistake almost everybody makes. There is a better ranking, and it takes an afternoon with the ticket export.
Rank by frequency times handling time
A question asked ninety times that takes two minutes to answer and a question asked eight times that takes forty are worth similar amounts. Ranking by frequency alone puts password resets at the top and leaves the genuinely expensive questions unwritten.
Read the customer's actual words
Take the article title from the ticket subject lines rather than from the internal noun. This is the whole of search optimisation for a support base and it costs nothing but the reading: if customers call it an invoice and the product calls it a statement, the article has to carry both.
Write the answer that was actually given
The best draft already exists in the ticket where somebody answered it well. Starting from that is faster and produces an article in the voice of somebody solving the problem rather than describing the feature.
One question per article
A page answering four related questions ranks for none of them and is skimmed past by all four askers, each of whom has to find their part. Splitting is nearly always right, and it also lets each one carry a different owner and a different review date, which longer pages cannot.
Put the review date on from day one
Support articles rot fastest because they describe a product that changes. Twenty articles on a three-month cycle is eighty reviews a year, which is a real commitment: the planner on this site prints what that costs before you commit to it.
Questions people ask about customer support knowledge base
What if we have no ticket history?
Then use the last month of chat and email by hand. Twenty questions is a small enough sample that a person can collect it in an afternoon.
Should we write for search or for existing customers?
Existing customers first. Support articles that rank publicly are a bonus; support articles that deflect are the point, and writing for the second usually achieves the first anyway.
How do we keep the twenty from becoming two hundred?
Require an owner before publishing. It is a soft cap that self-enforces, because the review load is visible.