Coder Legion - Recent posts tagged fix

5 Technical SEO Fixes in Templates and Code | FloxoLab

Mon, 26 Oct 2026 15:50:00 +0000

Direct answer: When the same SEO defect appears across a URL pattern, fix the template, routing rule, navigation component, or generator that creates it. Page-by-page edits are temporary. A complete fix names the shared source, implementation owner, rollback path, and recrawl test.

Some SEO problems can be fixed in a CMS field. Others are generated by a shared template, routing rule, navigation component, or sitemap process. In those cases, editing individual pages treats the symptom while the generator keeps recreating it.

The right workflow is consistent: identify the visible symptom, locate the shared source, change it with an appropriate developer or site owner, then crawl the rendered site again. Below are five common examples with a detection method, likely fix location, and validation step.

Use this implementation map

Repeated symptom	Likely shared source	Validation after deployment
Duplicate titles	Page template or content-to-template data binding	Crawl the affected pattern and confirm distinct, descriptive titles
Wrong canonicals	Head template, routing rule, or URL helper	Sample final 200 URLs and confirm the intended canonical in rendered HTML and URL Inspection
Uncontrolled parameter URLs	Filter links, router behavior, or faceted-navigation rules	Crawl the allowed path and confirm only intended combinations remain discoverable
Broken links or redirect chains	Navigation component, shared content block, or link generator	Recrawl the component and confirm direct links to final 200 destinations
Bloated sitemap	Sitemap generator, manifest, or CMS export rule	Validate the XML and confirm it contains only canonical, indexable 200 URLs

Why the fix location matters

A template edit can affect every page that uses it. It therefore needs code access, testing, deployment, and a rollback path. An SEO specialist may diagnose the problem while a developer implements it, or one person may do both. What matters is that the scope names the owner and does not leave the issue as a recurring audit note.

Ask for five things: affected URL pattern, source of the generated output, intended rule, implementation owner, and post-deployment test. That turns a vague recommendation into work that can be shipped and verified.

On a new build, define those shared rules before visual sign-off. The SEO-friendly web design checklist turns navigation, URL states, template fields, mobile parity, schema, and launch validation into an acceptance contract instead of a repair queue.

Fix 1: Templated duplicate titles

The title element helps Google and users understand a page, but Google may generate a different title link in search results. When a template hardcodes the same title across a section, the pages lose a clear description of what makes each one distinct.

If the problem belongs to one important URL, use the ordered on-page SEO audit checklist to test its task, title, content, links, media, and rendered output together. If the same symptom appears across a section, keep reading here and fix the shared generator.

The cause is almost always one template line. A product or service template prints the site name and nothing else, so every page in the section ships identical:

For the wider product and category implementation, use the product and category page SEO guide to connect unique page jobs, crawlable inventory, variants, availability, media, and Product data before fixing individual titles.

<title>Acme Print Shop</title> <title>Acme Print Shop</title> <title>Acme Print Shop</title>

The fix is to build the title from the page's own data, so one template produces a unique, descriptive title per page:

<title>{{ page.name }} | Acme Print Shop</title>  <title>Vehicle graphics and vehicle wraps | Acme Print Shop</title> <title>Business cards, matte or gloss | Acme Print Shop</title>

To find it yourself, crawl the site with a tool like Screaming Frog and sort by the title column. A block of identical titles is the tell. If you are investigating a title that appears differently in search, compare the rendered title element with a live result for a small sample. Search Console does not provide a title-rewrite report. Titles still matter even when Google generates a different visible title link, so a clear, unique, descriptive title per page remains the right starting point.

Fix 2: The wrong canonical across a whole section

A canonical tag is a strong hint about the preferred URL among duplicate or very similar pages. A wrong value in a shared template can cause Google to choose an unexpected canonical. The classic failure is a section template that points every page at the homepage or one category page.

<link rel="canonical" href="https://example.com/" />

A distinct indexable page will usually use a self-referencing absolute canonical with the site's preferred protocol, host, and path format. Redirects, internal links, sitemap URLs, and canonical tags should agree on that preferred form.

<link rel="canonical" href="https://example.com/services/vehicle-graphics" />

