SEO Website Design

I start with a sheet of paper. I draw boxes for every core topic or product category, then connect them with arrows that show how a visitor — or a crawler — would move from the homepage to the deepest piece of content. I enforce a rule: no page more than three clicks from the home page. If a blog post or product detail ends up four clicks deep, I reconsider the category structure. This exercise fixes more SEO problems than any plugin ever could.

Once the information architecture is clear, I choose responsive design. One HTML source that adapts to any screen width. No separate mobile site, no m-dot subdomain. I have seen too many sites lose link equity or screw up canonicalisation because they maintained two versions. Responsive eliminates that headache entirely.

Next I define the URL structure. Short, readable, keyword-bearing. /products/red-widget, not /p?id=123&cat=5. I avoid parameters and numbers where possible. I keep the hierarchy flat: domain.com/category/page rather than domain.com/region/category/subcategory/page. Every extra directory level weakens the perceived importance of the page and makes crawling less efficient.

I then lay out the heading hierarchy. One H1 per page that matches the page title. H2s for major sections, H3s for subsections. I check that the page title and meta description each contain the target keyword naturally, and that the meta description is unique per page.

Internal linking is the next priority. I identify the 5–10 highest-priority pages and make sure every other page on the site links to at least one of them. I use descriptive anchor text — “how to optimise images” rather than “click here”. I also add a breadcrumb trail for navigation clarity. Breadcrumbs help both users and crawlers understand the page’s place in the site.

I set up HTTPS from day one — no excuse for not doing it. I submit an XML [sitemap](/sitemap/) via Search Console and check that the sitemap lists only canonical, indexable URLs. I block thin or duplicate pages in robots.txt or with a noindex [directive](/directive/). I also configure a robots.txt file that allows all important resources (CSS, JS, images) so Google can render the page properly.

Finally I tackle performance. I run a Lighthouse audit on the homepage and a representative content page. I target a Largest Contentful Paint (LCP) under 2.5 seconds, a Cumulative Layout Shift (CLS) under 0.1, and an Interaction to Next Paint (INP) under 200 milliseconds. I compress images, use modern formats (WebP, AVIF), lazy-load below-the-fold content, and remove unused JavaScript. I test on a 3G connection with a mid-range device — that is where real users sit.

The biggest trap I keep seeing is JavaScript-heavy frameworks like React, Vue, or Angular deployed without server-side rendering or static generation. If Google cannot see the content because the page requires JavaScript execution that fails, your pages vanish from the index. I have audited sites where 70% of product pages returned an empty body to Google because the framework rendered everything client-side. The fix: use SSR, pre-rendering, or hybrid rendering. Test every page with the URL Inspection tool in Search Console before you launch.

Second trap: autoplay video or heavy animations. A hero video that starts playing on load can balloon page weight to over 10 MB and push LCP past six seconds. I have watched otherwise well-designed sites lose 40% of their organic traffic after adding a full-screen background video. If you must use video, make it muted, avoid autoplay on desktop, and defer loading until the user scrolls to it.

Third trap: bloated themes and plugins, especially on CMS platforms like WordPress. Many themes load 20+ CSS and JS files for features you never use — sliders, icon libraries, Google Fonts variations. I once trimmed 15 unused plugins from a client’s site and cut page load time from 5.2 seconds to 1.8 seconds. Audit your dependencies before you build.

Fourth trap: ignoring mobile interstitials. Pop-ups that cover the full screen on mobile violate Google’s interstitial guidelines and can trigger a manual action. If you must show a newsletter sign-up, make it a small, dismissible bar that takes up less than 20% of the screen.

Fifth trap: poor canonicalisation or [duplicate content](/duplicate-content/). I have seen e-commerce sites where the same product page was accessible via three different URLs — product.php?id=123, /product/red-widget, and /category/widgets/red-widget. That dilutes link authority and confuses the crawler. Pick one [canonical URL](/canonical-url/) per page and enforce it via the rel=[canonical tag](/canonical-tag/) and internal links. No exceptions.

Sixth trap: overly deep site structure. Even with good internal links, a page four clicks from the homepage gets less crawl budget and lower perceived importance. I reorganised a client’s site from seven levels to three levels and saw their indexation rate jump from 55% to 92% within two weeks.

Early in my career I thought “good design” meant a visually stunning homepage with large hero images, complex layouts, and fancy transitions. I spent weeks perfecting the look and then treated SEO as a last-minute checklist. The result: a site that loaded in 7.8 seconds on a mid-range phone, had no clear heading hierarchy, and used a Flash-based slider that Google could not even render. That site lost ranking for its target terms within three months of launch. I rebuilt it from scratch, and the second version followed the principles I now use: information architecture first, then responsive HTML, then CSS, then JavaScript enhancement.

Another mistake: I ignored the mobile experience because my analytics showed only 20% mobile traffic at the time. I served the same desktop layout but pinched it into a smaller viewport. Buttons were too small, text was unreadable, and Google’s mobile-first indexing penalised the site before I even realised it. I switched to responsive design mid-project — a painful retrofitting job that cost three weeks of development.

I also used to overload URLs with keywords. I thought /best-red-widgets-in-london-2024-buy-now/ would rank better than /products/red-widget. It did not. Google saw spammy paths and the CTR suffered because the URL looked untrustworthy. I now keep URLs under five words and remove stop words.

Finally, I waited until after launch to implement Core Web Vitals optimisation. By then the site was full of uncompressed images, render-blocking scripts, and unnecessary fonts. Fixing those took a month of back-and-forth with the developer. Now I run Lighthouse on the staging environment and refuse to go live until LCP and CLS meet the thresholds. Catching performance issues early saves weeks of work later.