A tab title is the first thing a user reads before the page even loads
Generic titles like "Home" or "Dashboard" cost clicks in search results and open tabs
Every RAXXO tool follows the same title formula: tool name, then the one thing it does
Five minutes fixing titles beats five hours chasing traffic that never converts
The Line Nobody Reads Until It Is Wrong
I did not think about browser tab titles until I had six tabs open one evening, all from my own tools, and every single one said "Dashboard." I could not tell OhNine from Statusline Builder from Git Dojo without clicking through each one. If I could not tell my own products apart at a glance, a stranger with twenty tabs open had no chance.
That was the moment the title tag stopped being an afterthought. A browser tab title does three jobs at once. It is the headline in a Google search result. It is the label on every open tab. It is the text a screen reader announces first when a page loads. Most builders treat it as a formality, something the framework fills in with the page component name or the word "Home." I used to do the same thing.
The fix is not clever. It is a formula I now apply to every page on every RAXXO property: tool name first, then a short, specific description of what that exact page does, separated by a single character. Not a tagline. Not a slogan. A description a person scanning ten search results in half a second can act on.
"OhNine" alone tells a stranger nothing. "OhNine, Menu Bar App for Claude Limits" tells them exactly what to expect before they click. The difference sounds small until you watch someone tab-switch between four of your own products and realize they cannot find the one they wanted without hovering over each tab first. Attention is the scarcest resource a small studio has, and a vague title spends it for free.
I keep a plain text file with every page's title written out before I touch a line of layout code. If I cannot write a title that describes the page in under 60 characters, the page usually does not have a clear enough job yet. That has caught more structural problems than any design review. A page that resists a clear title is a page trying to do two things at once.
Why Generic Titles Cost More Than They Save
A generic title feels harmless because nothing breaks. The page still loads, the button still works, the checkout still fires. The cost shows up somewhere you are not looking: in search rankings, in bookmark folders, in the moment someone tries to find your tool again three weeks later and cannot remember what it was called because the tab just said "Pricing."
Search engines weight the title tag heavily, more than most builders expect, because it is the single strongest on-page signal of what a page is actually about. A page titled "Home" competes with millions of other pages titled "Home." A page titled with the exact product name and the exact problem it solves competes with almost nobody, because almost nobody bothered to be that specific.
There is a second cost that is harder to measure but just as real: trust. A person who lands on a page from a search result expects the tab title and the page content to match what they searched for. When they do not match, the bounce is immediate. I have watched this happen on my own analytics when a title drifted out of sync with a page after a content update and nobody caught it for a week. The traffic did not disappear. It arrived and left within seconds.
Bookmark folders are the quiet reason I care most. A customer who liked Git Dojo and wants to come back to it later saves the tab or bookmarks the page. If the title said "Git Dojo, Terminal-First Git Lessons" instead of "Home," that bookmark is useful six months later. If it said "Home," it is one more unlabeled link in a folder of a hundred unlabeled links, and the easiest thing for that person to do is forget it exists and search for something else instead, possibly a competitor's tool that happened to title its pages correctly.
None of this requires new tooling or a redesign. It requires deciding, before a page ships, what the shortest true sentence about that page is, and putting it where the browser will show it first.
The Formula I Use On Every Page
Every RAXXO tool gets the same title structure, applied without exception, because consistency is what makes the formula work across five separate products instead of five separate habits. The structure is: product name, comma, then the specific job that page does, kept under 60 characters so search engines do not truncate it with an ellipsis.
The homepage of a tool gets the broadest version: "Statusline Builder, Build a Custom Claude Code Status Line." A pricing page gets narrower: "Statusline Builder Pricing, One-Time Purchase." A docs page narrower still. Each title answers the same silent question a stranger asks in the half-second before they decide whether to click: is this the page I am looking for.
I write the title before I write the page copy, not after. That order matters more than it sounds like it should. Writing the title first forces me to state the page's one job in a single sentence before I have the chance to let the page sprawl into three jobs. If I cannot compress the page into a clean title, I usually find out the page needed to be split into two pages, and I find that out before launch instead of after a customer gets confused.
Product pages get an extra rule: the title names the product and the outcome, never the internal build details behind it. "Git Dojo, Learn Git From the Terminal" tells a visitor what they get. It does not describe how the lessons are generated or what tools built them, because a title is marketing surface, not documentation. This is the same instinct behind why every RAXXO tool ships in dark mode first: one rule, applied everywhere, so consistency does the work that a bigger team would otherwise need a style guide and a review process to enforce.
Legal pages, the 404 page, and the waitlist page all get titles too, and they follow the same rule even though almost nobody screenshots them. A 404 page titled "Page Not Found, RAXXO Studios" instead of the framework's default "404" tells a lost visitor exactly where they ended up and that the studio, not a broken link, is still in control of the experience.
Blog posts follow a slightly different version of the same formula, because a post competes for attention against every other article on the same topic across the entire web, not just against other RAXXO pages. Here the title leads with the specific claim or question the post answers, not with the studio name, because nobody searches for a studio they have not heard of yet. A post about pricing habits titled "RAXXO Studios, Blog Post 42" would never surface for anyone searching how independent studios handle EUR pricing. A title built around the actual question a reader typed into a search bar has a real chance.
What I Check Before Calling a Page Done
Title checking is now part of the same pre-launch pass that covers accessibility and performance. Before I call any page shipped, I open it in a browser with only that one tab, close everything else, and read just the tab title with no other context. If it does not tell me, cold, what the page is and which product it belongs to, it fails the check and I rewrite it.
I also paste every title into a character counter before it ships. Sixty characters is the rough ceiling before Google starts truncating a title in search results, and a truncated title that cuts off mid-word looks careless in a way that costs more trust than a slightly shorter, plainer title would. I would rather ship "OhNine, Menu Bar Claude Limits" at 31 characters than a title that gets clipped to "OhNine, the Only Menu Bar App That Actually Tra…"
The other check is duplication. With over a hundred products and pages live, it is easy for two pages to drift toward the same title without anyone noticing, especially after a content refresh. I keep a running list of every live title, sorted alphabetically, and scan it before adding a new page. Two pages competing for the same search intent with the same title is wasted surface area. Each page should own a distinct question a visitor might ask.
None of this is glamorous work. It will never be the feature I lead with in a launch post, and no customer has ever emailed to say the tab title was great. It sits in the same category as the favicon rule every RAXXO tool follows before launch: a detail that compounds quietly, page after page, tool after tool, and costs almost nothing to get right the first time compared to fixing it across a hundred pages later.
Bottom Line
A browser tab title is one line of text, and it is easy to treat it like an afterthought because nothing visibly breaks when it is wrong. But it is the first thing a search engine reads, the first thing a crowded tab bar shows, and the first thing a screen reader announces. Getting it right costs a few minutes per page. Getting it wrong costs clicks, bookmarks, and the small daily trust that keeps someone coming back to a tool instead of searching for a replacement.
The formula I use, product name first, then the specific job the page does, kept short enough to survive a search result without truncation, is not clever. It is just applied consistently across every page on every RAXXO product instead of left to whatever a framework defaults to. That consistency is the actual product of a one-person studio: not any single clever trick, but the same small discipline repeated enough times that it starts to look, from the outside, like a much bigger team was behind it.
If you build anything with more than one page, write the title before you write the copy. It will tell you faster than anything else whether the page actually knows what it is for.
Top comments (0)