Lionel Pairuna
←  back

isset()  ·  every page, ×3 languages

A falsy trap on every <title>

isset() returns true for a value of false. A location suffix meant for a few page types rendered on all of them, in every language.

Two lines, two bugs
$prms = ['home' => false, /* ... */];

if (isset($prms['home'])) {          // true even though home === false
    $title .= ' | ' . SITE_NAME . ' | ' . LANG_UBICATION;
}

$id = BASE_URL . '/' . $path;         // BASE_URL already ends in '/'  → "...//..."

Context

A client asked to remove the location suffix —  | Company Name | Province, Country — from the <title> of the informational pages (news, crypto), keeping location targeting only on the pages that sell services. Acting on that request surfaced a bug that had been adding the suffix to 100% of pages, in every language.

The problem

1. isset() treats false as “set.” The suffix was appended inside if (isset($prms['home']) || …). Every content module passes 'home' => false, and isset() returns true for a value of false — only null counts as unset. So the suffix rendered on every page, not only the ones meant to have it.

2. Double slash in 5 JSON-LD @id values. Built as BASE_URL . '/#…', but BASE_URL already ends in /, producing https://site//#organization. Search Console flagged it in the Breadcrumbs report: “Invalid URL in field 'id'” — 22 items.

The fix

  1. Replaced the broken isset() gate with an explicit flag:
if ($prms['title_ubicacion'] ?? true) { … }

Defaults to true, so home, portfolio and servicios keep the suffix with no regression. noticiasUI and cryptosUI pass 'title_ubicacion' => false per the client request.

  1. Removed the redundant / literal from the 5 @id concatenations: BASE_URL . '/#x'BASE_URL . '#x'.

Result

Verified now, in production:

  • home / portfolio / services: <title> with suffix — no regression
  • news / crypto: <title> without suffix
  • JSON-LD: @id values with no double slash; valid in the Rich Results Test; Breadcrumbs validation now shows “Looks good”
Search Console, recrawl pending (~2–4 weeks): “Invalid URL in field 'id'” in the Breadcrumbs report, 22 → expected 0. Before-and-after screenshots available on request.

What this shows

  • Spotting a falsy-value PHP bug with a site-wide SEO consequence
  • Fixing it without breaking existing behaviour — safe-default flags
  • Correct URL construction in structured data
  • Verification across three layers: rendered HTML, Rich Results Test, Search Console

Contact

Something similar in your Search Console? Tell me what's stuck — a screenshot or a single URL is enough to start.

lionel@lionelpairuna.dev