Check it by viewing source on a handful of pages across each section and reading the canonical line. If two different pages name the same canonical URL, or a page canonicalizes somewhere unexpected, you have found a template bug. This is also the correct tool for consolidating duplicate URLs, which leads straight to the next fix.

Article JSON-LD can repeat the same URL mistake across every guide. The Article schema implementation guide shows how to keep the canonical, author, dates, image, and breadcrumbs aligned with the visible page and validate the rendered output.

If Search Console has already grouped an important URL under this status, follow the complete Crawled - currently not indexed troubleshooting sequence. It checks the stored and live versions, rendered HTML, canonical signals, internal discovery, and whether the page should remain a separate URL.

Fix 3: Parameter URLs splitting the crawl budget

Filters, sorting, and tracking tags generate URLs. A shop with color, size, and sort options can turn one real page into hundreds of near-identical addresses: ?color=red, ?sort=price, ?color=red&sort=price, and so on. Google has a limited budget for how much of a site it will crawl, and on a large or filter-heavy site these parameter URLs can eat it, leaving real pages crawled less often. Crawl budget becomes a real concern once a site runs past roughly ten thousand URLs or leans on faceted navigation. If your site has a few hundred pages and no filters, crawl budget is not your problem right now, so do not lose sleep over it. The canonical part below still applies; the robots.txt blocking matters most once your URL count climbs.

Choose the control based on whether Google needs to crawl the URL. If a parameter version can be crawled, a canonical may help consolidate a genuinely duplicate page:

<link rel="canonical" href="https://example.com/shop" />

For filter and sort URLs that should not be crawled, Google documents robots.txt as one option on large faceted sites. Do not combine that assumption carelessly: when robots.txt blocks a URL, Google cannot fetch the page to read its canonical or noindex tag. Test the required facets and keep crawlable any URL that must be discovered or indexed.

# robots.txt: stop crawl waste on filter, sort, and tracking URLs User-agent: * Disallow: /*?sort= Disallow: /*?filter= Disallow: /*?utm_

Treat the sample as an illustration, not a block to paste blindly. Inventory parameters first, decide which combinations have unique search value, and test the rules on a staging or controlled URL set before deployment.

Fix 4: Broken internal links and redirect chains

Internal links are how Google moves through your site and how ranking signals flow between pages. Two things quietly break that flow. A link to a page that now returns a 404 sends both a crawler and a visitor into a dead end. A link to an old URL that redirects, then redirects again, makes every crawl pay for hops it should not have to.

# A nav link that costs three hops instead of one /old-page -> /new-page/ (301) /new-page/ -> /new-page (301, trailing-slash rule) /new-page -> 200 OK

Neither is fatal on a single link. The damage is structural: these links usually live in shared template parts, a navigation menu, a footer, a sidebar, so one stale URL repeats on every page of the site. The fix is to update the link in the template to point straight at the final, live URL, removing the chain entirely.

<a href="https://floxolab.com/new-page">Our work</a>

A site crawl lists every internal link with its status code. Sort by anything that is not a 200, fix the worst offenders first (the ones in global navigation), and recrawl to confirm the chains are gone.

Fix 5: The bloated sitemap

Your XML sitemap is meant to be a clean list of the pages you want indexed. When it is generated automatically and never pruned, it fills up with URLs that contradict that purpose: pages that redirect, pages that 404, pages marked noindex, pages blocked in robots.txt. Handing Google a list and then telling it half the list should not be indexed sends conflicting signals and wastes the discovery the sitemap exists to help. A good sitemap contains only canonical URLs that return 200 and are meant to be indexed.

<loc>https://example.com/old-page</loc>  <loc>https://example.com/thank-you</loc>  <loc>https://example.com/deleted</loc>

A healthy entry lists a live, canonical URL with an honest last-modified date that reflects when the content actually changed:

<url> <loc>https://example.com/services/vehicle-graphics</loc> <lastmod>2026-06-13</lastmod> </url>

Search Console's Sitemaps and Page indexing reports will flag much of the rot for you: redirects, 404s, and "excluded by noindex" pages that still sit in the file. The fix is to correct how the sitemap is generated so those URLs never enter it, not to delete rows by hand once a year.

