DEV Community: Build for Search

Web Development SEO: How to Build Search-Friendly Websites From Day One

Build for Search — Tue, 13 Oct 2026 15:51:04 +0000

SEO often becomes a task that developers hear about near the end of a project.

The website is already designed. The components are built. The pages are connected. Then someone checks the site and discovers missing page titles, broken internal links, duplicate URLs, or content that search engines may struggle to access.

Most of these issues are easier to prevent when SEO is considered during development rather than after launch.

Web development SEO is not about adding keywords everywhere or making a website look different for search engines. It is about building a website that is accessible, technically sound, easy to navigate, and useful to people.

Here are some practical ways to make SEO part of your normal development workflow.

1. Build a Clear URL Structure

A good URL should help users understand where they are going.

Compare these examples:

/services/web-development
/blog/website-performance
/pricing

With a URL that uses unclear parameters for every page:

/page?id=123&cat=7

Query parameters are useful when they serve a real purpose, so they are not automatically bad. However, important content pages should have stable, understandable URLs where possible.

Before building routes, plan the main sections of the website. Decide how service pages, categories, blog posts, and product pages will be organized.

Also make sure that direct visits to nested URLs work. A page should not return an unexpected error simply because someone opens it in a new tab or refreshes the browser.

2. Treat Metadata as Part of the Page Component

Page titles and descriptions should not be forgotten until launch day.

A common problem is using the same title across every route. This makes it harder to describe each page accurately.

For example, a website might have separate pages for services, pricing, and documentation. Each page should have metadata that reflects its own content.

In a React application, you can manage metadata through your framework's route-level features or a suitable metadata library.

A simple example of updating a title in a client-rendered component looks like this:

import { useEffect } from "react";

function ServicesPage() {
useEffect(() => {
document.title = "Services | Example Website";
}, []);

return (

Our Services

Explore the services we provide.

);
}

export default ServicesPage;

This updates the title after the component mounts. If the page needs server-rendered metadata, configure the title through the server-side or framework-level metadata system instead.

The important lesson is to make metadata part of the page implementation, not a task that gets lost before release.

3. Make Navigation Work Without Unnecessary JavaScript

JavaScript can create excellent user experiences, but basic navigation should still behave like navigation.

For example, a standard link provides a clear destination:

Read the performance guide

If you use a client-side routing library, its link component can support smooth navigation while rendering a proper anchor element.

Avoid making every navigation item a generic clickable div. That can create accessibility issues and remove useful browser behavior.

Check that important pages can be reached through internal links. Also test keyboard navigation, link destinations, and direct page access.

A clear navigation structure helps visitors find information and gives crawlers paths to discover your content.

4. Think About Rendering Before Choosing a Framework Setup

A website may display content correctly in a browser but deliver very little useful HTML in its initial response.

This is common in some client-rendered applications.

Search engines can render JavaScript, but rendering introduces extra complexity. Depending on the project, server-side rendering or static generation may make important content easier to access.

For example, a documentation site or blog may benefit from pre-rendered pages because much of its content is available before a user visits.

An internal dashboard may have different requirements because most of its content is available only after login.

Do not choose a rendering method simply because someone says it is better for SEO. Consider the site's content, update frequency, performance needs, and development complexity.

Then inspect representative pages to confirm that important content is delivered as expected.

5. Handle Missing Pages Properly

A website should respond correctly when someone visits a URL that does not exist.

A common issue in single-page applications is that the server returns the main application document for every URL, including missing pages.

The frontend may display a not-found message, but the server can still return 200 OK. This may create a soft 404.

For genuinely missing pages, configure the application and server to return an appropriate 404 Not Found status whenever possible.

For pages that have moved permanently, use a suitable redirect to the relevant replacement.

Test invalid URLs during development instead of discovering these problems after search engines have crawled the site.

6. Add Performance Checks to Your Workflow

Performance affects how people experience a website, especially on mobile devices.

Instead of waiting until launch, test performance while building the site.

Look for large images, unnecessary JavaScript, third-party scripts that delay loading, and layout shifts caused by elements that do not reserve space.

Tools such as browser developer tools and PageSpeed Insights can help identify specific problems.

Google's Core Web Vitals provide useful measurements for loading performance, responsiveness, and visual stability.

You do not need to optimize every part of the site at once. Start with the pages users visit most often and fix the largest issues first.

