How Can We Make AI-Generated Blog Titles Readable?

Introduction

Wiblog takes a keyword, prepares topic candidates with descriptions, outlines, and sources, and generates an article from the topic the user chooses.

When I reviewed real estate topics myself, the titles often stopped me. They were long and stiff, and I could not immediately tell what answer an article would provide.

This post follows the problems I encountered in use back to the generation instructions and code. In particular, it explains which judgments I left to the LLM and which behaviors I handled in code. It ends with a complete before-and-after comparison from an additional title-generation run on 21 existing topics.

1. Discarding Topics Because of Their Titles Led Me to the Generation Path

I discarded topics because I could not edit their titles

At the time, users could not edit a topic card’s title before generating the article. They could edit the title of a generated article, but not while choosing a topic. As a result, I often excluded the entire topic card when I disliked its title.

The saved titles show what this verbosity looked like. The Korean titles are translated into English here and in the comparisons below.

The titles seemed to contain useful material, but I did not particularly want to click them. Phrases such as “how to check,” “selection criteria,” and “key information” kept recurring. Placed side by side, topics covering different subjects all looked like similar instruction sheets.

Overlapping problems made it hard to identify what to fix

I was the only PoC engineer, and I was putting experiments into production almost weekly. Identifying what needed fixing took much longer. Awkward titles, outlines drifting away from the original question, and missing source material were appearing together.

I had to distinguish whether a title merely needed shortening, whether the outline was wrong, or whether the sources were insufficient. That meant checking not just the title on screen, but also the generation instructions and the paths where it changed.

Titles were generated more than once

The system first generated a title from a keyword, then generated another title after gathering material and writing the outline. Improving only the initial title would still allow it to be overwritten later.

Keyword → Initial title → Source collection and outline → Final title regeneration

Trying to represent transport, living conditions, market prices, and parking adds one item after another to the title. This helped explain the verbosity I saw on screen. Without deciding which answer the title should foreground, representing more of the outline could simply make the title longer.

This was an improvement opportunity identified from the previous code and its visible output. I did not trace every intermediate title for each topic and measure whether it grew at every stage.

2. Grok Chose the Title Format; Code Enforced the Rules

Shortening titles or adding question marks was not enough

Changing “how to check” into “how can I check?” makes a sentence a little more conversational. But someone looking for the current status needs the status itself. “Where can I check the current status?” can change the promised answer into lookup instructions.

The intermediate results also leaned too heavily toward questions. Version 9 of the early comparison still produced many question titles, and it also replaced established real estate terminology: “school districts and apartment prices” became wording closer to “schools and house prices, summarized.” In trying to sound natural, it changed terms familiar to readers in the field.

What these iterations revealed was the need to distinguish the kind of answer the reader wants. A direct question about an amount, a request for a schedule or list, and a request for actual experiences did not all need the same instructional tone.

The word “price” did not automatically trigger a question title. Required purchase funds and a comparison of prices across areas call for different answers. There were no quotas for each format or fixed sentence endings.

I left interpreting the input and outline to Grok

Grok was already generating the titles. The change was to instruct Grok, within the title-generation prompt, to choose a format first and then write the title. A separate classifier did not assign the format.

Grok reads the input and outline, determines what answer is being sought, and writes a title in a form that conveys that answer. The aim was to generate a natural title suited to the planned content, without forcing it into a fixed sentence template. Question, informational, and experience-based formats are criteria that help guide that judgment.

The title model does not read the entire finished article. Source texts are used to write and verify an outline, which is then passed to title generation. The reader question is also only wording guidance, not factual evidence.

From topic to title: a step-by-step timeline

The following is an illustrative example of the processing flow. It shows how a draft covering several points narrows its focus after the outline is available.

Association eligibility and contract clauses remain in the outline as material to explain. The title foregrounds the question connecting them: “Could I buy the property and still end up with cash settlement?” Grok decides what belongs in the title, while code keeps the validated title in subsequent generation steps.

I handled mandatory behavior in code

Choosing natural wording is different from preserving saved input or checking for required response fields. I left meaning judgments to Grok, but did not rely solely on prompts for rules that code could enforce explicitly.

input_coverage is an LLM’s assessment of meaning. Checking its value in code does not independently verify the facts in the sources.

A saved sentence takes precedence over format selection. I did not let the model rewrite a person’s question into its preferred wording. The rule blocking a change from status to lookup instructions also distinguishes inputs and saved sentences that explicitly asked for lookup instructions in the first place.

3. Regenerating Titles for the Same 21 Topics

These are English translations of the Korean titles, not a separate English generation experiment. “Jeonse” refers to Korea’s lump-sum deposit rental arrangement; “villa” here refers to low-rise multifamily housing.

The titles made the promised answers clearer

The clearest change was that instructional phrasing and lists receded, while the reader’s question or the information provided came to the foreground.

For Seongsu, “progress by district” replaced “how to check status,” making the information available in the article immediately clear. The Jangji-dong title moved from listing noise, reviews, and support information to resident reviews of aircraft noise in an officetel, making the experience being discussed more specific.

The deposit title became longer, but replaced the vague idea of “preparing” with “how much and when?” The point of this change was to clarify what the article answers, rather than simply make titles shorter.

Conclusion

The starting problem was long, stiff titles. Addressing it required both a judgment about what to keep in the title and code that preserved that judgment afterward.

I left interpreting the input and outline and selecting the title’s form to Grok. I used code to preserve original wording, handle explicit errors, and retain finalized titles. That boundary let the title express the answer the planned article could provide and kept the result intact through later generation stages.

The next post covers carrying the needed answer into search queries and assigning collected platform documents across topic candidates.