Why meta tags are not SEO
The phrase "built for SEO" gets attached to almost every website sold today. In practice, it usually means one of two things: a plugin has been installed that prompts you to write a meta description, or someone has added keyword-stuffed copy to the homepage.
Neither of these is SEO in any meaningful sense. Meta descriptions do not affect rankings. They affect click-through rate in search results, which is a secondary signal. Keywords in page copy matter far less than they did a decade ago. What actually determines organic search performance is a combination of technical signals that live in the code, not in the content.
This distinction matters because it changes where the SEO work happens. If SEO is about meta tags, you can add it after the site is built. If SEO is about code structure, it has to be part of the build from the first line.
Semantic HTML: the foundation search engines read
Search engines process HTML. They don't render pages the way browsers do - they parse document structure. The quality of that structure determines how well a search engine can understand what your page is about and how the information is organised.
Semantic HTML uses elements that carry meaning. <article>, <nav>, <header>, <main>, <section> - these tell the parser something about the role of the content they contain. A heading hierarchy that uses <h1> through <h3> correctly signals the relative importance of topics on the page.
Template platforms and page builders generate the opposite of this. A typical Elementor or Divi page wraps everything in generic <div> elements with class names that describe the visual layout, not the semantic role. The parser sees a flat structure with no meaningful hierarchy. The search engine has to guess what's important.
Custom code can be written with semantic correctness as a primary requirement. Every element is chosen for its meaning, not just its rendering behaviour. The heading hierarchy is a deliberate editorial decision, not an accident of which heading size looked right in the visual editor.
Structured data and JSON-LD: telling search engines what your content is
Structured data is machine-readable information embedded in your page that tells search engines not just what your content says, but what it is. A business address is a string of text to a human. It's a PostalAddress schema object to a search engine. A product listing becomes a Product with a price, availability, and aggregateRating.
JSON-LD is the preferred format for this data. It's injected into the <head> of your page as a <script type="application/ld+json"> block. It doesn't affect visual rendering, but it enables rich results in search - the star ratings, opening hours, FAQ dropdowns, and breadcrumbs you see in Google's results for well-structured pages.
Most template sites have no structured data at all, or rely on a plugin that generates a generic WebPage schema with minimal fields. A custom build can implement the full schema hierarchy appropriate to the business: LocalBusiness, Service, FAQPage, BreadcrumbList - structured precisely to match the actual content and business type.
Core Web Vitals: performance as a ranking signal
Core Web Vitals are part of Google's page experience signals. The three primary metrics - Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) - measure how fast and stable a page feels to a real user.
LCP measures how long it takes for the largest visible element (usually the hero image or headline) to load. CLS measures how much the layout shifts unexpectedly while the page is loading. INP measures how quickly the page responds to the first user interaction.
Template platforms typically struggle with all three metrics for structural reasons. LCP is delayed by render-blocking JavaScript and CSS from unused features. CLS is caused by images without explicit dimensions, web fonts that load after the layout is painted, and ad placements that push content down after initial render. INP is affected by the size of the JavaScript bundle the browser has to parse before interaction is possible.
A custom build can solve each of these by design. Images get explicit width and height attributes. Critical CSS is inlined. JavaScript is minimal and deferred. Font loading uses font-display: swap with preloaded font files. These are not difficult optimisations. They're just impossible to implement properly inside a template's constraints.
Canonical URLs and multilingual architecture
For businesses operating in multiple languages or regions, the SEO stakes get higher. Without correct hreflang attributes, Google cannot determine which version of a page to show to which audience. The result is that the English page ranks for German searches, or both versions compete against each other and both perform worse than either would alone.
The hreflang implementation is not complex in principle: each language version of a page declares a relationship to all other versions, including an x-default fallback. In practice, template platforms implement this inconsistently, and page builders often break it entirely when pages are duplicated or migrated.
Canonical URLs present a similar problem. When a CMS generates multiple URLs for the same content - with and without trailing slashes, with and without query parameters, with and without pagination suffixes - the canonical tag ensures search engines know which version is authoritative. Template platforms often generate canonical confusion through automatic URL generation rules that conflict with actual page structure.
Custom builds can implement canonical and hreflang logic systematically at the routing level, ensuring every page in every language carries the correct declarations consistently.
AI-ready content structure and generative engine optimisation
A newer consideration - but increasingly important - is how AI-powered search features process your content. Google's AI Overviews, Bing's Copilot integration, and third-party AI assistants all ingest web content differently from traditional crawlers. They look for clear, quotable passages, well-structured factual claims, and content that answers specific questions directly.
This changes the writing requirements for pages, but it also changes the structural requirements. A well-structured document with a clear <article> container, organised subsections with descriptive headings, and concise opening paragraphs that summarise the section's content is more likely to be quoted in AI-generated responses than a visually rich page full of content trapped in JavaScript components or split across fragmented <div> blocks.
The lede paragraph convention - a 50-80 word opening that states the article's main claim clearly - is borrowed from journalism for exactly this reason. AI systems privilege introductory material that establishes context. A page that buries its point inside a JavaScript carousel that requires interaction to reveal is invisible to both AI crawlers and traditional search engines.
Built-for-SEO, understood properly, means built for how the web actually works today: semantic structure, fast loading, correct metadata, and content that's accessible to both human readers and automated systems. That's a code architecture decision, not a plugin choice.
Want a site that performs in search from day one?
Every Linekern build includes semantic HTML, Core Web Vitals optimisation, and structured data - built in, not bolted on.
Free demo →