7. Turn SEO Checks Into a Repeatable Process

One of the easiest ways to avoid repeated mistakes is to add basic SEO checks to your development checklist.

Before releasing a page, confirm that:

The URL is correct and works when opened directly.

The page has a relevant title and description.

The main content is accessible in the expected HTML or rendered output.

Internal links point to valid destinations.

Missing pages return the correct status.

Canonical URLs are set where needed.

Important content is not accidentally blocked from crawling.

The page works well on mobile devices.

For larger projects, you can automate some checks with tests or scripts. For example, a test can visit important routes and verify that each page has a non-empty title.

Automation will not replace a full SEO review, but it can catch simple mistakes before they reach production.

Final Thoughts

Good web development SEO is mostly about making sensible technical decisions early.

Plan your URLs, build useful navigation, manage metadata properly, choose a suitable rendering strategy, and test how the website behaves before launch.

These steps will not guarantee rankings. Search visibility depends on many factors, including content quality, competition, and how search engines evaluate a site.

But they can help you avoid preventable technical problems and create a better experience for users.

For developers, the best time to think about SEO is not after the website is finished. It is while the important technical decisions are still being made.

Technical SEO for Developers: 7 Checks to Make Before Launching a Website

Build for Search — Mon, 12 Oct 2026 16:37:26 +0000

A website can look great, load a modern JavaScript application, and still have a problem that is easy to miss: search engines may not be able to access its most important content.

This is one reason technical SEO matters to developers.

SEO is often treated as a marketing task that starts after a website goes live. In practice, several search-related problems begin much earlier. Routing decisions, page metadata, rendering methods, internal links, and server responses can all affect how a website is discovered and understood.

You do not need to become an SEO expert to avoid common mistakes. A few checks during development can make a website easier to crawl, understand, and maintain.

Here are seven things worth checking before launching a website.

1. Check What the Server Actually Returns

Start with the response from the server, not just what you see in your browser.

A page may look correct after JavaScript runs, but its initial HTML response might contain very little meaningful content. Search engines can process JavaScript, but rendering can add complexity, so important content should not depend on unnecessary client-side work.

You can inspect a response with curl:

curl -I https://example.com/

This shows the response headers, including the HTTP status.

To inspect the returned HTML:

curl -L https://example.com/ -o page.html

Open page.html and check whether the expected title, metadata, and important page content are present.

This does not replace testing in a browser or checking Google's rendering tools. It simply gives you another useful view of what the server sends.

What to look for:

The homepage returns the expected status.

Important URLs do not unexpectedly return errors.

Redirects lead to the intended destination.

The HTML contains useful information where server rendering is expected.

For JavaScript-heavy applications, test representative pages rather than assuming that one successful homepage check means the whole site is healthy.

2. Give Every Important Page a Clear Title

Page titles help describe what a page is about. They also help search engines understand the page and may influence the title shown in search results.

A common problem is that every route uses the same generic title.

For example:

My Website

This does not explain whether the page is about pricing, documentation, a product, or a service.

A better title describes the specific page:

Pricing | Example App

For a site with many routes, titles should be generated from page-specific data rather than copied manually across every page.

In React, you might use a framework or a metadata management solution that supports your rendering setup. If your application uses server-side rendering, make sure the correct title is included in the HTML response.

Also check that important pages have meaningful descriptions and that metadata does not accidentally contain values from the wrong route.

There is no need to force a keyword into every title. Clarity should come first.

3. Make Important Links Real Links

A link that works when clicked is not always implemented in the most accessible or crawl-friendly way.

For navigation between pages, prefer standard anchor elements:

Getting Started

This provides a clear destination and works with normal browser behavior.

Compare that with a clickable element that only triggers JavaScript:

Getting Started

The second example does not behave like a standard link. It also lacks the built-in keyboard and accessibility behavior users expect from links.

Client-side routing is perfectly reasonable. The important part is that your application's navigation still exposes meaningful URLs and usable links.

During testing, check whether:

Important pages can be reached through internal links.

Links have valid destinations.

Browser refresh works on nested routes.

Users can open links in a new tab when appropriate.

Navigation remains usable without relying on a mouse.

Good link structure helps users move through a site and gives crawlers paths to discover pages.

4. Use the Correct HTTP Status Codes

Status codes communicate what happened when a URL was requested.

A few common examples are:

200 OK: The request succeeded.

