Marketing

SEO foundations: what's built in during development

Part of search optimisation is done not by an SEO specialist but by a developer — and done once. What can't be added later with a plugin.

"We'll build the site and bolt SEO on later" is a phrase after which a rework begins six months on. Some search engine requirements concern not the texts but how the site is built: URLs, page templates, speed and markup. All of this is settled at the design stage almost for free and costs noticeably more once the site is live and indexed.

URL structure

A page's URL is its permanent identifier. The search engine ties accumulated signals to it, external links point exactly to it, and changing it later is painful.

What makes sense to build in straight away:

  • Readable URLs in Latin characters that reflect the hierarchy: section, subsection, page. /services/websites/landing is clear to both people and systems.
  • One page, one URL. If the same material is available at several paths, the search engine has to know which one is primary.
  • Settled rules on trailing slashes, case and www. All variants should lead to one canonical URL via a permanent redirect.
  • Language in the URL, not in a parameter. Language versions live under prefixes and are linked to each other with hreflang attributes.
  • Predictable behaviour with filters and sorting. Parameter combinations shouldn't spawn an endless number of indexable pages.

Changing the URL structure on a live site means a redirect map for every existing page, a period of ranking loss and inevitable losses on links nobody thought to account for. A correct scheme from the start costs one discussion at kick-off.

Titles and descriptions as part of the template

The title tag and meta description are written for a specific page, but the ability to set them is a developer's job. If the content management system simply has no such fields, the SEO specialist has nothing to fill in.

The template requirements are simple:

  1. Every page can have its own title and description, and when a field is empty a sensible default rule applies, not one shared title for the whole site.
  2. A page has exactly one first-level heading, and the other levels follow in order and reflect the text's structure, not font size.
  3. Images have a descriptive attribute.
  4. Pages that don't belong in search — service pages, technical pages, filter duplicates — have a way to be excluded from indexing.
  5. Canonical links and correct server response codes are set: a non-existent page returns 404, not 200 with a "nothing found" message.

The last point is a common reason hundreds of empty pages end up in the index. No amount of text fixes that.

Speed and how the page is served

Speed affects both people's behaviour and how search engines evaluate a page. Yet most of it is determined by decisions made before the first line of content is written: which stack, how markup is served, how many third-party scripts are loaded.

The key question is what the search crawler receives in response to a page request. If the server returns an empty shell and the content is assembled by a script in the browser, indexing becomes unpredictable. This is solved at the architecture level: with server-side rendering or pre-building pages. Switching to server-side rendering in a finished project is essentially rebuilding the frontend.

The rest is in the same vein:

  • images in modern formats and at the right size, not camera originals shrunk with styles;
  • lazy loading of what isn't visible on the first screen;
  • a limited number of third-party scripts — every chat, widget and counter slows the page;
  • correct caching of static assets.

Speed isn't a setting you switch on. It's a consequence of architecture, and changing it after the fact is always more expensive.

Structured data, sitemap and service files

Structured data tells the search engine what exactly is on the page: an organisation, a product, an article, a Q&A, breadcrumbs. It doesn't guarantee rich results, but without it they're impossible in principle. It's convenient to generate it by template — one for each page type.

The sitemap should be generated automatically from the real list of pages. A file generated by hand once and forgotten describes a non-existent site six months later. Only pages you actually want in search belong in it: canonical, returning 200, not excluded from indexing.

The robots.txt file closes service sections and points to the sitemap. It's easy to get wrong in both directions: blocking too much when moving from a test server to production is a classic accident, after which the site silently disappears from search results.

A separate page for a separate query

This is an architectural decision, not copywriting. If you have ten services and the site has one "Services" page with a list, you have nothing to compete with for a query about a specific service: search engines rank pages, not companies.

The practical conclusion: the site's structure should mirror the structure of demand. Separate pages for different types of task — this is how, for example, our websites by type section is built, where each type has its own page instead of a general list.

At the same time, there's no point multiplying pages if there's nothing to fill them with. A page for a query makes sense when it has a substantive answer: what's included, how the work goes, how this option differs from the neighbouring one. Ten empty pages are worse than one full one.

Templates for such pages are also laid down during development: if the system only has "home page" and "text page", every new landing page will require custom layout work.

Why "later" costs more

The difference isn't in the volume of work but in the obligations that appear towards the existing state:

  • URLs are indexed, and changing them requires a redirect map;
  • external links point to the pages, some of which you don't control;
  • a page's accumulated history is reset by a careless migration;
  • reworking templates affects the layout of all page types at once;
  • changing the rendering approach means reworking the entire frontend.

None of these points is solved by installing a plugin. A plugin can add fields for titles and generate a sitemap — but it won't change the URL structure, speed up rendering or create pages for your queries.

Pre-launch checklist

  • The URL structure is approved, the canonical domain form is chosen, redirects are set up.
  • Every page type has fields for title and description, with a default rule.
  • The heading hierarchy in templates is correct, and images have descriptions.
  • Non-existent pages return 404; service pages are excluded from indexing.
  • Content is available in the initial server response, not assembled only by a script.
  • Images are optimised, and the number of third-party scripts is deliberately limited.
  • Structured data is generated by page type.
  • The sitemap is generated automatically and contains only canonical pages.
  • robots.txt has been checked on the production domain itself after the move.
  • Key service areas have separate, filled-in pages.

Check this list before launch — at that point any item costs a template edit. If you need help reviewing your current site, describe the task.