toolforge.ai
← Back to home

Audit

borednbuzzed.com

The one thing to read first: this site is a client-rendered React SPA

△
The server sends 1,272 bytes and one empty <div id="root">
Every word of visible content, every link, every image loads AFTER the browser downloads and runs /assets/index-CufQhBwR.js. That shapes almost every finding below.
  • The no-JS on-page crawl sees 0 links, 0 images, 0 words, no <h1> — because it never ran the JavaScript that builds the page. This is not a report that the page is empty; it is the known limit of the thin/no-JS plan requested. A real content audit needs a JS-rendering crawl (paid, costs more per page).
  • Lighthouse (PageSpeed Insights) DOES run real Chrome and DOES execute the JavaScript, so its speed numbers below are trustworthy for what a visitor actually sees.

Speed — Lighthouse / PageSpeed Insights (free API, real Chrome)

68Moderate
Performance — Mobile
97Good
Performance — Desktop

Largest Contentful Paint — the real problem

8.1sPoor
Mobile
0.7sGood
Desktop

First Contentful Paint

2.7sModerate
Mobile
0.7sGood
Desktop
Accessibility 100 / 100 Best Practices 100 / 100 Total Blocking Time 0 ms / 0 ms Cumulative Layout Shift 0 / 0 Page weight 1,257 KB Server response 0 ms (Vercel edge)

Mobile LCP is the one real speed problem, and it is not a server or bundle-size problem — the server answers in 0 ms and the page is only 1.2 MB total. The 8.1-second wait is the SPA pattern itself: on a throttled mobile connection, the visitor sees a blank page until the JS bundle downloads, parses, and React paints the content. Desktop does not show this because Lighthouse desktop assumes a fast connection.

Fix: prerender or server-render at least the above-the-fold hero (a static HTML shell Google and mobile visitors see immediately, before React hydrates) — this is a build change, not a hosting change, since Vercel itself responds instantly.

On-page scan — what happened, and what tripped

16Pages attempted
16Pages returned 200
0Broken (4xx/5xx)
0Redirects
92.32On-page score (all 16)
16Identical shells

Every one of the 16 known routes was crawled as its own thin, no-JavaScript page — not one homepage scan. All 16 returned HTTP 200. Zero were broken and zero redirected.

△
The real finding: all 16 pages are byte-identical
/about, /shop, /checkout, /blog/indica-vs-sativa, and every other route return the exact same 1,272-byte SPA shell as the homepage — same title, same meta description, same onpage_score: 92.32, same missing <h1>. The server sends one shell for every route with no per-page HTML; a crawler or link-preview bot that cannot run JavaScript sees 16 indistinguishable pages, not 16 distinct ones. Same root cause as the mobile LCP issue above — the fix is prerendering or SSR per route, not a hosting change.
  • Title (all 16 pages, pre-JS): “Bored ‘N Buzzed Cannabis — Kirkland, WA” (39 chars — fine on its own, but identical everywhere)
  • Meta description (all 16 pages, pre-JS): “Bored N Buzzed Cannabis — Premium cannabis dispensary in Kirkland, WA. Come bored. Get buzzed.” (94 chars)
  • No <meta name="robots"> conflicts, canonical present, HTTPS, valid HTML5 doctype, on every page
  • duplicate_tags check errored (API needs a type param on this account) — harmless; the identical-shell finding above already covers what that check would have flagged

Site health

  • ✗
    No sitemap.xml. Confirmed two ways: DataForSEO's own site-wide check (sitemap: false) and a direct fetch — /sitemap.xml returns HTTP 200 but the body is the React app shell, not a real sitemap.
  • ✗
    No robots.txt either. Same symptom — /robots.txt returns 200 with the SPA shell, not a robots file.
  • ✗
    No analytics at all. No Google Analytics, GTM, Meta/TikTok/Snapchat/Pinterest pixel, Hotjar, Klaviyo, Segment, Mixpanel, Amplitude, Matomo, HubSpot, Intercom, or Cloudflare RUM. Checked three ways: the live request list from a real Chrome page load, the raw HTML source, and the full text of all four JS bundles (index, vendor, motion, state) for every common tracker signature. Two string hits were false positives on inspection — “TikTok” is marketing copy, “gTag” is an internal JS toStringTag string, not Google's gtag.js. No visitor analytics of any kind, first-party or third-party.
  • ✓
    SSL valid — wildcard cert (*.borednbuzzed.com) from Let's Encrypt, expires 2026-09-18. Auto-renews if Vercel manages it (it almost certainly does).
  • ✓
    Redirects working — http:// → https:// (308) and bare borednbuzzed.com → www. (308) both correct, no duplicate-content risk.
  • ✓
    Hosting: Vercel — healthy — IP 216.198.79.1, HTTP/2, HSTS enabled (max-age=63072000), fast edge response (X-Vercel-Cache: HIT). No CMS detected.

Fonts in use

Six font families load across two paths — the HTML <head> link and a separate @import inside the compiled CSS bundle. Luckiest Guy is the site's primary display font, the default for every <h1>–<h6> and all three button styles.

Bored N Buzzed

Luckiest GuyPrimary display font — default for every h1–h6 and all buttons. Loaded via the CSS @import.

Bored N Buzzed

Bebas NeueThe font-display utility (fallback: Impact)

Bored N Buzzed

AntonThe font-heading utility (fallback: Impact)

Bored N Buzzed

DM SansBody font (font-body), weight 300–600, italic

Bored N Buzzed

JetBrains MonoLoaded via the same @import; used only for code/kbd/pre — not a visible design element here

Bored N Buzzed

ItalianaLoaded via the head link but zero font-family declarations anywhere in the built CSS — genuinely unused

← Back to home