The tags were all there
My Shorts uploader builds a title, a description, and hashtags for every video and uploads it. Videos come in three languages: Korean, English, and Japanese. No video went out without hashtags, and there were no upload errors.
The problem was the order. The first slots in the description hashtags held words like "free" and "web app". Those words aren't wrong about the app. But nobody looking for a horoscope app starts by typing "free" or "web app" into the search box. They type topic words: 별자리운세, 占い, zodiac.
This matters because of how YouTube treats description hashtags. Only the first three appear above the title, and if there are more than fifteen, all of them are ignored. More is not better. The first three slots are most of what counts, and too many drops you to zero.
In your own upload pipeline, which words are sitting in the slots the platform actually shows?
Why I didn't notice
My check was "are there tags?" If there were tags, it passed. How many there were, what order they came in, and how many were actually shown were never part of the check. A tag list is just an array of strings, so "free" and "별자리운세" are equally valid values. The code had no way to tell them apart.
The other mistake was treating description hashtags and the API tags field as the same thing. They do different jobs. Description hashtags are visible to viewers and limited in count and order. The tags field is metadata that never shows on screen. Putting roughly the same list in both meant it fit neither one.
What would you do: add more tags, or decide first what goes in the visible slots?
What I changed
The fix touched one uploader file: 46 lines added, 6 removed.
First, a per-app search topic dictionary (TOPIC_TAGS). Each app gets the topic words people would actually search for, kept separately in Korean, English, and Japanese. For a horoscope app, that means words like 별자리운세, 占い, and zodiac.
Second, description hashtags were cut to five: three topic words, one Shorts tag, and one market tag. The three slots shown above the title all go to topic words. Since the count is fixed at five, the description can't go over fifteen and get every hashtag ignored.
Third, low-value tags like "free" and "web app" came out of the front slots. Keywords that could bring in search traffic now come first.
Fourth, broader tags went into the API tags field, which is filled more generously, up to fifteen. The visible slots are narrow and precise. The hidden field is wide.
Self-check
- Does your code know how many hashtags the platform shows, and how many make it ignore all of them?
- Are the visible front slots filled with topic words people actually search for, or with modifiers like "free"?
- Are you handling visible hashtags and hidden metadata tags as one shared list?
The honest part
I don't know yet whether this brought in more search traffic. The commit records the new structure, not any before-and-after numbers for impressions or traffic. The per-app topic words weren't chosen from data either. They're my guess at how people search, and that guess still needs checking. The rule itself, three shown and everything ignored past fifteen, will need updating if the platform changes it. What this fix actually settled is narrower: the code now decides what goes into the visible slots.