---
title: "Your CMS Can Publish the Opposite of What Your Page Says"
description: "When a template cuts a title, the negation carrying the claim can go with it. A six-site audit of 2,068 pages found 166 summaries where exactly that happened."
canonical: https://authoritytech.io/blog/metadata-truncation-reverses-page-claim-2026
last-updated: 2026-09-26
---

# Your CMS Can Publish the Opposite of What Your Page Says

When a template cuts a title, the negation carrying the claim can go with it. A six-site audit of 2,068 pages found 166 summaries where exactly that happened.

Canonical URL: https://authoritytech.io/blog/metadata-truncation-reverses-page-claim-2026
Published: 2026-09-26
Author: Jaxon Parrott
Topic: Machine Relations

There is a failure mode in AI visibility that nobody on your team is looking for, because it does not happen in the engine. It happens in your own build, before a crawler arrives.

Your content management system enforces a character budget on the title and the meta description. When the claim on the page lives in a negation — *not*, *never*, *does not*, *nobody* — and the budget cuts the sentence in the middle, the negation is what gets deleted. What is left is grammatically complete and factually reversed. No ellipsis. Nothing to signal that anything was removed. The page argues one thing and the two fields a machine lifts most reliably argue the other.

We ran the test across the six sites we operate, 2,068 pages. It found 166 rendered page summaries where the negation carrying the claim had been deleted and 1,079 where the summary stops mid-clause with no ellipsis at all. The fixes for the harmful cases are live. The test itself is below, and it runs in under an hour on any site where you control the source.

## The character limit you are enforcing is not a rule

Start with the part that changes the decision, because most teams have this backwards.

Google's documentation is explicit on both fields. On the title: "While there's no limit on how long a `<title>` element can be, the title link is truncated in Google Search results as needed, typically to fit the device width" — [Influencing title links in Google Search](https://developers.google.com/search/docs/appearance/title-link). On the description: "There's no limit on how long a meta description can be, but the snippet is truncated in Google Search results as needed, typically to fit the device width" — [How to write meta descriptions](https://developers.google.com/search/docs/appearance/snippet). The [HTML specification](https://html.spec.whatwg.org/multipage/semantics.html#the-title-element) sets no length either, and neither does the [meta name reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name). [Bing's guidelines](https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a) ask for descriptive titles and accurate descriptions, not short ones.

So the 60-character title and the 160-character description are display conventions. They describe how much of your string a search result shows on a phone. They are not requirements, and there is no penalty for exceeding them.

Now look at what your template does with that convention. It applies it to the source. The string that goes into the HTML is the cut one. Which means the cut is not scoped to one search result on one device — it is scoped to every consumer of that page:

- The `<title>` element every crawler reads.
- The `<meta name="description">` tag, which Google says it will sometimes use verbatim as the snippet.
- The Open Graph `og:title` and `og:description` that produce every link preview in Slack, LinkedIn and iMessage — the [Open Graph protocol](https://ogp.me/) has no length limit either.
- The [schema.org `description`](https://schema.org/description) property in your structured data.
- The string an LLM fetcher sees. [OpenAI's crawlers](https://platform.openai.com/docs/bots) and [Perplexity's](https://docs.perplexity.ai/guides/search-best-practices) read the page as published.

To avoid a cosmetic truncation on one surface, the template performs a real truncation on all of them. That trade would be questionable if the cut were merely unflattering. It is worse than that.

## What the cut does to a negation

A word-boundary trim removes text from the end of a sentence. The claim in a well-written title is often carried by a single word near the end, and a large share of the time that word is a negation.

The shape is always the same:

- `Press Releases Do Not Earn AI Citations` → cut → `Press Releases Do Not Earn` → cut again → `Press Releases Do`
- `Why Dashboards Are Not an AI Visibility Strategy` → cut → `Why Dashboards Are`
- `Your Blog Posts Go Stale in AI Search. Your Research Reports Do Not` → cut → `Your Blog Posts Go Stale in AI Search. Your Research Reports`

Read that last one as a machine would. It says research reports go stale. The page says the opposite, and says it in the sentence the cut removed.

The audit found the same mechanism on the description side. One page of ours argued that the widely quoted AI-traffic conversion multiple is the wrong signal to manage and that brand mentions are the real one. Its rendered description, complete and with no ellipsis, read: "A new multi-source analysis of 680 million AI citations confirmed what founders should have acted on a year ago: AI traffic converts at 5.1x Google organic." The setup survived. The correction did not. That is a page arguing against a number while publishing a summary that endorses it, and it was live until we caught it. It is fixed.

There is a reason this class deserves more concern than an ordinary typo: the readers most affected are already weak here. Negation is a documented failure point in language models, not a speculation. "Language models are not naysayers" found insensitivity to negation, no grasp of its lexical semantics, and an inverse scaling trend where larger models did worse — [Truong et al., 2023](https://aclanthology.org/2023.starsem-1.10/). A 380,000-sentence benchmark found models proficient on affirmative sentences and reliant on superficial cues under negation — [This is not a Dataset](https://arxiv.org/abs/2310.15941). Follow-up work across four languages reported the same difficulty with premise length and explicitness as factors — [Negation: A Pink Elephant in the Large Language Models' Room?](https://arxiv.org/abs/2503.22395) — and the multimodal case is starker still, with joint embedding models performing near chance on negated queries — [Vision-Language Models Do Not Understand Negation](https://openaccess.thecvf.com/content/CVPR2025/papers/Alhamoud_Vision-Language_Models_Do_Not_Understand_Negation_CVPR_2025_paper.pdf).

Put the two together. A template that deletes the negation is handing a negation-weak reader a sentence with the hard part already removed — and removed in a way that leaves no trace. The model is not misreading your page. It is reading a different page, correctly.

## The measurement, and why you cannot buy it from a third party

This defect is only visible where you own the source. It is defined by the difference between the string a writer wrote and the string the template rendered. An external crawler, an SEO platform, a competitor — all of them see the rendered side only. A 58-character title looks like a short title. Nothing about it says a negation used to be there.

So we ran it on our own corpus, at the current commit of each repository, on 26 September 2026. The method is the part worth copying: import each site's real metadata function and execute it over every source string in the content tree. Do not approximate with a length bucket. We tried that first and it was wrong twice, because these helpers have clause rules, brand suffixes and trailing-word strippers that make the cut point unpredictable from length alone.

Six sites, 2,068 content pages. Five of the six bound the description; one does not bound it at all.

| Measure | Count |
| --- | --- |
| Pages scanned | 2,068 |
| Rendered descriptions that differ from their source | 1,544 |
| Of those, ending mid-clause with no ellipsis | 1,079 |
| Rendered descriptions that drop a negation | 166 |
| Of those, leaving a survivor that reads as a complete sentence | 6 |
| Of those, asserting the opposite of the page | 1 |
| Rendered titles that drop a negation | 107 |
| Of those, losing it to a mid-clause cut | 49 |

The 49 titles are fixed and live. The one reversed description is fixed and live. And the shape of that table is the finding, because it is not what we expected when we started.

1,544 cut descriptions looks like a thousand-page emergency. It is not. Falsity is rare: one page in 2,068 actually asserted the opposite of itself. What is common is silence — 1,079 page summaries that stop mid-clause, so the field an answer engine lifts is a fragment rather than a summary. A fragment is a worse source than a short sentence, and it is entirely self-inflicted.

The distribution across sites matters more than the total. On one site, 1,056 of 1,112 cuts emit no ellipsis, because the helper strips trailing connectors after cutting and so never signals the cut. Three of the six sites end every cut with an ellipsis, which is visible truncation and costs little. One site cuts 88 descriptions while only 16 of its source descriptions exceed 160 characters, because its own budget is tighter than the field it is fed. Same convention, six implementations, wildly different damage.

## Run the test on your own site

This is a one-hour job for anyone with repository access, and it does not need a crawl.

1. **Find the function, not the limit.** Search your codebase for the metadata builder — in a Next.js app it feeds [`generateMetadata`](https://nextjs.org/docs/app/api-reference/functions/generate-metadata); in most others it is a helper named for SEO or metadata. Read it. Note the budget, whether there is a clause rule, whether a brand suffix is counted, whether it appends an ellipsis, and whether anything strips trailing words after the cut.
2. **Check how the budget is measured.** One of ours measures the HTML-serialized length, so an apostrophe costs six characters rather than one. A title with three apostrophes has a real budget of 45, not 60. Ten replacement titles we had verified by eye were cut anyway for this reason.
3. **Execute the function over every source string.** Import it and run it. Keep every case where the output differs from the input.
4. **Diff the two strings and inspect what was dropped.** For each difference, isolate the removed text and test it for negation markers: *not, never, no, nobody, none, nothing, cannot, without, fails, rarely, neither, nor, unless*. Keep the cases where the dropped text contains one and the surviving text does not.
5. **Sort that set by whether the survivor reads as a complete sentence.** A survivor ending mid-clause is visibly unfinished. A survivor ending in a period, with the negation gone, is the dangerous one. That subset is small and you should read every member of it by hand.
6. **Fix the reversals. Leave the rest.**

Step six is a judgment, so here is ours, stated as a rule. Fix a field only where the rendered string asserts something the page denies. Do not rewrite a description that merely lost a framing clause and remains true: the existing string is what engines have been indexing, and spending it to gain a few characters of nuance is a bad trade. Of our 107 negation-losing titles, 49 were reversals and got fixed, and 58 lost the negation at a clean clause boundary and produce a shorter true title. Those 58 are deliberately untouched.

And if your count of cut fields runs into the thousands, that is an argument for fixing the template, not for a thousand-page content edit. A bounded-metadata helper that can silently emit a mid-clause fragment should either fit the field or refuse the build. That is a two-day engineering change that prevents the class. Hand-editing the output is a permanent tax that does not.

## Why this belongs in an AI visibility program rather than a technical backlog

The standard advice about title tags treats them as a click-through-rate lever. That framing is now out of date, for a measurable reason: when an AI summary appears, users click links far less often. [Pew Research Center](https://www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/) found users clicked a result on 8% of visits with an AI summary present against 15% without.

If fewer people click, the value of those two fields shifts from persuading a human to click toward informing a machine that is answering without the click. They stop being ad copy and become the most load-bearing summary of your position that you publish. A reversed one is not a missed click. It is a machine-readable statement, in your own voice, on your own domain, that contradicts you.

That is why this sits inside Machine Relations rather than in a technical SEO queue. The discipline is about what machines can find, read and repeat about you, and the first requirement is that the sources you control say what you mean. Distributed evidence in publications engines already trust is how a brand becomes citable; the [Machine Relations Index](https://machinerelations.ai/index.md) measures which sources those are across [22,000-plus domains](https://machinerelations.ai/research). The Index does not reach this question — it measures which domains get cited, not what a template did to their metadata — so the evidence here is the six-site helper audit and nothing else.

Both layers are the same discipline. Get cited by sources machines trust, and make sure the page they land on does not argue against you in the first sentence they read.

If you want to know how AI engines currently describe your company, [run the visibility audit](https://app.authoritytech.io/visibility-audit). If the description comes back subtly wrong, check your own template before you blame the model.

## Frequently asked questions

**Is there actually a character limit on a title tag or meta description?**
Not one that engines impose. [Google's title documentation](https://developers.google.com/search/docs/appearance/title-link) describes the length of a `<title>` element as unbounded and says the title link is "truncated in Google Search results as needed, typically to fit the device width"; [its snippet documentation](https://developers.google.com/search/docs/appearance/snippet) says the same of the meta description. The 60 and 160-character figures are display conventions. Truncating the source string applies a display convention to every consumer of the page, including crawlers, link previews and structured data.

**How would I know if this is happening on my site?**
Import your own metadata helper, run it over every source title and description, and keep the cases where the output differs from the input. Then isolate the dropped text and test it for negation words. The cases where the dropped text contains a negation and the surviving text does not are the ones to read by hand. It does not require a crawl, because the comparison is between your source and your own render.

**Should I rewrite every truncated description?**
No. In our audit, 1,544 descriptions were cut and one asserted the opposite of its page. Fix reversals. Leave a description that lost only a framing clause and remains true, because the existing string is what engines have been indexing. A large cut count is an argument for fixing the helper so it stops emitting mid-clause fragments.

**Does this affect AI answers or only Google search results?**
Both, and the AI side is harder to detect. The truncated string is in the published HTML, so every crawler and LLM fetcher reads the truncated version. Language models are also documented to handle negation poorly, so a summary with the negation deleted is being read by systems that would have struggled with the negation even if it had survived.

**Why does the title on this page fit?**
Because we wrote it to the budget the template enforces and then checked the rendered output before publishing, which is the cheap half of the fix. The expensive half is the template change that would make the check unnecessary.

## Links

- [Blog Index](https://authoritytech.io/blog.md)
- [Home](https://authoritytech.io/index.md)