Architecture practice SEO
Technical SEO for Architects: Keep the Photography, Lose the Weight
Practice websites are some of the most image-heavy sites on the web, and they are often built for large desktop screens in a studio. Your clients look at them on a phone, on a train, with patchy signal.
- years in SEO
- 6+
- client websites worked on
- 60+
- person doing the work
- 1
Technical SEO for architects: why practice websites are different
Technical SEO for architects covers everything that decides whether search engines can reach, render and index a practice website, and whether its photography loads quickly on a phone. Elsewhere, most technical problems come from scale: thousands of product pages, faceted filters, parameter URLs. A practice website might have fewer than a hundred pages, so its problems come from weight and presentation instead. The hero image on the homepage might be larger than an entire e-commerce category page. Project pages hold dozens of full-resolution photographs. Text is often minimal, set in thin type over images, or loaded by a script after the page appears.
The sites are usually built by designers who care about how the work looks - rightly - and often on platforms chosen for visual control: Squarespace, Wix, WordPress with a portfolio theme, or a bespoke build. Each has typical failure points, and none of them is unfixable without compromising the design.
Search intent matters here too. Someone searching 'loft conversion architect near me' on a phone wants a page that loads quickly and shows relevant work in the first screen. Someone researching 'permitted development rear extension' wants readable text, not a slider. A technical set-up that serves neither is losing visitors before they see a single project.
Key takeaways
- Portfolio images are usually the main cause of poor Core Web Vitals on practice websites, especially Largest Contentful Paint on mobile.
- JavaScript sliders, lightboxes and gallery plugins can hide project text and images from search engines or load every image at once.
- Portfolio themes often create category, tag and archive pages that duplicate project content and dilute internal links.
- Template platforms such as Squarespace and Wix can rank well, but have limits on redirects, markup and image handling that need planning around.
- Practice rebrands and partner changes often trigger domain or platform migrations; without a redirect map, years of project pages lose their rankings.
What's included in my technical SEO for architects
Six parts, each delivered as developer-ready tickets ranked by their likely effect on rankings and enquiries. The table below shows the problems they usually uncover on a practice site.
A crawl and render audit of every template on the practice site
I crawl the whole site and compare it with the XML sitemap and the Search Console indexing report, then compare raw and rendered HTML for each template: home, project-type, project, guide and contact. That shows which projects are buried behind 'load more' buttons and whether captions and descriptions exist before a script runs.
- Full crawl against sitemap and index report
- Raw versus rendered HTML for each template
- Orphaned and buried projects listed
- URL Inspection checks on key project pages
Archive, tag and attachment clean-up so project-type pages lead
Portfolio themes often register a project post type with its own categories, tags and attachment pages, all indexable by default. These thin archives compete with the project-type pages you actually want to rank and spread internal links across pages nobody needs. Each one gets a noindex, merge or removal recommendation.
- Indexable archives and tag pages listed
- Attachment and image-only pages handled
- Duplicates from slashes or capitalisation fixed
- Project-type pages made the real hubs
Image optimisation that keeps photographic quality on every screen
An image audit covers formats, dimensions, file sizes, lazy-loading rules, alt text and file names. Core Web Vitals are reviewed from field data where it exists, plus lab tests on mobile. The aim is the right file for the right screen: the hero loaded first and fast, the gallery deferred, and every image given reserved space.
- WebP or AVIF with responsive sizes
- Hero image prioritised, not lazy-loaded
- Width and height set on every image
- Video and tour embeds behind click-to-load facades
Fixes for WordPress portfolio themes, Squarespace, Wix and bespoke builds
Each platform can rank well and each has habits to watch. Page builders on WordPress add heavy scripts, and image handling depends on plugins and hosting. Squarespace has clean markup but limited control, and redirects are added by hand. Wix needs checking on real phones, not the editor preview. Bespoke and headless builds may send search engines an empty page unless they render on the server.
- WordPress: archive settings, plugins and scripts
- Squarespace: gallery blocks and manual redirects
- Wix: rendered output and mobile vitals
- Headless: server-side rendering or static generation
Structured data that describes the studio, its people and its projects
BreadcrumbList on every page, ProfessionalService for the practice, Person for architects and designers, and ImageObject for key project images. I validate the markup against the visible content and correct it, because schema that claims things the page does not show is worse than none.
- Existing markup validated
- Corrected markup supplied per template
- Credentials described exactly as shown on the page
- Breadcrumbs matched to the site hierarchy
Redirect plans for rebrands, partner changes and platform moves
Partners join or leave, the practice is renamed, the site moves platform, and old project URLs disappear without redirects. Years of rankings and links from design press and award sites then point at pages that no longer exist. Before any move I build a full URL inventory and a one-to-one redirect map; larger moves are covered under SEO migration services.
- Full URL inventory of the current site
- One-to-one redirect map
- Image URLs preserved where possible
- Search Console checks in the weeks after launch
Experience
Technical SEO from someone who has done it many times
You work with me from the first call to the last report. No account managers, no hand-offs to a junior team.
Book a free call- years in SEO
- 6+
- client websites worked on
- 60+
- documented case studies
- 35
More Architecture practice SEO
The other disciplines, written for architecture and design practices.
Keyword Research for architects
Project-type and planning searches mapped to pages, with the protected-title question settled first. UK 'extension' and US 'addition' vocabulary handled separately, scored by project value and catchment rather than volume.
Read moreOn-Page SEO for architects
Project pages that tell the story behind the photographs, project-type pages linked to real work, and titles that use the right professional description. Registration, chartered status and named designers made visible.
Read moreContent Strategy for architects
Planning, permitted development, zoning, building regulations, cost and process guides built around the project types you want, reviewed by your practice and grounded in your own projects.
Read moreLocal SEO for architects
Google Business Profile, Houzz and professional directories set up for a practice that works across a region, with location pages built on real local projects and planning knowledge.
Read moreOff-Page SEO for architects
Awards, design press, collaborator credits, professional directories and client reviews turned into links and consistent listings, within the protected title rules and without paid guest posts.
Read moreThe technical problems I find most often on practice sites
Ordered roughly by how often they appear. The impact column reflects how much each issue typically holds back rankings or enquiries on a site of this kind.
| Issue | Symptom | Fix | Impact |
|---|---|---|---|
| Oversized portfolio images | Slow LCP on mobile; pages several megabytes in size | Serve modern formats such as WebP or AVIF, responsive sizes with srcset, compression tuned per image | High |
| Sliders and galleries loading every image | Long load times, high data use, poor Core Web Vitals | Load the first image eagerly with high fetch priority, lazy-load the rest, avoid autoplay sliders above the fold | High |
| Project text loaded or hidden by JavaScript | Rendered HTML missing captions and descriptions; project pages rank for nothing | Put text in the server-rendered HTML; check with the URL Inspection tool | High |
| Duplicate project archives | Category, tag and filter pages indexed, competing with project-type pages | Noindex or remove thin archives; make project-type pages the real hubs | Medium |
| Images without dimensions | Layout shifts as photographs load, poor CLS | Set width and height or aspect-ratio on every image and embed | Medium |
| Orphaned and buried projects | Older projects only reachable through 'load more' buttons or filters | Crawlable links from project-type pages; paginated archives with real links | Medium |
| Video and 3D tour embeds | Heavy third-party scripts delay interaction and hurt INP | Click-to-load facades for video and virtual tours | Medium |
| Indexed staging or old domains | Duplicate copies of the site in search results | Password-protect staging, redirect or remove old domains | Variable |
Crawl, render, index, understand
I check every site in this order, because a problem at one stage makes everything after it irrelevant.
- 1
Crawl
Can search engines reach every project, project-type and guide page through normal links? Infinite scroll, filter buttons and 'load more' scripts often hide older projects. I crawl the site and compare it with the sitemap and Search Console's indexing report.
- 2
Render
Does the rendered page contain the project text, captions and links, or do they depend on scripts that may not run? Gallery plugins and page builders are the usual suspects. I compare the raw HTML with the rendered version for each template.
- 3
Index
Which pages are indexed, which are excluded and why? Archives, attachment pages, image-only pages and duplicates from trailing slashes or capitalisation often appear here. The goal is an index made of pages that deserve to rank.
- 4
Understand
Does the site make clear what each page is about and how pages relate? Headings, internal links, breadcrumbs and structured data tell search engines that a page is a loft conversion project in a particular town, linked to the practice's loft conversion page.
Free review
Get a free Technical SEO review
Send me your site. Before the call I look at your rankings and pages, then tell you what I would fix first and what it is likely worth.
Core Web Vitals on a studio's image-led pages
The three Core Web Vitals - Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift - all suffer on portfolio sites, for predictable reasons.
LCP is usually the hero photograph. It needs to be served at the size the screen actually needs, in a modern format, without lazy loading, and ideally preloaded or given high fetch priority. A common mistake is lazy-loading every image including the first, which delays the very image that LCP measures.
INP suffers from heavy scripts: gallery libraries, animation frameworks, cookie banners, chat widgets and Instagram feeds. Each one competes for the main thread when the visitor tries to open a menu or tap through a gallery. I check which scripts are actually needed and defer the rest.
CLS comes from images and embeds without reserved space, and from web fonts that swap late. Setting dimensions on every image and using sensible font-loading rules usually fixes it.
None of this requires lower-quality photography. It requires the right file for the right screen. A phone does not need the same image file as a large studio monitor, and responsive images let each device download only what it needs.
Where SEO meets CRO
A slow portfolio loses the client before it impresses them
Architecture is a visual sale, so it is tempting to think heavy images are worth the wait. They are not, if the visitor leaves before the first image appears. Faster project pages keep more visitors long enough to see the work, and a fast, stable enquiry form - one that does not shift as images load around it - is easier to complete on a phone. I treat speed on project-type and project pages as a conversion task as much as a ranking one.
Site architecture for a design practice portfolio
The architecture I recommend mirrors how clients search: project-type pages at the top level, projects beneath them, guides in their own section linking across. Projects can belong to more than one type, but each should have one canonical URL. Flat portfolio grids with filters replace this structure with JavaScript, and search engines lose the relationships between pages.
Where technical work connects
Technical fixes protect the value of everything else. The page structure they support comes from keyword research for architects, the templates being sped up are specified in on-page SEO, and the links earned through off-page SEO only help if the pages they point at still exist after a migration.
For the overview of how this fits together for a practice, see SEO for architecture practices.
Growth from real projects
Learn more about technical seo
Technical SEO in other industries
Technical SEO for Architects FAQs
Will optimising images reduce the quality of our photography?
Not visibly, if it is done properly. The aim is to serve each device an image at the size it actually displays, in an efficient format, with compression tuned so the difference cannot be seen. A phone screen does not need a file prepared for a large print. Your original files stay untouched.
Does technical SEO for architects work on Squarespace or Wix?
No. Both can rank well for a practice website. They do limit some technical control, such as certain markup and redirect handling, and their gallery features can hide text or load too many images. The platform matters less than how the pages are built and how much useful text they contain.
Should we lazy-load all our images?
No. Lazy-load images below the first screen, but load the first visible image, usually the hero, straight away and with high priority. Lazy-loading the hero delays the element that Largest Contentful Paint measures, which is one of the most common Core Web Vitals mistakes on portfolio sites.
Do we need an image sitemap?
It helps on sites where images are loaded by scripts or sit in galleries that search engines may not discover through normal crawling. If your images are in standard HTML on crawlable pages, it matters less. I check whether your key project images are being indexed before recommending one.
We are rebranding the practice. What should we do about SEO?
Plan the redirects before the new site goes live. List every existing URL, especially project pages that have links from press and award sites, and map each one to its new equivalent. Keep the old domain registered and redirecting for the long term, and monitor Search Console closely for several weeks after launch.
How do you check whether Google can see our project text?
I use the URL Inspection tool in Search Console to view the rendered page, and compare the raw HTML with what a browser shows. If captions or descriptions only appear after a script runs, or sit inside a lightbox that is never opened, they may not count. The fix is usually to put the text in the page itself.
See what technical SEO for architects would fix on your portfolio
Send me your website address. On a free 30-minute call I will walk through how your project pages load on a phone, what search engines can see on them, and which fixes would make the most difference.