Architect Website: Project Descriptions and Service Pages Written With AI

Give the AI facts you can verify about each project (the brief, the constraints, what you decided and why, the outcome), not adjectives. Use one repeatable pattern for project pages, one service page per project type you want more of, and an FAQ on fees and process. Edit every page for accuracy and voice before it goes live.

Many practice websites are galleries with captions, and the first AI-written ones can look worse: the same "stunning, bespoke, light-filled" adjectives on every page, awards that do not exist, and a page for every town you could conceivably serve. A visitor scanning for proof that you have done their kind of project finds none of it. The fix is to write from the practice's own facts, and to decide before opening a chat window which clients each page is meant to bring in.

Follow me on Instagram@sagnikteaches

Decide which clients the site should bring in

Start with two lists on one sheet of paper: the projects you want more of, and the ones you would rather not take. For an illustrative three-person practice the first list is house extensions and whole-house refurbishments for owner-occupiers with a mid-range budget, plus small mixed-use conversions. The second is one-off garden buildings and jobs so small that the fee cannot cover a proper service. Every page you write should pull towards the first list and quietly filter out the second.

Connect on LinkedInSagnik Bhattacharya

That gives you a page set, and it is smaller than you might expect:

Subscribe on YouTube@sagnikteaches

A set of 12 to 18 pages that are all true will usually serve you better than 60 thin ones, and it is a set you can keep current. Treat the numbers as a starting size, not a target.

Collect facts before you open the chat window

The assistant writes well from facts and badly from vibes. A ten-minute voice note per project, answering the same eight questions, beats staring at a blank page:

1. What did the client ask for, in their words?
2. What made the site or the brief difficult?
3. Which three design decisions mattered most, and why did you make each?
4. What did you try and drop?
5. What would a visitor miss in the photographs?
6. Programme and budget band, only if the client is happy to share them.
7. What changed on site?
8. What did the client say afterwards? Use a real quote only, and only with permission.

Transcribe the note, tidy it into a one-page fact sheet, and add the boring fields: project type, floor area added or refurbished, completion year, your role (concept only, or full service), consultants, photographer and licence. Add a final line that is easy to forget: "Client has agreed to publication: yes or no, and whether the address may be named." If the answer is no or unclear, the project waits. A good page that the client later asks you to remove costs more than the one you did not write.

The same caution applies to client data and images generally; the copyright and client data tutorial explains where the risks sit before a photograph or a brief goes into an AI tool.

A project description pattern the AI can follow

A pattern turns six projects into six pages that read as a set without sounding identical. This one runs to roughly 400 words and has seven parts: a headline of up to 70 characters (project type plus one distinctive fact); a 45 to 55 word lead saying who it was for, what you did and the one thing that made it hard; the brief in 60 to 80 words; the constraint in 60 to 80; what you did in 100 to 150, built around three decisions with a reason each; the result in 50 to 80 words, facts only; and a fact box. This prompt applies it.

Write a project page for an architecture practice's website, in plain English
with our usual spelling, using "we". Use ONLY the facts below. If you need a fact that is not
there, write [MISSING: what you need] instead of guessing. Do not write awards,
quotes, dimensions, orientations or materials that are not in the facts.
Avoid the words stunning, bespoke, iconic and light-filled.

Pattern:
1. Headline, max 70 characters: project type plus one distinctive fact.
2. Lead, 45-55 words: who it was for, what we did, the one thing that made it hard.
3. The brief, 60-80 words, using the client's own words where given.
4. The constraint, 60-80 words.
5. What we did, 100-150 words: three decisions, each with its reason.
6. Result, 50-80 words: facts only.
7. Fact box: type, size, completed, our role, consultants, photographer.

FACTS:
- Type: rear extension to a two-storey family house
- Client: family of four, owner-occupiers
- Brief, in their words: "We spend every evening in the kitchen and can't see the garden from it."
- Constraint: garden only 3.2 m wide beside a shared boundary wall; neighbour's
  light; one mature tree to keep
- Decisions: (1) kitchen moved to the back with glazed doors to the garden;
  (2) extension stepped back 600 mm from the boundary to limit the effect on the
  neighbour; (3) kitchen floor lowered 150 mm to meet the garden level
- Result: 28 m2 added; completed 2025
- Our role: full service, concept to completion
- Consultants: structural engineer
- Photographer: [name], licence for web use

A typical first draft opens: "Headline: Award-winning rear extension that gives a narrow house a south-facing kitchen. Lead: A family of four asked us to turn a dark, cramped kitchen into the heart of their home..." Three things in those two lines are not in the facts: "award-winning", "south-facing" and "dark, cramped". The assistant added them because they are the usual furniture of an architect's project page. Strike each, or replace it with something true.

The fixes you make on almost every draft:

