The latest articles on DEV Community by Cody Wang (@amazong110). https://dev.to/amazong110 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4139050%2F9d60ef5c-4ccd-4154-876e-9f056d978f9a.jpg https://dev.to/amazong110 en Cody Wang Tue, 13 Oct 2026 06:09:05 +0000 https://dev.to/amazong110/what-is-this-site-actually-built-with-three-checks-and-13-signals-h6g https://dev.to/amazong110/what-is-this-site-actually-built-with-three-checks-and-13-signals-h6g <h1> What is this site actually built with? Three checks and 13 signals </h1> <p>When you inherit a site — or want to change your own — the first thing you need is not the code. It's <strong>what the thing is built with</strong>.</p> <p>Because the stack decides what is possible afterwards.</p> <ul> <li> <strong>Whether you can change it at all.</strong> A WordPress site's heading font might live in one theme setting. On Webflow you may not even get the HTML. A headless CMS means editing a content model.</li> <li> <strong>Whether the images can be saved.</strong> WordPress serves from <code>/wp-content/uploads/</code>, Shopify from <code>cdn.shopify.com</code>, Prismic from <code>images.prismic.io</code> — and each pipeline takes a different set of transform parameters. Miss the pipeline and you don't know what to tune.</li> <li> <strong>Cache and render strategy.</strong> Headless leans on CDN caching for API JSON and an HTML shell; classic PHP leans on full-page and object caches; hosted builders give you the fewest knobs.</li> <li> <strong>Whether you can touch the code.</strong> Some platforms give you a panel. Some give you everything.</li> </ul> <p>In one line: <strong>identify the platform first, then optimise.</strong> The other order wastes your time.</p> <h2> Three checks </h2> <h3> Check 1: View source, then search it </h3> <p>Open the page → <code>Ctrl+U</code> (<code>Cmd+Option+U</code> on Mac) → search the HTML for the vendor name you suspect.</p> <p><strong>The distinction that matters:</strong> if the name only shows up in body copy or a comment, it proves nothing. What counts is the name appearing inside a <code>src</code>, <code>href</code> or <code>data-</code> attribute — that is a resource the browser was <strong>told to load</strong>.</p> <p>A concrete example: you search for <code>prismic</code> and find it inside a <code>&lt;p&gt;</code> tag. That site may just have published an article about Prismic. But if it appears in <code>src="https://images.prismic.io/..."</code>, that is hard evidence.</p> <p>So the question is never "is this word here" — it is <strong>where the word appears</strong>.</p> <h3> Check 2: Read the response headers, especially the cookies </h3> <p>Open dev tools → Network → reload → click the first document request. Look at:</p> <ul> <li> <code>x-powered-by</code>, <code>x-generator</code>, <code>server</code> </li> <li> <strong>the names inside <code>set-cookie</code></strong> — the most valuable of the lot</li> </ul> <p>Why are cookies stronger than meta tags? Because <strong>meta tags are written by a human, cookies are issued by the platform</strong>. A cookie called <code>wp-settings-1</code> or <code>_shopify_s</code> is the platform introducing itself.</p> <p>⚠️ One trap: <strong>CDNs strip headers.</strong> Put Cloudflare or Vercel in front and a lot of the original headers are simply gone. So "I don't see it" is <strong>not</strong> the same as "it isn't there". It's one vote, not a verdict.</p> <h3> Check 3: Compare against a site you already know </h3> <p>The same platform leaves <strong>the same shape</strong> on every site that runs it: the same asset host, the same path prefixes, the same admin endpoints.</p> <p>That is the whole reason CMS detection works at all — not guessing, but shape matching.</p> <ul> <li>A single keyword → maybe a false positive</li> <li>Keyword + matching host + matching path → that is confirmation</li> </ul> <h2> 13 signals worth memorising </h2> <ul> <li> <strong>WordPress</strong>: <code>/wp-content/</code>, <code>/wp-includes/</code>, <code>/wp-json/</code>, the <code>wp-emoji-release</code> script, <code>wp-*</code> cookies</li> <li> <strong>Shopify</strong>: <code>cdn.shopify.com</code>, <code>cdn.shopifycdn.com</code>, <code>/cdn/shop/</code>, <code>Shopify.theme</code> in page scripts</li> <li> <strong>Wix</strong>: <code>static.wixstatic.com</code>, <code>static.parastorage.com</code>, the inline viewer model JSON</li> <li> <strong>Squarespace</strong>: <code>static1.squarespace.com</code>, <code>Static.SQUARESPACE_CONTEXT</code> </li> <li> <strong>Webflow</strong>: <code>website-files.com</code>, <code>website-images-assets.com</code>, <code>data-wf-*</code> on <code>&lt;html&gt;</code> </li> <li> <strong>Prismic</strong>: <code>images.prismic.io</code>, <code>/prismic-assets/</code>, slice markers, <code>prismic-toolbar</code> </li> <li> <strong>Contentful</strong>: <code>images.ctfassets.net</code>, <code>assets.ctfassets.net</code> </li> <li> <strong>Sanity</strong>: <code>cdn.sanity.io</code>, the project id referenced in page scripts</li> <li> <strong>Ghost</strong>: <code>/ghost/</code>, <code>/content/</code> paths, <code>ghost-*</code> meta tags, the Ghost admin SDK</li> <li> <strong>Drupal</strong>: <code>/sites/default/files/</code>, <code>drupalSettings</code>, the <code>X-Generator</code> response header</li> <li> <strong>Joomla</strong>: <code>/media/jui/</code>, <code>/media/system/</code>, <code>/components/com_</code> </li> <li> <strong>Craft CMS</strong>: the <code>CRAFT_CSRF_TOKEN</code> cookie, <code>/cpresources/</code> </li> <li> <strong>Strapi</strong>: a <code>/uploads/</code> path together with an <code>api.</code> host or <code>/api/</code> JSON endpoints</li> </ul> <h2> A real example </h2> <p>Let's practise on a site everyone knows: the TechCrunch homepage.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fk1qkjomsrdvb46w0z8kr.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fk1qkjomsrdvb46w0z8kr.png" alt="TechCrunch homepage source, with the WordPress-only paths visible" width="800" height="225"></a></p> <p><strong>In the source</strong>, these two lines are decisive:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"https://api.w.org/"</span> <span class="na">href=</span><span class="s">"https://techcrunch.com/wp-json/"</span> <span class="nt">/&gt;</span> <span class="nt">&lt;script </span><span class="na">src=</span><span class="s">"https://techcrunch.com/wp-includes/js/dist/i18n.min.js?ver=..."</span> <span class="na">id=</span><span class="s">"wp-i18n-js"</span><span class="nt">&gt;&lt;/script&gt;</span> </code></pre> </div> <p><code>/wp-json/</code> and <code>/wp-includes/</code> are WordPress-only paths, and they sit inside <code>href</code> and <code>src</code> — the browser genuinely loads them.</p> <p><strong>In the response headers</strong> it is even more direct:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight http"><code><span class="err">x-powered-by: WordPress VIP &lt;https://wpvip.com&gt; link: &lt;https://techcrunch.com/wp-json/&gt;; rel="https://api.w.org/" server: cloudflare </span></code></pre> </div> <p><code>x-powered-by</code> names the platform outright, and the <code>link</code> header hands you the REST API address.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftjyymonkjd8htkyl5p2j.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Ftjyymonkjd8htkyl5p2j.png" alt="The same page's response headers, with x-powered-by naming WordPress VIP" width="800" height="318"></a></p> <p>Note that last line: <code>server</code> is <strong>cloudflare</strong>, not the origin. That is the "CDNs strip headers" problem in the wild — with a CDN in front, you see one layer less.</p> <p><a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F0yikyhnh1x3mmymdkjgs.png" class="article-body-image-wrapper"><img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F0yikyhnh1x3mmymdkjgs.png" alt="The audit tool listing every hit with its evidence" width="800" height="906"></a></p> <h2> The two most common mistakes </h2> <p><strong>Mistake one: finding the brand name in body copy and calling it done.</strong></p> <p>Documentation sites, comparison posts and job ads list several vendors at once. None of that is proof of an install.</p> <p><strong>Mistake two: concluding from a single signal.</strong></p> <p>Plenty of sites sit behind Cloudflare. Cloudflare is a CDN — it says nothing about which CMS runs underneath.</p> <p><strong>The right approach</strong> is to read the signals in layers:</p> <ul> <li>Vendor-specific hosts (strong) &gt; path prefixes (strong) &gt; cookies (strong)</li> <li>Response headers (medium — CDNs strip them)</li> <li>Brand strings in page copy (weak)</li> </ul> <h2> If you'd rather not check by hand </h2> <p>Paste the URL into <strong><a href="https://prismicaudit.com/tools/cms-checker?from=devto" rel="noopener noreferrer">prismicaudit.com/tools/cms-checker</a></strong>. It runs 100+ detectors across CMS, frameworks, hosting, CDN and third-party scripts, and <strong>lists the raw evidence behind every hit</strong> — not just a yes/no.</p> <p>I care about giving evidence rather than verdicts, because <strong>you should be able to check the answer yourself</strong>.</p> <p><em>The checks described here work on any site. Vendor names are used only to describe identification fingerprints; this tool is not affiliated with any of them.</em></p> webdev cms seo tooling Cody Wang Sun, 04 Oct 2026 09:01:03 +0000 https://dev.to/amazong110/ai-can-generate-a-shopify-section-that-looks-fine-not-one-you-can-edit-4fde https://dev.to/amazong110/ai-can-generate-a-shopify-section-that-looks-fine-not-one-you-can-edit-4fde <p>A theme I was reviewing had a section that would not move. You could pick it up in the theme editor, drag it, and it would return to its original position. Nothing in the console, no error in the editor. The section rendered correctly on the storefront.</p> <p>The cause was one attribute. The section had <code>id="hero-1"</code> in its markup instead of <code>{{ section.id }}</code>. Shopify uses that value to tell one section instance from another, so two instances of the same section had the same ID, and the editor could not keep track of which one you were dragging. Replacing the hardcoded value with <code>{{ section.id }}</code> fixed it.</p> <p>That theme came from an AI tool. The four issues below are the ones I keep finding in themes built this way. Two of them show up as bugs in the editor, two of them show up months later.</p> <h2> 1. Hardcoded IDs in the section markup </h2> <p>Liquid sections need <code>{{ section.id }}</code> for their identity. A hardcoded value works while there is only one instance of the section on the page. Add a second one, or duplicate the section into a template twice, and both render with the same ID. The storefront still looks right. The editor stops behaving predictably.</p> <h2> 2. Missing presets </h2> <p>Sections that merchants should be able to add need a <code>presets</code> array in the schema. Without it, the section renders wherever it is already placed in a template, so it passes a visual check. It never appears in the Add section menu.</p> <p>The same applies to <code>{{ block.shopify_attributes }}</code>. Without it on a block, the block renders but cannot be selected in the editor, so merchants cannot change its settings or reorder it.</p> <p>Both of these only appear when someone tries to edit the theme. That is why they survive a review, a screenshot check, and a demo.</p> <h2> 3. CSS inside the section markup </h2> <p>Many generated sections include a <code>&lt;style&gt;</code> block in the section itself. This works, and it has two costs. The rules reload on every page where the section appears, and when two sections define the same selector, the result depends on load order rather than on which file owns the style. Shopify's <code>{% stylesheet %}</code> tag handles this: one request, deduplicated, scoped to the section.</p> <p>The same pattern shows up in responsive rules. Generated sections often contain the desktop layout and skip the breakpoint at 750px, so the section tests clean at 1440px and breaks on a phone. For a store where most sessions are mobile, that is the layout that matters most.</p> <h2> 4. Code that disappears on theme update </h2> <p>When a theme update is published, Shopify keeps the merchant's settings and template edits and leaves custom code alone. Code that sits outside the theme's own structure can be missing from the new version. This is the expensive one, because the merchant ends up with a feature that has no readable source and no one who remembers how it was built.</p> <h2> What Shopify says about this </h2> <p>Shopify's theme support page lists AI-generated theme blocks among the customizations its support team will not troubleshoot. That means the merchant has no support path if the person who wrote the code is unavailable.</p> <p>The requirements for listing a theme in the Shopify Theme Store set a higher bar than "it renders":</p> <ul> <li>Average Lighthouse performance of at least 60 and accessibility of at least 90, measured on the home, product, and collection pages, on desktop and mobile, with real content in the sections.</li> <li>Original code. Themes derived from Dawn or Horizon are not eligible as new submissions.</li> <li>No fake urgency components such as countdown timers or low-stock counters.</li> </ul> <p>Those requirements apply to the official store. Themes sold elsewhere are not reviewed against them.</p> <h2> A five-minute check for any theme </h2> <ol> <li>Open the theme editor on a page that has your sections and try to move one to a different position.</li> <li>Check whether the section appears in the Add section menu.</li> <li>Open the store on a phone, add a product to the cart, and complete the flow to the cart page.</li> <li>Press Tab through the page and confirm you can see where focus is.</li> </ol> <p>If the section does not move, does not appear in the menu, breaks on mobile, or the focus indicator is missing, the theme needs work before a merchant can rely on it.</p> <h2> How I build sections </h2> <p>I built <a href="https://prismicaudit.com/pet-field-guide" rel="noopener noreferrer">a theme for pet stores</a> with 44 sections and 20 page templates. Each section uses <code>{{ section.id }}</code>, ships with presets, includes <code>{{ block.shopify_attributes }}</code> on its blocks, and keeps its CSS in a stylesheet tag.</p> <p>Before release I loaded the home, collection, and product pages at six widths from 375px to 1440px and checked for horizontal overflow, broken images, dead links, and keyboard traps. No horizontal overflow at any width. Touch targets measured at 24x24 or larger to meet the WCAG 2.5.8 minimum, which required resizing six link styles that were initially smaller.</p> <p>None of that is visible in a screenshot. It shows up when the merchant changes the store themselves.</p> shopify webdev ecommerce a11y Cody Wang Wed, 30 Sep 2026 02:55:00 +0000 https://dev.to/amazong110/hreflang-said-english-canonical-said-chinese-google-believed-the-canonical-10d3 https://dev.to/amazong110/hreflang-said-english-canonical-said-chinese-google-believed-the-canonical-10d3 <p>I'm Cody Wang. I build and optimise Prismic, SvelteKit and Next.js sites, mostly for clients in New Zealand and for Chinese brands going international.</p> <p>Last week I put a small SEO audit tool online. Most of the week went into the unglamorous half of launching: making sure search engines could actually read what I'd built. I found one bug that had quietly removed half the site from the index, and it took me three days to spot because every single page looked fine on its own.</p> <h2> What the site is </h2> <p>It's a detector. You paste a URL, it tells you what the site is built with and lists the fixable problems.</p> <p>Two languages, one URL, language in a query parameter:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code>/tools/cloudflare Chinese (default) /tools/cloudflare?lang=en English </code></pre> </div> <p>66 URLs, all server rendered. The content is in the HTML, no JavaScript required.</p> <h2> What I was telling Google </h2> <p>Here's the head of the English page for the Cloudflare detector:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;html</span> <span class="na">lang=</span><span class="s">"en"</span><span class="nt">&gt;</span> <span class="nt">&lt;title&gt;</span>Cloudflare Detector — check if a website uses Cloudflare<span class="nt">&lt;/title&gt;</span> <span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"canonical"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare"</span><span class="nt">&gt;</span> <span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"alternate"</span> <span class="na">hreflang=</span><span class="s">"zh-Hans"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare?lang=zh"</span><span class="nt">&gt;</span> <span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"alternate"</span> <span class="na">hreflang=</span><span class="s">"en"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare?lang=en"</span><span class="nt">&gt;</span> <span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"alternate"</span> <span class="na">hreflang=</span><span class="s">"x-default"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare"</span><span class="nt">&gt;</span> </code></pre> </div> <p>Look at the canonical. The English page is declaring that its real URL is the Chinese one.</p> <p>So I was saying two contradictory things on the same page. hreflang says the English version lives at <code>?lang=en</code>. The canonical says the canonical version lives at the bare URL, which serves Chinese. When those two disagree, Google follows the canonical. The English page becomes a duplicate of the Chinese page, and 1,600 words of English copy I wrote for English searchers gets folded into a page in a language those searchers can't read.</p> <p>The cause was dull. My head builder took <code>lang</code> as its first argument and used it for the <code>&lt;html&gt;</code> attribute, the title, the description, the structured data, the font stack. Then it built the canonical out of the path alone, because that line was written before the language switching existed and nobody updated it when the language switching arrived. One argument that got passed in and never used, on every page of the site.</p> <h2> How I noticed </h2> <p>Not from a dashboard alert. There isn't one for this.</p> <p>Search Console showed 199 impressions and 8 clicks across four weeks. Four of the five pages that earned a click were <code>?lang=en</code> URLs. The Chinese pages, which were the canonical targets, were picking up scraps.</p> <p>That's the tell. Almost everything getting impressions was something I'd told Google to ignore.</p> <p>You can check this on your own site faster with curl than with any tool:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code>curl <span class="nt">-s</span> <span class="s2">"https://prismicaudit.com/tools/cloudflare?lang=en"</span> <span class="se">\</span> | <span class="nb">grep</span> <span class="nt">-o</span> <span class="s1">'&lt;link rel="canonical"[^&gt;]*&gt;'</span> </code></pre> </div> <p>If the canonical that comes back has no <code>lang</code> in it while the page itself is in English, you have the same problem.</p> <h2> The fix </h2> <p>Each language version gets a canonical pointing at itself:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"canonical"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare"</span><span class="nt">&gt;</span> <span class="c">&lt;!-- zh --&gt;</span> <span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"canonical"</span> <span class="na">href=</span><span class="s">"https://prismicaudit.com/tools/cloudflare?lang=en"</span><span class="nt">&gt;</span> <span class="c">&lt;!-- en --&gt;</span> </code></pre> </div> <p>The hreflang block stays, except <code>x-default</code> now points at the English version. That one is a judgement call and not a rule. <code>x-default</code> is the page you show when no language matches, so it should be the version your audience actually searches in. Mine is English, so that's where it points. On a site aimed at the Chinese market I'd point it the other way.</p> <p>The sitemap needed the same treatment. It was emitting one <code>&lt;loc&gt;</code> per path with three alternates, which never put the English URL in the sitemap at all. Now each language gets its own entry, so 66 URLs became 132.</p> <h2> Verifying it </h2> <p>I don't trust "looks right." I wrote a loop that walks every URL in the sitemap and checks the canonical on the English version:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight shell"><code><span class="nv">U</span><span class="o">=</span><span class="s2">"https://prismicaudit.com"</span> curl <span class="nt">-s</span> <span class="s2">"</span><span class="nv">$U</span><span class="s2">/sitemap.xml"</span> | <span class="nb">grep</span> <span class="nt">-o</span> <span class="s1">'&lt;loc&gt;[^&lt;]*&lt;/loc&gt;'</span> <span class="se">\</span> | <span class="nb">sed</span> <span class="nt">-e</span> <span class="s1">'s/&lt;loc&gt;//'</span> <span class="nt">-e</span> <span class="s1">'s/&lt;\/loc&gt;//'</span> | <span class="nb">grep</span> <span class="nt">-v</span> <span class="s1">'lang=en'</span> | <span class="nb">sed</span> <span class="s2">"s#^</span><span class="nv">$U</span><span class="s2">##"</span> <span class="o">&gt;</span> /tmp/paths.txt <span class="k">while </span><span class="nb">read</span> <span class="nt">-r</span> p<span class="p">;</span> <span class="k">do </span><span class="nv">got</span><span class="o">=</span><span class="si">$(</span>curl <span class="nt">-s</span> <span class="s2">"</span><span class="nv">$U$p</span><span class="s2">?lang=en"</span> | <span class="nb">grep</span> <span class="nt">-o</span> <span class="s1">'rel="canonical" href="[^"]*"'</span> | <span class="nb">head</span> <span class="nt">-1</span><span class="si">)</span> <span class="o">[</span> <span class="s2">"</span><span class="nv">$got</span><span class="s2">"</span> <span class="o">=</span> <span class="s2">"rel=</span><span class="se">\"</span><span class="s2">canonical</span><span class="se">\"</span><span class="s2"> href=</span><span class="se">\"</span><span class="nv">$U$p</span><span class="s2">?lang=en</span><span class="se">\"</span><span class="s2">"</span> <span class="o">]</span> <span class="o">||</span> <span class="nb">echo</span> <span class="s2">"FAIL </span><span class="nv">$p</span><span class="s2"> -&gt; </span><span class="nv">$got</span><span class="s2">"</span> <span class="k">done</span> &lt; /tmp/paths.txt </code></pre> </div> <p>66 paths, 66 passes, no output. Mobile Lighthouse on a detector page still reads 100 for performance, accessibility, best practices and SEO. The fix didn't cost anything measurable.</p> <h2> What I got wrong while fixing it </h2> <p>The homepage had its own head builder, separate from the page template, so the same bug needed fixing twice. I patched the homepage by running a regex over the already-rendered HTML instead of fixing the template that produced it.</p> <p>It passes every check I have. It's also fragile in a way I'll pay for later: if the order of those three link tags ever changes, the regex matches nothing, silently, and the bug comes back with no error anywhere. I left a note in the file. Next time I touch that template it goes in the template.</p> <p>Two head builders and one regex. The actual lesson wasn't about hreflang.</p> <h2> What I still don't know </h2> <p>Whether it worked.</p> <p>Canonical and hreflang are hints for crawlers. I've changed the hints. Now Google has to come back, re-crawl 132 URLs, and re-evaluate which page is the real one. That takes days to weeks, and until it does, both versions are in a weird state where the signals contradict what Google last saw.</p> <p>So I'm in the waiting part. Nothing to design, nothing to ship, just checking Search Console every few days to see whether the English URLs start collecting impressions the way they should have been all along.</p> <p>If you run a multilingual site, the curl loop takes ten minutes. Nothing in a Lighthouse report will ever show you this one.</p> webdev seo html beginners Cody Wang Wed, 23 Sep 2026 08:45:20 +0000 https://dev.to/amazong110/six-things-that-keep-a-site-off-a-perfect-lighthouse-score-3ecg https://dev.to/amazong110/six-things-that-keep-a-site-off-a-perfect-lighthouse-score-3ecg <p>I'm Cody Wang. I build and optimise Prismic, SvelteKit and Next.js sites, mostly for clients in New Zealand and for Chinese brands going international.</p> <p>These six things are ones I've fixed myself, more than once. No theory dump. Just what it looked like, what I assumed at first, what I actually changed, and where the official docs are.</p> <h2> 1. Images: alt text, dimensions, file size </h2> <p>The most common one is a missing <code>alt</code>. People either write <code>alt="image"</code> or stuff keywords in there. Both read badly through a screen reader. Alt text describes the picture to someone who can't see it: <code>alt="Dark grey steel garage door after installation, seen from the street"</code>. Purely decorative images get <code>alt=""</code> — an empty string, not an omitted attribute.</p> <p>If editors upload content through a CMS, the template has to cover for them: <code>alt={image.alt || contextFallback}</code>. Don't assume everyone remembers. On one client site I counted 32 images without alt; after the fix, zero.</p> <p>Docs: <a href="https://web.dev/learn/accessibility/images" rel="noopener noreferrer">https://web.dev/learn/accessibility/images</a></p> <p>Second issue is dimensions. Without <code>width</code> and <code>height</code>, the browser doesn't know how much room an image needs. It lays out everything else first, then reflows once the image arrives, and the user watches the content jump. That's where CLS comes from.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;img</span> <span class="na">src=</span><span class="s">"/hero.webp"</span> <span class="na">width=</span><span class="s">"1200"</span> <span class="na">height=</span><span class="s">"630"</span> <span class="na">alt=</span><span class="s">"…"</span> <span class="nt">/&gt;</span> </code></pre> </div> <p>Docs: <a href="https://web.dev/articles/optimize-cls" rel="noopener noreferrer">https://web.dev/articles/optimize-cls</a></p> <p>Third is file size, and it's the most visible one. A hero exported straight from the design file can land at 527 KB. I once found a star rating icon, an SVG, weighing 123 KB when it should have been about 2 KB.</p> <p>I do three things together: convert to WebP or AVIF, serve the size the layout actually uses (a 400px card doesn't need a 2000px image), and let the CDN handle it with something like <code>?auto=format,compress&amp;q=75&amp;w=800</code>. Also don't lazy-load the hero — give it <code>fetchpriority="high"</code> and lazy-load the rest.</p> <p>Static assets on one site went from 996 KB to 79 KB.</p> <p>Docs: <a href="https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images" rel="noopener noreferrer">https://developer.chrome.com/docs/lighthouse/performance/uses-webp-images</a></p> <h2> 2. Don't load the whole font family </h2> <p>Text goes blank for a second on mobile, and LCP suffers for it.</p> <p>Usually the entire family is being pulled down at once: four to six weights, plus full character sets. While it downloads, the browser may show nothing at all. Chinese sites hit this hard, since a single CJK font can run into megabytes.</p> <p>What I do: keep only the weights in use, say 400 and 600; ship woff2 split by <code>unicode-range</code>, so an English page never fetches the CJK file; and set <code>font-display: swap</code> so text appears in the system font first.</p> <p>On one site that was Roboto at 468 KB plus Raleway at 309 KB, 777 KB total, and after the split 57 KB plus 43.7 KB — 100.7 KB.</p> <p>Docs: <a href="https://developer.chrome.com/docs/lighthouse/performance/font-display" rel="noopener noreferrer">https://developer.chrome.com/docs/lighthouse/performance/font-display</a></p> <h2> 3. Third-party scripts: not whether, but when </h2> <p>Scrolling feels sticky, clicking a button does nothing for a moment. That's usually total blocking time.</p> <p>GTM, the Facebook pixel, chat widgets — they all load as synchronous JavaScript and compete with your page for the main thread. While it's busy, taps do nothing.</p> <p>Deleting them is cleanest, but on most client work the tracking scripts are a business requirement and I can't touch them. So I change when they load instead:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code><span class="p">[</span><span class="dl">'</span><span class="s1">scroll</span><span class="dl">'</span><span class="p">,</span><span class="dl">'</span><span class="s1">click</span><span class="dl">'</span><span class="p">,</span><span class="dl">'</span><span class="s1">keydown</span><span class="dl">'</span><span class="p">,</span><span class="dl">'</span><span class="s1">mousemove</span><span class="dl">'</span><span class="p">,</span><span class="dl">'</span><span class="s1">touchstart</span><span class="dl">'</span><span class="p">]</span> <span class="p">.</span><span class="nf">forEach</span><span class="p">(</span><span class="nx">e</span> <span class="o">=&gt;</span> <span class="nf">addEventListener</span><span class="p">(</span><span class="nx">e</span><span class="p">,</span> <span class="nx">loadTags</span><span class="p">,</span> <span class="p">{</span> <span class="na">once</span><span class="p">:</span> <span class="kc">true</span><span class="p">,</span> <span class="na">passive</span><span class="p">:</span> <span class="kc">true</span> <span class="p">}));</span> <span class="nx">requestIdleCallback</span><span class="p">?.(</span><span class="nx">loadTags</span><span class="p">);</span> <span class="nf">setTimeout</span><span class="p">(</span><span class="nx">loadTags</span><span class="p">,</span> <span class="mi">3500</span><span class="p">);</span> </code></pre> </div> <p>Inject them once the page is idle, or after the first sign of interaction. Nothing is removed and nothing stops reporting. With that change on one site, TBT went from 284 ms to 179 ms.</p> <p>Worth knowing before you promise a number: changing when a script loads is something you can usually get approved. Removing it is not. Where the tracking scripts stay, mobile performance has a ceiling, and it's not a ceiling you can code your way past.</p> <p>Docs: <a href="https://developer.chrome.com/docs/lighthouse/performance/third-party-summary" rel="noopener noreferrer">https://developer.chrome.com/docs/lighthouse/performance/third-party-summary</a> and <a href="https://web.dev/articles/tbt" rel="noopener noreferrer">https://web.dev/articles/tbt</a></p> <h2> 4. Navigation built from buttons is invisible to crawlers </h2> <p>The audit says <code>Links are not crawlable</code>, which means search engines can't follow your links.</p> <p>Crawlers read <code>&lt;a href="..."&gt;</code>. If your nav is a <code>button</code> with an <code>on:click</code> handler that scrolls the page, it isn't a link as far as a crawler is concerned. Your most important entry points simply don't exist in search.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;a</span> <span class="na">href=</span><span class="s">"/#whatwedo"</span><span class="nt">&gt;</span>What we do<span class="nt">&lt;/a&gt;</span> </code></pre> </div> <p>You keep the styling and the smooth scroll. Let CSS handle it with <code>html { scroll-behavior: smooth }</code> rather than intercepting clicks in JavaScript.</p> <p>On one site I counted four real <code>&lt;a href&gt;</code> elements on the whole page; the rest of the navigation was JavaScript. Real links took SEO from 83 to 100.</p> <p>Docs: <a href="https://developers.google.com/search/docs/crawling-indexing/links-crawlable" rel="noopener noreferrer">https://developers.google.com/search/docs/crawling-indexing/links-crawlable</a></p> <h2> 5. canonical tags and structured data </h2> <p><code>canonical</code> tells search engines which URL is the source of truth for a piece of content. Parameterised URLs, language variants and leftover staging environments all make it easy for them to treat the same page as duplicates. Structured data (JSON-LD) is what lets results show details like ratings or service areas.<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;link</span> <span class="na">rel=</span><span class="s">"canonical"</span> <span class="na">href=</span><span class="s">"https://example.com/page"</span> <span class="nt">/&gt;</span> <span class="nt">&lt;meta</span> <span class="na">property=</span><span class="s">"og:url"</span> <span class="na">content=</span><span class="s">"https://example.com/page"</span> <span class="nt">/&gt;</span> </code></pre> </div> <p>One trap here is worth its own paragraph. In Svelte:<br> </p> <div class="highlight js-code-highlight"> <pre class="highlight html"><code><span class="nt">&lt;script </span><span class="na">type=</span><span class="s">"application/ld+json"</span><span class="nt">&gt;</span><span class="p">{</span><span class="nx">JSON</span><span class="p">.</span><span class="nf">stringify</span><span class="p">(</span><span class="nx">data</span><span class="p">)}</span><span class="nt">&lt;/script&gt;</span> </code></pre> </div> <p>That renders the literal string on the page. Users can see <code>{JSON.stringify(data)}</code> sitting in the markup, because Svelte doesn't evaluate what's inside a <code>&lt;script&gt;</code> element. You need <code>{@html ...}</code>. I found it only because the Facebook pixel logged "Malformed JSON".</p> <p>So after adding structured data, open the page in a browser and look at what actually renders. Don't trust the source file.</p> <p>Docs: <a href="https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls" rel="noopener noreferrer">https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls</a> and <a href="https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data" rel="noopener noreferrer">https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data</a></p> <h2> 6. Contrast and touch targets </h2> <p>When accessibility stalls at 97 or 98, the culprits are almost always <code>color-contrast</code> and <code>target-size</code>.</p> <p>Light grey text on white looks refined, but WCAG AA wants a contrast ratio of 4.5:1, or 3:1 for large text. Tappable things on mobile need to be at least 24×24 px, and putting them too close together also fails.</p> <p>Don't judge this by eye. Run Lighthouse once and it tells you the exact values you're missing. Readability beats the elegant-grey look.</p> <p>On my own site: <code>#a4a4a4</code> on <code>#f7f7f7</code> measured 2.85:1, so it became <code>#767676</code> at 4.54:1. Footer links were 85×20 px and got padding to clear 24 px.</p> <p>Docs: <a href="https://web.dev/learn/accessibility/color-contrast" rel="noopener noreferrer">https://web.dev/learn/accessibility/color-contrast</a> and <a href="https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html" rel="noopener noreferrer">https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html</a></p> <h2> Two honest notes </h2> <p>A perfect Lighthouse score isn't the point. The point is that people see your content within three seconds, can tap what they need, and can find you in search. The score is useful only because it turns those feelings into numbers you can work through and verify one at a time.</p> <p>The longest run I've done was eight rounds to take a mobile score from 61 to 86, and that was with every third-party tracking script left in place. Most sites don't need eight rounds. The first three items above will usually cut the page weight in half.</p> <p>If you're not sure where your site stands, send me the URL. I'll run it through a tool I built and give you a free diagnosis: why the score is stuck, what's fixable, and which parts are a ceiling set by third-party scripts that no amount of refactoring will move.</p> <p>Tool: <a href="https://prismicaudit.com" rel="noopener noreferrer">https://prismicaudit.com</a></p> webdev performance seo a11y