301 Moved Permanently: The resource has moved permanently.

404 Not Found: The requested resource was not found.

500 Internal Server Error: Something failed on the server.

One issue worth checking is the soft 404.

A soft 404 happens when a page displays a "not found" message but returns a successful status such as 200 OK. Search engines may have trouble distinguishing a real page from a missing one.

For a genuinely missing page, return an appropriate 404 response. If a page has permanently moved to a relevant replacement, use a suitable redirect.

Avoid redirecting every missing URL to the homepage. That usually creates a confusing experience and does not provide a meaningful replacement for the missing content.

If your application uses a frontend router, confirm how unknown routes behave in production. A fallback that serves the app shell for every URL may be normal for some single-page applications, but the final response and rendered behavior still need to be tested carefully.

5. Add a Sitemap and Review robots.txt

A sitemap can help search engines discover important URLs. The robots.txt file gives crawlers instructions about which paths they may request.

They serve different purposes.

A basic robots.txt file might look like this:

User-agent: *
Disallow: /admin/
Sitemap: https://example.com/sitemap.xml

This is only an example. Your actual rules should match your website's structure.

Be careful with broad disallow rules. Accidentally blocking important assets or public pages can create problems.

Also remember that robots.txt is not a reliable way to keep private content private. Sensitive pages should be protected with proper authentication and access controls.

For a sitemap, include canonical, indexable URLs that you actually want search engines to discover. Avoid adding URLs that redirect, return errors, or should not appear in search results.

After deployment, open both files directly and confirm that they return the expected content.

6. Handle Duplicate URLs and Canonical Tags

The same content can sometimes be reached through more than one URL.

For example, a website may expose different versions of a page through URL parameters, trailing slashes, or alternate paths.

Not every variation is automatically a problem, but unnecessary duplicates can make crawling and reporting harder to manage.

A canonical link can indicate the preferred URL for a page:

rel="canonical"
href="https://example.com/docs/getting-started"
/>

The canonical URL should be a real, preferred version of the page. It should not point every page to the homepage.

For websites with dynamic routes, generate canonical URLs carefully. Check that each important page points to the correct destination and that internal links generally use the preferred URL format.

Canonical tags are signals rather than absolute commands, so consistency across redirects, internal links, sitemaps, and page metadata still matters.

7. Test Performance and Mobile Usability

A page that technically works can still be frustrating if it loads slowly or becomes difficult to use on a phone.

Performance testing should be part of development, not just a task for the final week before launch.

Start by checking:

Large images that could be compressed or resized.

JavaScript bundles that include unnecessary code.

Third-party scripts that delay rendering.

Layout shifts caused by images or embedded content without reserved space.

Buttons, navigation, and forms on smaller screens.

Google's Core Web Vitals are useful measurements for real-world user experience. They include loading performance, responsiveness, and visual stability.

You can begin with PageSpeed Insights and then use browser developer tools to investigate the causes of problems.

Do not assume that every website needs the same optimization. A content site, dashboard, and online store may have very different performance bottlenecks.

Measure first, identify the largest issues, and improve them one by one.

A Simple Pre-Launch Checklist

Before releasing a website, run through this list:

Important pages return the expected HTTP status.

Page titles and descriptions match their content.

Main content is available in the expected HTML or rendering output.

Internal links use valid destinations.

Missing pages behave like missing pages.

The sitemap contains the intended URLs.

robots.txt does not block important public content.

Canonical tags point to the correct preferred URLs.

Main pages work on mobile devices.

Performance issues have been checked on representative pages.

Forms, navigation, and redirects work after deployment.

Automated tests can cover many of these checks. Even a small script that verifies status codes and required metadata across important routes can catch problems before users report them.

The key is to include these checks in your normal development workflow rather than treating SEO as a separate project after launch.

Final Thoughts

Technical SEO is not about adding tricks to a website. It is about making sure the website works in a way that users and search engines can understand.

Developers already make decisions about routing, rendering, HTML structure, performance, and server behavior. Those same decisions can influence whether important pages are discovered and interpreted correctly.

You do not need to solve every SEO issue before launch. Start with the basics, test the pages that matter most, and keep checking after deployment.

A useful question to ask during your next code review is simple:

Can a visitor and a search engine both find, load, and understand this page without unnecessary obstacles?

If you make that question part of your development process, you can prevent many avoidable problems before they reach production.