• Remove invented praise and orientation. If it is not in the fact sheet, it does not go in.
• Check every number against the sheet. The draft may round 600 mm to "about half a metre" or convert 28 m² into square feet with a different result.
• Turn adjectives into decisions. "Thoughtfully designed" becomes "We stepped the extension back 600 mm from the boundary so the neighbour's kitchen window keeps its light."
• Check the headline against the lead. The two should not promise different things.
• Read the result paragraph for outcomes you cannot prove. "The family now enjoy evenings in the garden" is the kind of line that needs a client quote or a deletion.

Expect three or four [MISSING] tags in each draft. They are the assistant being honest about gaps: fill them from your notes or delete the sentence that needed them. A draft with no [MISSING] tags at all deserves suspicion, because it probably filled the gaps itself.

The pattern flexes for other project types. A second, shorter illustration, with made-up facts, is the conversion of a former shop. The result paragraph an assistant produces unprompted is "The transformed space is now a vibrant, welcoming hub for the community." The version built from facts reads: "The former shop now holds a 46 m² ground-floor studio and a one-bedroom flat above, with separate entrances. We moved the flat's kitchen to the front so the studio keeps its rear daylight. Completed 2024." Same project, but the second version tells a prospective client what you can do and what you decided.

The assistant's draft takes about five minutes; the edit is where the page becomes yours. For case studies aimed at LinkedIn as well as the website, the tutorial on case studies, website copy and LinkedIn covers the second channel.

Keeping your own voice across a dozen pages

Pages written from one prompt drift towards the same cadence: tidy sentences, a mild sense of wonder, three adjectives to a noun. Two habits keep the voice yours. First, give the assistant three paragraphs you wrote yourself, from an old proposal or an email to a client you got on well with, and ask it to describe the style in five bullet points: sentence length, level of formality, how you explain a technical point. Keep those bullets as a short style note and paste them under the main prompt. Second, keep a list of words the practice uses and words it never does. A "never" list for the practice in this tutorial might read stunning, bespoke, iconic, light-filled, curated and journey.

Then read every page aloud. If you would not say a sentence to a client across a table, change it. Reading aloud also catches the shared rhythm that gives machine writing away: three-item lists, a short punchy line after each paragraph, and an opening that announces the topic. Cut the pattern wherever you hear it.

Service pages by project type

Clients search for what they want done ("house extension architect"), not for your practice name, so each project type you want more of gets its own service page. The skeleton is the same every time: who the service is for and who it is not for; what the work involves, in stages; what affects cost and time; two or three projects that show it; how a project starts; and three to five FAQ entries.

The generic version could sit on any practice's site: "We offer a full range of architectural services including design, planning and project management tailored to your needs." It says nothing a competitor could not say. The specific version, written from your own process, reads differently: "For a house extension we start with a measured survey and two sketch options, take one into detailed design, and prepare the drawings for approvals and tender. The first month usually settles three things: how far to extend, where the kitchen goes, and whether the roof is flat or pitched."

Plan the set as a table before you write any of it:

The "not for" column is the filter. It saves you enquiries you would decline and it makes the right clients feel recognised. Feed the assistant your stage descriptions and your own FAQ answers, tell it to write no fee numbers and no timescales unless you supply them, and ask for the "who it is not for" paragraph explicitly, because it will skip it otherwise.

Area pages: write one only if it passes the test

Area pages are where AI can do the most damage, fastest. It is easy to produce 40 pages that differ only by the place name, and Google's own spam policies describe exactly that pattern. The spam policies page (updated 28 August 2026) lists "using generative AI tools or other similar tools to generate many pages without adding value for users" under scaled content abuse, and lists pages targeted at specific regions or cities that funnel users to one page under doorway abuse. Google's guidance on generative AI content adds that generative models "don't retrieve facts, but predict a likely sequence of words", and that it is critical to fact-check and review everything they produce.

So an area page needs a test. Publish one only if the answer to all five questions is yes:

1. Have we completed at least two projects in [area]?
2. Do we know something about working there that comes from those projects, not from a search?
3. Would the page still be useful to a visitor if the place name were hidden?
4. Would it read differently if [area] were swapped for another?
5. Have we checked every fact on it?

Build the guard into the prompt: "Use only the project facts supplied. If fewer than two projects are provided, reply 'Do not write this page' and stop." An assistant that is told it may refuse is less likely to invent. Cap the whole set at three area pages until you have more work to write about, and keep the rest of the site pointing at the projects themselves.

A fees and process FAQ that filters the right enquiries

An FAQ on fees and process does two jobs: it answers what visitors would otherwise email you about, and it quietly sets expectations on price and pace. Source the questions from real enquiries. Paste your last 20 enquiry emails with names removed into the assistant and ask it to list every question asked, grouped by theme and ranked by how often it appears. Then answer from your own fee proposal and process notes, not from the assistant's general knowledge. The tutorial on fee proposals and briefs shows how to keep that source material tidy.

Here are three entries, with square brackets where your own terms belong:

