Help article titles should name a task as customers recognise it rather than as your team labels a module in its panel. An existing instruction can be correct but difficult to find when it uses only internal terminology. You do not need another article for every synonym. Compare customer words with the feature name, improve the title and lead, then try finding that existing content through a few safe search examples rather than expanding the catalogue with duplicate explanations.

Choose an existing instruction that people cannot find

A naming problem exists when useful content already exists but customers cannot recognise its title or find the words they use. Start with one task, such as recovering access, instead of browsing the entire catalogue without a criterion. Open the instruction and check that it leads to the expected result. Missing content is a different task from renaming; broader organisation belongs to a website knowledge base and FAQ.

Record two safe examples of how customers describe the need: “forgot my password” and “cannot get into my account”. Do not assume those phrases always indicate the same cause; access can fail for another reason. The title should lead to the right task and the lead explain its scope. Avoid hiding distinctions because a broad title might attract more clicks to an instruction that cannot resolve some of the situations suggested by its heading.

Map customer words to the feature name

A terminology map joins the everyday phrase, official name and visible product label. Password recovery might connect “get my account back”, “password reset” and “Forgot password?”. Name the task in the title and use the actual button label in the steps. That lets readers move from their need to the correct interface action without guessing which control to choose; finding the article becomes the beginning of completing the task rather than another point where they get stuck.

Avoid comma-separated keyword piles. “Password, login, account, access, reset, recovery” does not say what the article enables and may imply more scope than its content supports. Select one main phrase and place another naturally in the lead. Plain-language guidance helps name an action without jargon; it does not require removing every technical term when a term helps readers locate the actual button or recognise a particular service they already know by its official name.

Write a task-based title and a lead with a boundary

A task title names an outcome or action, such as “How to change an appointment date”. The lead defines the case: “Change a confirmed visit when your offer allows changes before it starts.” This fictional structure needs your actual process conditions. Do not write “every visit” if the instruction covers only some offers, and do not promise independent changes where customers can only submit a request to the team rather than modify the booking record themselves.

Scroll the table sideways to see all columns.

Team termCustomer titleTerm in the lead
Slot modificationHow to change an appointment dateBooking change
Credential recoveryHow to recover account accessPassword reset
Fiscal documentationHow to get an invoice for a purchaseInvoice details

The table proposes replacing internal labels with recognisable tasks, not asserting that every listed action is independently available in Meetlead. Their availability depends on your product and process. Check whether the title distinguishes a procedure from an explanatory question: “How to get an invoice” and “When an invoice is available” serve different needs. Avoid combining them under an imprecise heading if they lead to different actions and require different information to help a customer decide what to do next.

Test search according to its actual matching behaviour

Search trials should reflect the supported mechanism rather than expectations of any AI tool. Meetlead's help article list uses indexed tokens and a prefix for the last query fragment. Do not promise automatic recognition of every synonym or an entire sentence's meaning. Try a natural customer phrase, a feature-name variant and a short task phrase; note whether the right instruction appears and whether its title makes the relevant result recognisable among other returned articles.

Compare article language with the language selected by the visitor too. Content in another language is not equivalent to a clearly named result for that reader. When results are absent, check publication and search scope before renaming again. Broader diagnosis belongs to website search with no results; this task assesses findability of one existing instruction rather than automatically collecting arbitrary search entries or assuming that the widget stores every phrase typed into the customer's own website search.

Google recommends descriptive headings and titles based on a document’s main purpose, with task-based titles for tutorials. This is editorial guidance rather than a ranking promise: documentation headings and titles.

Check title recognition without opening the article

A title also works when a reader scans results without typing your exact phrase. Show several real titles to a colleague and ask which helps with one specified task. Do not supply the answer or internal module name; “Which text helps change a visit?” tests whether the heading carries its own information. When two titles appear identical, name their situation or audience difference rather than adding a sequence number that explains nothing about the content or its intended use.

Ensure the title matches the first instruction step and its illustrations. Opening the article should not reveal a different panel version or an administrator-only task. Screenshots in help instructions help identify controls but cannot repair an unclear result title. After renaming, keep the task name consistent across the lead, headings and body; three different labels should not suggest three separate operations when they actually refer to the same available feature in the product interface.

Publish the rename and preserve the terminology map

A rename is ready after you check the version readers actually receive. Prepare title and lead, publish through your website's permissions and repeat the earlier queries. Help Centre content and Meet AI knowledge connect help texts with company sources, but publishing an article does not automatically rebuild all active AI knowledge. Do not turn a successful list-search trial into a promise that the model immediately uses the new title in every response generated afterwards for another customer.

Preserve the main phrase and feature-name map with the article so the next editor does not restore a convenient internal label. Include the comparison in new operator onboarding when the text supports the team, without creating a parallel help catalogue. Review genuine examples of an existing instruction not being found; avoid speculative synonym additions or renaming after every isolated question that actually concerns a different task rather than the procedure the current article is intended to explain.

Questions about help article names

Does every synonym need a separate article? No, when the words describe the same task and instruction. Use the main phrase in the title and a necessary alternative in the lead or opening explanation. Separate content suits different actions or conditions rather than different words alone; duplicate instructions make maintaining one accurate answer more difficult when rules or interface labels change.

Does a simple title guarantee the content will be found? No, results also depend on publication, language, indexing and query matching. Clear naming helps recognise a result but does not replace testing search. Try the saved phrases and compare the actual output rather than promising better rankings or automatic recognition of every wording variant merely because you changed a heading.