Human-readable URLs and page structure
Page URLs should be readable by humans, not look like product.php?id=8473. Search engines look at the address and try to understand what the page is about. If it's just numbers, there's no context.
Good address: /services/ecommerce-development. Bad: /page?id=42 or /services/service-detail/12. In the first case both humans and bots immediately understand what's on the page. In the second, only the database does.
You cannot change URL structure after launch without losing positions. Moving from old addresses to new ones via redirects always means a dip in search results for at least several weeks. So addresses are designed before development, together with the project manager and whoever will be handling promotion.
In practice: ask to see the site map (list of all pages with addresses) before development starts. If they say "we'll figure it out later," that's a problem. Later is expensive.
Title tags, descriptions and H1 headings
Title is the page heading shown in search results and in the browser tab. Description is the short text under the heading in search results. H1 is the main heading on the page itself. They should all be different and unique for each page.
Common mistake: all pages have the same title - the company name. The search engine doesn't understand how pages differ from each other and can't rank them. Or title simply isn't provided for in the CMS - there's physically nowhere to enter it.
Correct: in the site admin panel, each page has separate fields for title, description and H1. Not automatically generated from product name, but actual fields where you can type text manually. If you're building a catalog with 500 products, the template for generating these fields needs to be thought through in advance so you don't have to write them by hand.
If the developer says "the SEO person will add that later" - ask how exactly. Often it turns out there's nowhere to add it, and you'll have to rebuild the engine.
Load speed: not cosmetic, it's ranking
Google directly uses load speed as a ranking factor. Slow sites rank lower. But it's not just about positions: if a page takes longer than three seconds to load, more than half of visitors leave without waiting.
Speed is baked into architecture. You can't make a fast site on WordPress with ten heavy plugins and 5-megabyte photos. You can optimize, but the ceiling will be low. If you start with React with server-side rendering and set up automatic image processing, the site will be fast by default.
What to check before launch: ask to see the result in Google PageSpeed Insights. The score should be in the green zone (80+ points) on mobile devices. If it's red, that's not a cosmetic problem, that's a rebuild.
On our projects we build image compression and lazy content loading into the build process from the start. It's not a separate "do it later" task, it's part of the development process.
Mobile version - not adaptation, priority
Google indexes sites from the mobile version. If the mobile page is broken, slow or inconvenient, the site will rank poorly even in desktop results. This isn't "recommended," it's been a mandatory requirement since 2019.
Responsive layout is the minimum. But it's not enough to just squeeze the desktop version. The mobile page needs to be usable: buttons big enough to hit with a finger, text readable without zooming, forms fillable without torture. If someone misses a button three times in a row, they go to your competitors.
You can check in the same PageSpeed Insights or by opening the site on your phone. If you have to zoom to read text, or the "Submit request" button is half off screen, that's a problem you need to solve during layout, not after launch.
Structured data: helping search engines understand content
Structured data is special code that explains to the search engine what exactly is on the page: product, article, review, contacts. Thanks to markup, search results show star ratings, price, stock availability - this increases click-through rate.
Markup is added to the HTML code of the page. If the site is built on a website builder, it's often built in. If development is custom, it needs to be written manually. And this needs to be done immediately, because adding structured data after the fact means going into every page template and redoing the layout.
Which types of markup are needed: for an online store - products, prices, availability, reviews. For a service site - organization, contacts, services, FAQ. For a blog - articles, author, publication date. The list depends on the type of site, and needs to be agreed at the start.
You can check markup through the Schema.org validator. If it's empty, that means there's no markup, and the site is losing click-through rate.
Images: size, format and alt attribute
Images slow down sites more than anything else. A 3-megabyte photo uploaded from a phone will load for about ten seconds on mobile internet. The user will have time to close the tab.
Proper image handling means automatic compression on upload, modern formats (WebP instead of JPEG), adaptive delivery (small image to phone, large to desktop). This is set up once at the system level, not manually for each file.
The alt attribute is a text description of the image. Needed for the search engine (it doesn't see the image, only text) and for people with disabilities. Without alt, images aren't indexed, and the site loses traffic from image search.
What should be in the admin panel: a field for alt when uploading each image and automatic compression. If this isn't there, the content manager will either ignore alt (hello, lost traffic) or manually compress each photo.
Sitemap.xml and robots.txt files
Sitemap.xml is a site map for search robots, a list of all pages that need to be indexed. Robots.txt is a file with instructions on which pages cannot be indexed (for example, admin panel or shopping cart).
Both files should be generated automatically. If the sitemap is static, you'll have to update it manually every time a new page is added. Usually people forget about this, and half the site remains unknown to the search engine.
Robots.txt is set up once, but is set up incorrectly in 80% of cases: either they close the entire site from indexing with an accidental line, or leave service sections open that clutter the index.
Check: open yoursite.com/sitemap.xml and yoursite.com/robots.txt in a browser right after launch. If the first doesn't open or is empty, and the second gives a 404, this needs to be fixed before the site gets into search.
Clean URLs for filters and pagination
Online stores and catalogs have filters (by price, color, size) and page navigation. If their URLs look like /catalog?page=2&filter=345, the search engine won't index them properly.
Correct: each filter combination and each pagination page is a separate human-readable address. For example, /catalog/mens-shoes/sneakers?page=2. Plus you need canonical tags (rel=canonical) so the search engine understands which page is primary if identical content is available at different addresses.
This isn't done after the fact. The logic for generating URLs for filters is built into the engine during development. If it's not there, the rebuild will cost serious money.
When to bring in an SEO specialist
If the site is more complex than a landing page (online store, service catalog, portal with multiple sections), an SEO specialist needs to be brought in before development begins. They compile the semantic core, design the structure of sections and URLs, write requirements for the engine.
When SEO comes to a finished site, they work with what's there. And often it turns out that main sections are named incorrectly, catalog structure doesn't match queries, and technically adding the needed fields to the admin panel means weeks of development.
On our projects we request contact with the client's SEO specialist (if they have one) at the stage of discussing structure. If there's no specialist, we give recommendations ourselves: basic requirements for URLs, meta tags, speed and markup we build in by default. This isn't SEO promotion, it's the technical foundation without which there'll be nothing to promote.
If you're planning promotion, say so immediately. Developing an SEO-ready site isn't much more expensive than a regular one, but rebuilding a finished one costs many times more.
SEO isn't a separate service you add to a finished site. It's requirements for structure, code and content that are built in during development. Human-readable URLs, meta tags for each page, fast loading, structured data, correct mobile version - all this is done once and immediately. Rebuilding a finished site for SEO is expensive, time-consuming and comes with loss of positions. If you're planning promotion, say so before development starts.
Frequently asked
Can you do SEO after the site launches?
You can, but some requirements will be expensive or impossible to change without rebuilding. URL structure, filter logic, architecture - all this is built in during development. Content, links, meta tags - yes, added after launch. Technical foundation - no.
How much does it cost to build a site with SEO in mind?
Basic SEO requirements (human-readable URLs, meta tags, structured data, load speed) we build into development by default and don't charge separately. It's part of the normal process. If you need complex filter structure or integration with an external SEO service, that's discussed separately. Exact cost comes after the brief, approximate prices for different site types are on our website.
What happens if you don't build in SEO from the start?
The site will index poorly, load slowly and rank low in search. Then you'll have to rebuild structure, URLs, layout - this can cost as much as half the cost of a new site. Plus loss of search positions during the rebuild.
Do you need to hire a separate SEO specialist if the studio says they'll handle everything?
If the site is simple (landing page, business card with 5 pages) - no, the studio will build in basic requirements. If it's an online store, catalog or portal - better to bring in your own SEO at the structure design stage. The studio will do it technically correctly, and SEO will suggest which sections and URLs are needed for specific queries.