There's a comforting myth in web development: build a fast, modern site and the SEO takes care of itself.
It doesn't.
A custom-built site gives you a huge head start — clean HTML, fast pages, no plugin bloat. But search engines still need the right signals to understand, trust, and rank what you've built. Miss those signals and a genuinely excellent site can stay invisible.
This is the technical SEO layer we build into every project. Here's the field guide — the parts that actually move the needle, and a few traps that catch even well-built sites.
Why a fast site still needs a technical SEO layer
When you build on a framework like Next.js, a lot goes right by default: semantic markup, fast loads, mobile-friendly layouts. That's the foundation search engines reward.
But "fast and clean" isn't the same as "understood." A crawler landing on your page still has to answer questions: What kind of business is this? Who wrote this article? Where does this page sit in the site? Is this content worth showing? None of that is automatic — you have to tell it, explicitly, in a language it reads.
That language is mostly structured data, sitemaps, and Core Web Vitals — plus a few content signals. Here's how we handle each.
Structured data: the highest-leverage thing most sites skip
Structured data (JSON-LD) is a small block of machine-readable code that describes your page. It's what powers rich results — the star ratings, FAQ dropdowns, breadcrumb trails, and knowledge-panel details you see in Google.
Most custom sites ship with little or none of it. That's the single biggest, easiest win on the table.
What actually matters
You don't need every schema type. Focus on the ones that map to real page types:
- Organization — one block, site-wide. Your name, logo, contact point, social profiles, and the areas you serve. This is how Google builds an entity for your business.
- WebSite — declares the site and its language(s).
- Article / BlogPosting — on every post: headline, author, publish and modified dates, image. This is what makes articles eligible for rich treatment.
- BreadcrumbList — the hierarchy of the page (Home › Blog › This Post). Google shows it in results instead of a raw URL.
- FAQPage — if a page genuinely answers questions, this can earn expandable results.
Two details worth getting right: point your Organization logo at a raster PNG, not an SVG favicon (Google's guidelines are specific about this), and make sure your social sameAs URLs actually match your live profiles. A mismatch quietly weakens the entity Google builds for you.
The sitemap that returns 200 — and still "can't be fetched"
This is the subtlest trap on the list, and it catches well-built sites — so it's worth the detail.
Picture a sitemap that does everything right: it returns 200 OK, serves valid XML, loads in under 200 ms, has a valid certificate, and isn't blocked by robots. From every angle you can test, it works. And Search Console still reports "Couldn't fetch."
The usual cause is how it's served, not what's in it. A sitemap generated by a dynamic app route can come back with framework-specific caching and content-negotiation headers that Google's sitemap fetcher — a different mechanism from its normal crawler — won't accept. A live URL inspection can even show "Page fetch: Successful," which makes it look like a Search Console glitch.
The fix is to serve the sitemap as a plain static file generated at build time — identical content, clean headers. It validates immediately. And if a specific URL has picked up a "couldn't fetch" history in Search Console, publish the same content at a fresh URL and point robots.txt there.
The takeaway: if a sitemap "can't be fetched" but works everywhere you test it, suspect how it's served, not what's in it.
Core Web Vitals and the weight of a single image
Page speed is a ranking factor, and it's mostly about bytes. On most sites, the single heaviest asset is one hero image.
Here's the trap: a detail-dense 2430px screenshot can weigh 879 KB at source, and even after a framework's on-the-fly optimisation, the largest delivered variant lands around 188 KB. On a page that only ever displays it at ~1215px, that resolution is pure waste. Right-size the source to 1150px and every delivered variant drops to around 52 KB — a 70% cut — with no visible loss. "Optimised on delivery" doesn't help if the source is three times larger than it needs to be.
While you're at it, give every background and decorative image explicit width and height. Missing dimensions are a leading cause of layout shift — the annoying jump as a page loads — which Core Web Vitals penalises directly.
Content signals: readability and headings
Two softer signals round out the technical layer.
Readability. Automated tools flag copy that reads at a "difficult" level. Often the sentences are fine — it's the vocabulary that's dense with formal, multi-syllable words. Swapping "utilise" for "use", "in accordance with" for "under", and breaking a few long clauses lifts the score without dumbing anything down. Clearer copy is better for readers and machines.
Headings. One myth worth killing: multiple <h2>s on a page are not a problem. Some audit tools flag it, but it's correct HTML — every page with more than one section should have more than one <h2>. What matters is a logical order: one <h1>, sections as <h2>, sub-points as <h3>. Don't skip levels, and don't collapse real sections to satisfy a tool.
Breadcrumbs: schema and the visible trail
Breadcrumbs do two jobs. The BreadcrumbList schema lets Google show the trail in results. The visible breadcrumb helps users and reinforces the hierarchy. Do both, and keep the URLs canonical — a breadcrumb pointing at a redirecting URL is a small, avoidable waste.
The checklist
If you're reviewing a custom site, this is the short version:
- Organization + WebSite JSON-LD, site-wide, with a raster logo and correct
sameAs. - Article schema on posts, with
datePublished,dateModified, author, and an image. - BreadcrumbList schema — plus a visible trail — on nested pages.
- Sitemap served as a static file; every internal link pointing at canonical (non-redirecting) URLs.
- hreflang / canonical tags correct on every localised page.
- Images: source no larger than needed, explicit
width/height, modern formats. - Metadata: unique titles under ~60 characters, descriptions under ~155.
- Headings: one
<h1>, logical<h2>/<h3>structure. - Robots + indexing: confirm important pages are indexable and redirects resolve cleanly.
A custom build gets you most of the way — but the last mile of technical SEO is what turns a fast site into a findable one. None of it is glamorous. All of it compounds.
It's the work we build into projects and run as standalone audits. If your custom-built site is quietly under-performing in search, let's talk — a technical audit usually surfaces a handful of fixes with outsized impact.