Back to all checks

Text quality

Misplaced invisible marker in text — Shopify catalog

Finds a marker reserved for the start of text when it appears inside the value.

Needs your reviewAbout this check

What does misplaced bom inside catalog text check?

U+FEFF has been used as a byte order mark at the start of a stream; seeing it after text has begun is a different situation and should be reviewed as an internal invisible character.

File concatenation, repeated decoding, importing fragments that each carry their own BOM, or copying between systems can move the marker into the middle of a commercial value.

Unicode recommends U+2060 WORD JOINER for word-joining or no-break semantics, so an internal U+FEFF should not be retained merely by assuming it is a modern joiner.

Examples that require context

These are fictional educational examples. They illustrate situations where review is useful and do not represent real merchant data.

Example A — U+FEFF inside a value rather than at the start of a stream[correction candidate after review]

The case illustrates a possible pattern; verify start-of-stream BOM semantics, concatenation, and the distinction from U+2060 WORD JOINER before any change.

Example B — legitimate context for misplaced bom inside catalog textPreserve when intent is confirmed

The same class of character can have a legitimate role. U+FEFF has a special role at the start of some streams; internal U+FEFF must not be confused with a valid BOM. Unicode prefers U+2060 WORD JOINER for no-break semantics.

Example C — value without this findingPreserve the value

Absence of this issue does not prove overall text quality; other detectors remain independent.

01

What does PROVEN check?

Checks for a marker reserved for the beginning of text when it appears inside a value.

02

Why does it matter?

The misplaced marker is invisible and can introduce a storage difference without visible content.

Why can this matter for catalog maintenance?

The detector still does not determine provenance: U+FEFF alone does not prove database corruption, malware, a broken encoding, or a particular editor.

Exact position matters. A marker between two fragments may indicate a concatenation boundary, while the same code point at offset zero can belong to an external serialization convention.

Review should compare raw source, declared encoding, import pipeline, and visible text without inventing a character or separator that supposedly belonged at that location.

03

What can PROVEN do?

PROVEN can prepare removal of the marker from inside the text; the change requires your review.

How PROVEN handles the finding

The workflow preserves evidence and separates detection from the remediation decision to avoid speculative normalization.

  1. Locate the evidencePROVEN locates U+FEFF inside a value rather than at the start of a stream and preserves surrounding characters so the merchant can review position and effect.
  2. Check the semanticsThe merchant verifies start-of-stream BOM semantics, concatenation, and the distinction from U+2060 WORD JOINER. Context determines whether the finding is residue, a valid convention, or a case that should remain unchanged.
  3. Prepare the changeOnly after confirmation can PROVEN prepare a targeted edit. The proposal preserves unrelated text and remains reviewable before application.

What should be reviewed before application?

Removing an internal U+FEFF confirmed as residue is distinct from NFC normalization and distinct from handling U+FFFD; each issue keeps separate evidence.

For repeated findings, grouping by offset and data source can show whether the same internal BOM appears at an identical supplier-feed boundary.

After cleanup, re-export and code-point inspection can confirm that the marker is not being reintroduced by the same ETL stage or source file.

Limits and abstention cases

  • The page explains the standard and residue risk without turning U+FEFF into an automatic verdict about merchant data.
  • It does not ignore context: start-of-stream BOM semantics, concatenation, and the distinction from U+2060 WORD JOINER must be checked before remediation.
  • U+FEFF has a special role at the start of some streams; internal U+FEFF must not be confused with a valid BOM. Unicode prefers U+2060 WORD JOINER for no-break semantics.
  • The result should be interpreted in the context of the field and product; a finding is not an automatic verdict.
  • It does not invent copy, missing characters, data provenance, or merchant intent.
  • It does not guarantee SEO, ranking, traffic, or conversion benefits after remediation.

Frequently asked questions

Is misplaced bom inside catalog text always an error?

No. U+FEFF has a special role at the start of some streams; internal U+FEFF must not be confused with a valid BOM. Unicode prefers U+2060 WORD JOINER for no-break semantics. The finding identifies a review case, and the decision depends on field, language, format, and evidence.

Does PROVEN apply the change automatically?

Not from the finding alone. This check requires review, and the proposal must be checked before application.

Is this an official Shopify limit?

No. Shopify sources provide content-editing context; the exact criterion remains PROVEN detector-specific.

Why are Unicode sources used?

They provide context about text representation and processing and help interpret the finding.

Sources and independent context

The sources explain the relevant standard or content editor. They provide context for interpretation but do not by themselves show that a store has this finding.