What Makes a Website SEO-Friendly? A Developer Explains

A developer who builds Next.js and Laravel sites and handles post-build SEO work describes how a bug in his own portfolio's FAQ schema mislabeled project industries as countries, illustrating that SEO-friendliness is determined by construction decisions rather than plugins. He outlines practical rules for shallow site structure, stable URLs with redirects, semantic HTML, crawlability and indexability controls, and structured data, and reports that after rebuilding kamrandev.com, Google indexed all 32 pages within a week while Bing had crawled the domain only once during two years of a default WordPress install, leaving pages 'Discovered but not crawled' until he submitted the sitemap and pushed URLs through IndexNow.

Last week I found a bug on my own portfolio. The About page had a FAQ answer that said I'd built websites "for businesses in Computer Vision, Portfolio, Professional Services and International Clients." Those aren't countries. My code was splitting each project's industry label on a dot and treating whatever came after it as a place. Google had already indexed the page, and that answer was sitting inside FAQ schema, ready for any AI assistant to quote. I fixed it in ten minutes. But it's a good example of what "SEO-friendly" actually means, because no plugin would have caught that. It was a construction decision, made badly, by me. So here's my working definition. A website is SEO-friendly when search engines can find every page, understand what each page is about, and serve it fast on a phone. Every part of that is decided while the site is being built. I build web apps and websites for a living, Next.js and Laravel mostly, WordPress when it's the right tool, and for two years I've also done the SEO work that comes after a build. Doing the second job is what taught me what the first job gets wrong. A good structure is shallow. Every page that matters should be reachable within about three clicks of the home page, related pages should sit together, and there should be one page per topic. Two pages about the same thing means Google picks one, and it's often not the one you wanted. URLs should mirror that structure and stay boring: /services/woocommerce-development/ /work/resumaic/ /insights/website-speed-and-seo/ The thing nobody tells you until it hurts: every URL you change later needs a redirect. I've watched a redesign lose a year of rankings because the agency rebuilt the site with new slugs and nobody mapped the old ones. That's not an SEO problem, it's a planning problem. Decide the structure before design starts and you never have to do the migration. Search engines read your HTML, not your screen. One h1 that says what the page is. h2 for the sections. A real nav . Real links. Alt text that actually describes the image. <main <h1 WooCommerce Development</h1 <h2 What I build</h2 <img src="https://dev.to/work/store.webp" alt="Product page for a UK homeware store, built on WooCommerce" / </main Page builders make this very easy to break. Elementor will let you make body text look like a heading, or put five h1 s on one page, and it looks identical in the browser. I've inherited sites like that. The fix is always the same: set the hierarchy on purpose and style it separately. Screen readers navigate by headings too, so you're fixing accessibility at the same time. Crawlability is whether a search engine can fetch the page. Indexability is whether it's allowed to keep it. Both come down to small things: robots.txt , a sitemap, noindex tags, and canonical tags saying which version of a page is the real one. The classic WordPress failure is launching with "Discourage search engines from indexing this site" still ticked. I've seen that box stay checked for months. Mine was subtler. Before I rebuilt kamrandev.com this month, the domain spent two years serving a default WordPress install with a "Hello World" post. Bing crawled that once, decided the domain wasn't worth coming back to, and stopped. When the real site went live, Bing Webmaster Tools showed every page as "Discovered but not crawled." The fix was to submit the sitemap, request the key pages by hand, and push the URLs through IndexNow. Google, by contrast, had all 32 pages indexed inside a week. Two engines, same site, completely different outcomes. Check both consoles, not just one. Structured data is you telling the machine outright: this is a person, this is where he works, these are his other profiles. { "@context": "https://schema.org", "@type": "Person", "name": "Muhammad Kamran", "jobTitle": "Software Developer — AI/ML & Full Stack", "url": "https://kamrandev.com/", "sameAs": "https://www.linkedin.com/in/kamran-professional/", "https://github.com/thekamrandev" } Without that, the search engine has to guess from prose. With it, there's nothing to guess. That matters more now than it did two years ago, because AI answer engines lean on explicit, machine-readable facts when they decide who to cite. A caveat I'd rather say than have you find out: Google stopped showing FAQ rich results in May 2026. So add FAQ markup because it makes the answers easy to extract, not because you'll get dropdowns in the results. And validate everything with the Rich Results Test before launch, because schema that parses as JSON can still be wrong. Ask my About page. Every internal link does two jobs. It helps crawlers find the page, and it tells them how much you think the page matters. A page nothing links to is an orphan, and orphans don't rank. Use anchor text that says what's on the other end. "WooCommerce development", not "click here". Route links from your strongest pages toward the ones you want to rank. And keep the menu small. A navigation with forty links spends your budget on forty things at once. I draw the linking plan next to the sitemap, before writing starts. Sprinkling links in afterwards is how you end up with an orphaned case study you forgot existed. Core Web Vitals are three numbers Google measures from real users: | Metric | What it asks | Good | |---|---|---| | LCP | How fast does the main content show up? | 2.5 s or less | | INP | How fast does the page react to a tap? | 200 ms or less | | CLS | Does the page hold still while loading? | 0.1 or less | Loads fast, reacts fast, stays put. The ranking effect is real but small. The behavioural effect is not small. People leave slow pages before the content renders. And you can't fix that later with a caching plugin, because the weight is in the foundation: the framework, the theme, the plugin count, the image sizes, the hosting. The best number I have on this is OnlineToolPot, a tool platform with 130-plus generated pages that I worked on at Cross Media Sol. Mobile PageSpeed went from about 55 to about 90. Nothing clever. We removed a duplicate icon library, loaded heavy components dynamically, and fixed how fonts were loaded. All build decisions. Google indexes the mobile version of your site. The phone is the version being judged, so test on a real one. Everything above is cheapest on day one. Architecture decided in planning costs nothing extra. Schema added during the build takes an afternoon. Retrofitting either onto a finished site with tangled markup can take longer than the original build did. If you're hiring someone, including me, ask these and expect specific answers: If the answer to any of those is a shrug, that's the answer. I'm Muhammad Kamran, a software developer in Lahore working across AI/ML and the full stack. This post first appeared on kamrandev.com https://kamrandev.com/insights/what-makes-a-website-seo-friendly/ , and the case studies https://kamrandev.com/work/ show how this plays out on real projects, including the ones where I got it wrong first.