Title Tags and Meta Descriptions in Website Builders

The title tag and the meta description are the two fields every website builder exposes, which makes them the least interesting controls to compare and the most consequential ones to get right. They are the only part of your page a person reads before deciding whether to open it. Everything else on a page is downstream of that decision.

They are also where builders differ in a way nobody warns you about — not in whether the fields exist, but in what sits above them. Site-wide patterns and title formats are the feature that quietly generates near-duplicate titles across a whole small site, and it is on by default in more places than people realise.

Where the fields live

Wix puts per-page title and description in an SEO panel attached to each page, and layers site-wide patterns above it in the dashboard.

Squarespace puts an SEO title and SEO description in each page's SEO tab, with site-level title formats in the site settings above them.

Webflow puts them in page settings, where they can also be bound to CMS collection fields, so a collection of four hundred items generates four hundred distinct titles from one expression.

Shopify puts them in the search-engine-listing section at the bottom of each product, collection, page and blog article — the one place in Shopify's admin that people reliably scroll past.

Hostinger's builder documents editable page titles and meta descriptions, and will change them if you ask the AI builder to in plain language, which is a genuinely pleasant way to do a boring job.

GoDaddy's builder is the one with a documented gap: reports from independent reviewers are consistent that titles and descriptions are editable on standard pages but not on blog pages. That claim is single-sourced enough that it deserves checking on your own site rather than taking on trust — but if it holds, it means the pages most likely to attract search traffic are the pages you cannot write a title for.

The pattern trap

Site-wide title patterns exist for catalogues. On a shop with two thousand products, a pattern that assembles Product name — Category — Shop name is the only sane way to produce two thousand titles, and it works.

On a nine-page site it produces nine titles with the same shape, the same site name eating a third of the available width, and differences confined to a single noun. Two of those pages are then near-identical in a result list, and a person scanning cannot tell which one answers their question. This is not a penalty of any kind. It is worse than that: it is a click you do not get.

The fix is the same everywhere. Leave the pattern in place for anything generated in bulk. Override it by hand on every page you actually care about — the homepage, the money page, the three or four articles that carry the site. That is twenty minutes of work on a small site and it is the highest-yield twenty minutes in this whole category.

How long should they be?

Length guidance for these fields has been quoted as a character count for twenty years, and the character count has always been an approximation of the real constraint, which is pixel width. A title of sixty narrow characters can fit where a title of fifty-five wide ones does not.

Practical working limits: keep titles to roughly sixty characters and put the distinguishing words first, so the sentence still makes sense if the end is cut. Keep descriptions to roughly 155 characters for the same reason. Neither number is a rule handed down by Google; both are the width at which truncation usually starts in desktop results, and truncation is not a penalty — it is just a sentence ending in an ellipsis.

The more useful discipline is front-loading. Whatever makes this page different from the other nine results goes in the first forty characters of the title, because that is the part that survives every truncation rule on every device.

The part nobody likes about descriptions

Google frequently does not use the description you wrote. It generates its own snippet from page content when it judges that a passage matches the query better than your description does — and on long-tail queries, which is most queries, it usually does judge that.

Two things follow, and they point in opposite directions, which is why this gets argued about.

Writing a description is still worth doing, because when it is used it is used verbatim, and because it is what gets pulled into link previews on social platforms and in chat apps that ignore Google entirely.

Writing eleven drafts of a description is not worth doing, because you are polishing a string that may never be displayed. The effort belongs in the title, which is used far more consistently, and in the page's opening paragraph, which is where an auto-generated snippet usually comes from.

That asymmetry is the practical takeaway: titles deserve real attention, descriptions deserve one honest pass, and the opening paragraph deserves to be written as though it might be quoted, because it might.

Duplicates are the failure mode that actually bites

Of everything in this category, duplicate titles across a site are the problem worth auditing for. They happen through patterns, through paginated archives, through product variants, and through the simple accident of two pages about similar things.

No builder in this set will tell you when it has happened. Search Console will, in its own indirect way, and a crawl of your own site will do it directly. On a small site you can do it by reading the list of pages and their titles in one sitting, which takes ten minutes and is the only audit in this article that requires no tooling at all.

Where each platform sits on the broader question of how much of this you are allowed to control is laid out in the seven-builder control audit. On titles and descriptions specifically, though, the honest summary is that almost every builder gives you what you need — and the difference between sites is not the tooling, it is whether anybody used it.