• How are your fees calculated? "[Fixed fee for each stage / a percentage of construction cost / hourly], chosen according to [what you actually do]. We confirm the fee in writing after a first conversation, and it moves with [size, complexity, the consultants needed and how much the brief changes]."
• What is not included? "Unless our fee proposal lists them, application fees, surveys and specialist consultants' fees are paid separately. We list them early so there are no surprises."
• What do you need from me at the start? "A short description of what you want, what you can spend, and any drawings or surveys you already hold. We use them to decide whether we are the right practice for the job, and say so if we are not."

Do not publish a number you will not honour. If you want to give a range, attach the conditions that move it. The decision about what to publish is yours; the assistant can only tidy the wording.

A word on markup: Google's documentation records that FAQ rich results "will no longer appear in Google Search starting May 7, 2026", and the documentation page for them was removed on 15 June 2026. Write the FAQ for readers. Likewise, Google's page on AI features and your website says there are "no additional requirements" for appearing in AI Overviews or AI Mode and no special files or markup to add; the page needs to be indexed and eligible to be shown with a snippet. That is a reason to spend your time on facts instead of tricks. If you want the same answers delivered in conversation, the AI chatbot tutorial for fee and process questions reuses this material.

Titles, descriptions and alt text without the filler

Google's guidance on AI content tells site owners to review metadata too: titles, meta descriptions, structured data and image alt text. Ask the assistant for three options of each and choose, because it tends to stuff keywords.

Alt text should describe what a visitor who cannot see the picture needs to know. Check that the "weak" column never creeps back in: "award-winning" in a meta description is a claim, and it needs the same proof as on the page.

Images and claims to check before publishing

Before any page goes live, run it past five checks. Does the client permit publication, and the naming of the address? Do you hold a licence from the photographer, and is the credit right? Are concept images labelled as concepts, and are none of them AI-generated pictures presented as built work? If you use AI concept images in client meetings, the tutorial on AI concept images for client meetings covers how to label them. Is every award, publication and testimonial real and attributable? And does the way you describe yourself and your services follow whatever your professional body expects? Rules on titles and advertising differ and change, so read yours rather than trusting an AI summary.

A two-week plan for a small practice

Here is the whole job for a practice with six projects to write up, with estimated hours:

About 20 hours over two weeks is a realistic one-off effort. The page set then needs about an hour a month: a new project page when one completes, and a re-read of the FAQ against the latest enquiries.

Put three reminders in the diary to keep it current. A quarterly 15-minute check that the fees, process and team details on the service pages still match what you do. An annual re-read of every project page for claims that have aged, such as who still works at the practice and which consultants you still use. And a periodic re-check of the Google pages this tutorial quotes, because spam rules and search features change. Date the review on the fact sheet rather than on the page, so you can see at a glance what is stale.

Checking that the right clients arrive

Add two fields to the enquiry form: what the visitor plans to do, and how they found you. After 12 weeks, sort the enquiries into three piles: right fit, too small, and outside what you do. If, out of 14 enquiries, 9 are the right fit, 3 are too small and 2 are outside your services, the site is working and the "too small" pile suggests tightening the fees page. If most are outside your services, the "who it is not for" lines on the service pages are not doing their job.

The site will not do the whole job without a reply process behind it. What happens to an enquiry in the first hour is covered in the enquiry to fee invoice tutorial. Keep the habit of reading each new page aloud before publication: the sentences that make you wince are often the ones the assistant wrote and you did not check.

Questions about writing an architect's website with AI

Should my site have a news or journal section?

Only if you will keep it going. A section that stops after two entries looks abandoned and adds nothing. A better use of the same effort is a new project page each time a job completes, with real photographs and decisions. If you do publish articles, write them from your own experience on a question that clients actually ask you.

Should I let AI write my About page and team biographies?

Write the facts yourself (who does what, qualifications, years in practice, what each person leads) and let the assistant only tidy the wording. Every claim about a person must be accurate and agreed by them. Avoid statements the person would not make themselves, and check anything about registration or titles against your professional body's rules.

How do I get cited by AI assistants and AI Overviews?

Nobody can promise it. Google says there are no special requirements or markup beyond being indexed and eligible to show with a snippet, so the practical work is accurate, clear, specific pages. Check that your robots.txt does not block search crawlers you want, such as OpenAI's OAI-SearchBot; GPTBot is a separate crawler, used for training.

Should I tell visitors that AI helped draft the copy?

Google's guidance on generative AI content says that sharing how a piece of content was created can give readers more context. On a practice website, what matters more is that you stand behind every page and that its facts are checked. Look at whether your professional body or client contracts say anything about disclosure.

Further reads

• AI Marketing Tools for Small Businesses: A Shopfitter's Case Study Pages — Case study pages built from job facts, shown for a neighbouring trade.
• AI Marketing for a Construction Company: Case Studies, Bids and LinkedIn — Case studies, bids and LinkedIn from a construction firm's point of view.
• AI Tools for Architects 2026: A Toolkit From Brief to Handover — A toolkit organised by project stage, from brief to handover.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Google Search Central pages on spam policies (updated 28 August 2026), using generative AI content (updated 1 October 2026), AI features and your website, and the FAQ structured data deprecation notice. Checked October 2026.