For the full audit sequence, follow the guide to fixing redirects and non-canonical sitemap URLs. It maps each response and canonical state to the right action, then validates the regenerated file in Search Console.

Before a CMS or domain change, put these checks into a migration baseline and post-launch crawl diff. That makes template, redirect, canonical, and sitemap regressions visible while they are still recoverable.

Notice the pattern across all five. Each is one line, one rule, or one template fragment, repeated everywhere. That is why they are worth fixing and why a page-by-page workflow never gets to them. They are properties of the code that builds the site, not of any single page.

What implementation should include

A useful handoff does not stop at "titles are duplicated." It identifies the template or generator, proposes the intended rule, tests representative pages, ships with a rollback path, and recrawls the affected pattern. Finding public-output problems often needs only read access. Fixing them requires authorized access to the CMS, code, or deployment process. For the access boundary, see what access an SEO audit actually needs.

If you use a monthly provider, ask which issues they diagnose, which they implement, and who coordinates the rest. A clear development boundary is acceptable when it is explicit. For common scope patterns, see what a typical SEO retainer actually does, and to confirm whether the release changed visibility, read your own monthly report.

The bottom line

These fixes are template and configuration changes: descriptive titles, coherent canonical signals, deliberate handling of parameter URLs, internal links that point straight at live pages, and a sitemap containing canonical indexable URLs. The durable result comes from changing the generator and verifying the rendered output, not editing affected pages one at a time.

Want to know which of these are live on your site right now? That is what the fixed-price SEO audit finds: a full crawl plus your real Search Console data, with a prioritized fix list you own, and the template-level changes spelled out clearly enough to ship. One report at a flat $150, no retainer, no ranking promises. And if you want these template-level fixes kept up as the site keeps growing, an ongoing SEO retainer does exactly that. Get in touch to start.

Sources checked

Google's title, canonical, crawling, faceted-navigation, and sitemap guidance was rechecked on August 2, 2026.

Originally published on FloxoLab.

A Quick Way to Fix LCP: Four Changes That Cut Time to Paint

Thu, 09 Jul 2026 12:39:00 +0000

Largest Contentful Paint (LCP) fails when the browser is still waiting on the server, fighting for bandwidth, or blocked on JavaScript before it can paint the biggest thing in the viewport. You do not need a six-week performance programme to move the needle. In our delivery work, four changes cover most urgent LCP regressions: fix Time to First Byte (TTFB), remove competing work from the path to the LCP element, prioritise that element with fetchpriority="high", and schedule low-value JavaScript after the load event. What follows is a practical order of operations, with enough detail to implement without re-reading a full Core Web Vitals textbook.

For background on thresholds and the four LCP sub-parts, see LCP, INP, CLS: What Each Core Web Vital Means and How to Fix It. For image-specific tuning when the LCP element is a hero photo, see Image Optimisation Strategies for Better LCP Scores. Both posts go deeper on sub-parts and formats; here we stay focused on the fastest fixes.

What is the path to LCP?

LCP is not one timer. It is a chain from first request to final paint of the largest visible element. Google’s documentation breaks the chain into TTFB, resource load delay, resource load duration, and element render delay. The path to LCP is everything the browser does before that element paints: HTML download, discovery of the LCP resource, competing requests, font and script work on the main thread, and layout.

When teams say “LCP is slow but the hero image is only 200 KB,” the bottleneck is usually earlier in the chain. TTFB adds blank time. Icons, analytics, web fonts, and below-the-fold images steal connection slots. JavaScript runs before the browser can commit the LCP paint even after the asset has arrived. The four fixes below map directly to those failure modes.

Step 1: Improve TTFB (Time to First Byte)

TTFB is pure page-blank time. Nothing in the viewport can render until the first byte of HTML arrives. If TTFB is 800 ms on mobile lab tests, every downstream optimisation starts late.

Treat TTFB as a caching and origin problem first:

Cache database queries on CMS and ecommerce routes that build the HTML shell. Object caches (Redis, Memcached) and query result caching cut repeated work on popular templates.
Cache full pages or page fragments at the edge. A CDN or reverse proxy (Cloudflare, Fastly, Varnish, nginx proxy_cache) should serve anonymous HTML for marketing and category pages where content is not user-specific.
Cache generated code paths where applicable. Opcode caches (OPcache on PHP), template compilation caches, and warmed application caches reduce CPU time per request.

Also check the basics: slow upstream APIs in the critical path, cold serverless instances, and TLS or DNS misconfiguration. TTFB improvements often drop LCP by hundreds of milliseconds without touching front-end assets at all, which makes this step worth doing even when the design team is already compressing heroes.

Run PageSpeed Insights and note TTFB in the diagnostics. If it is high, fix origin and caching before optimising images. Our Core Web Vitals guide lists the “good” LCP band at 2.5 seconds or less in the field; shaving TTFB is the fastest way to buy headroom when you are close to the line.

Step 2: Remove anything in the path to LCP that matters less than the LCP element

Once HTML starts arriving, the browser schedules dozens of requests. Anything that competes with the LCP resource for bandwidth or main-thread time extends resource load delay and render delay. The rule is simple: if it is not required to paint the LCP element, it should not run or download ahead of it.

Icons and decorative assets

Favicons, sprite sheets, and small UI icons often sit early in the document or load from high-priority stylesheets. They rarely affect LCP directly, but they consume connections and parser attention. Inline critical icon SVGs only when needed above the fold; otherwise load icon fonts and sprite bundles after the LCP resource is underway or from low-priority async paths.

Third-party scripts

Analytics, chat widgets, A/B testing snippets, and personalisation tags are common LCP killers. They execute in the head or early body and block parsing. Audit with the Network panel: sort by start time and see what fires before the LCP image or text block.

Practical moves:

Load tag managers and non-essential vendors after the LCP resource is discoverable (see Step 4 for load-based scheduling).
Self-host or proxy only what you truly need on first paint.
For deeper triage patterns, see Third-Party Scripts and Performance: How to Identify and Fix the Worst Offenders.

Below-the-fold images

Lazy-loading is correct for content lower on the page, but never lazy-load the LCP candidate. Conversely, do not let below-the-fold tags without loading="lazy" sit in the head of the queue with fetchpriority defaults that compete with the hero. Ensure decorative and content images that are not LCP use lazy loading and lower priority so the hero wins the network race.

Fonts that are not needed for the LCP element

Web fonts are often requested from CSS before the LCP image is even parsed. If the LCP element is a photograph, decorative display fonts do not need to block the chain. If the LCP element is a headline, only the weights used in that headline need early loading.

The goal is not “delay until interaction” tricks that hide text until a user taps. The goal is enqueue order: make sure font files for secondary UI copy enter the pipeline after the LCP resource is requested and ideally after it has started downloading. Techniques include splitting @font-face rules into non-critical stylesheets loaded later, subsetting fonts (font subsetting guide), and using system font stacks for non-LCP text on first paint.

Step 3: Prioritise the LCP element with fetchpriority="high"

Browsers schedule requests with heuristics. Hero images discovered late in HTML or hidden behind CSS may get default priority while less important assets jump ahead. The fetchpriority attribute lets you mark what matters.

For an image LCP element:

Pair with in when the LCP image is known at build time and appears late in the markup. Preload is not a substitute for fixing TTFB or removing competing scripts, but it removes discovery delay when the hero sits below inline styles or markup generated by JavaScript.

Do not set fetchpriority="high" on everything. If every image is high priority, none are. Reserve it for the single LCP candidate PSI reports in Lighthouse diagnostics.

For text or video LCP elements, the same principle applies: ensure the resource that feeds the largest paint is discoverable early and not deprioritised by lazy attributes or late injection.

Step 4: Schedule less important JavaScript after the load event

Even when the LCP asset has downloaded, element render delay can balloon if the main thread is busy executing JavaScript. Parsing, compilation, and long tasks defer layout and paint, which is why deferral belongs in the same checklist as caching and fetch priority.

defer and async help for scripts that must run before interaction, but many apps bundle analytics, carousels, and enhancement code that can wait until the page has fully loaded. The load event fires when the document and its subresources (images, stylesheets) have finished loading. Scheduling non-critical work there keeps the main thread freer while LCP is still forming.

Example pattern:



  window.addEventListener('load', function () {
requestIdleCallback(function () {
  initNonCriticalWidgets();
  loadDeferredAnalytics();
}, { timeout: 2000 });

});

Use requestIdleCallback where supported so you do not immediately replace one long task with another. Framework-specific code splitting (dynamic import() on load or on first interaction) achieves the same outcome: the LCP element paints before megabytes of client-side routing and chart libraries execute.

This is distinct from deferring fonts until interaction, which can harm readability. Here we defer JavaScript functions that do not affect first paint: heatmaps, chat bubbles, personalisation hooks, and secondary carousels below the hero.

A one-hour LCP fix workflow

Use this sequence when you have a red LCP on a priority URL and limited time:

Identify the LCP element in PageSpeed Insights or Lighthouse (Diagnostics → LCP element).
Record TTFB on mobile lab. If it is above ~600 ms, open caching and origin tickets first.
Waterfall audit: list every request and script that starts before the LCP resource. Remove or postpone icons, third parties, lazy-competing images, and non-LCP fonts.
Add fetchpriority="high" (and preload if needed) on the LCP node only.
Move non-critical JS to load + idle callbacks; retest.
Set an LCP budget in your monitoring tool so the fix survives the next deploy. See Performance Budget Thresholds Template.

Agencies managing many client homepages and landers should run mobile and desktop lab tests on the same URL after each change. One-off PSI tabs miss regressions when a plugin reintroduces a head script. PageSpeed Insights vs automated monitoring explains why scheduled tests and alerts matter once the quick fix ships.

What these four steps do not replace

These changes target the delivery path to LCP. They do not replace image compression, responsive srcset, CDN tuning, or server-side rendering when the LCP element itself is too large or injected only after client-side hydration. When the LCP element is an image, combine this checklist with the image optimisation guide. When third parties dominate the waterfall, the third-party scripts post goes deeper on vendor policy.

LCP also differs between mobile and desktop strategies. A fix on one may not carry to the other if different heroes or ad slots apply. Monitor both; see Mobile vs Desktop Core Web Vitals.

FAQ

Should I fix TTFB or the LCP image first?

Fix TTFB first when it is high. Blank time before HTML cannot be recovered by compressing a hero image. If TTFB is already healthy, focus on the path to LCP and the LCP resource itself.

Does fetchpriority replace preload?

No. fetchpriority="high" adjusts priority once the browser discovers the resource. Preload starts discovery earlier when the URL is known at build time. Use both on image heroes that appear late in the document.

Is lazy-loading the LCP element ever correct?

No. Never lazy-load the element PageSpeed Insights reports as LCP. Lazy-load below-the-fold images only.

Why defer JavaScript to load instead of using defer on every script?

The defer attribute preserves execution order before DOMContentLoaded for scripts that still run during the critical path. Analytics, widgets, and enhancement bundles that do not affect first paint can wait until load, which reduces main-thread contention while LCP is still forming.

How do I know the fix worked?

Re-run PageSpeed Insights on the same URL and strategy (mobile vs desktop). Compare LCP time and the filmstrip. For production confidence, schedule lab tests with budgets in Apogee Watcher so the next theme or tag-manager change triggers an alert if LCP drifts back above your threshold.

Can Apogee Watcher fix LCP automatically?

No. Watcher schedules PageSpeed lab tests, stores LCP and other vitals over time, and emails you when budgets breach. You still implement caching, prioritisation, and script deferral in the codebase; Watcher tells you when those fixes slip on priority URLs across client sites.

TTFB, a clear path to the LCP element, fetchpriority="high", and JavaScript deferred until after load are the four changes we reach for first when LCP is red and the release window is small. Ship them in that order, re-test on mobile lab, then lock the win with budgets and scheduled monitoring so the metric stays green after the next deploy. Start a free Apogee Watcher account to track LCP on priority URLs with mobile and desktop schedules and vitals budgets, or run a free domain PageSpeed check before you change caching or script order.