Building · Checks · SEO · GEO · AI agents · Express production · Timelines and constraints · FAQ
Updated: 12 October 2026.
How a site is built
For the projects we develop and deploy end to end, we follow the same six building practices. They aim to prevent a change from causing a fault that goes unnoticed, and to make it possible to return to the previous version.
Custom development
PHP 8 prepares the pages on the server. JavaScript handles interactions in the browser, without a framework, that is, without a prebuilt software scaffold. Hand-written CSS defines the presentation. MySQL stores the data. No purchased theme and no pile of plugins.
In plain terms: the page loads only the scripts and styles it uses. The page is generally lighter. There are fewer third-party components to monitor and update, and no plugin licence to renew.
Change history with Git
Every change is recorded in a Git repository, with its date and its reason.
In plain terms: Git keeps the complete history of the code and makes its earlier versions retrievable. If a change causes a problem, the previous version of the code is put back online. Data (content, accounts, orders) is stored in the database and has its own backups.
Protected staging
Each site has a second address, protected by an access code, where we develop it and where you approve it.
In plain terms: it is a dress rehearsal. The public never sees work in progress, and you see the real result, on your phone, before it goes live.
Automated deployment
Going live is carried out by a script, always the same one, from the repository: the server receives exactly the version of the code chosen from the history.
In plain terms: nobody drops files onto the server by hand. What is online corresponds exactly to a recorded version in the history, which can be reread and compared.
Content in the database
The content you will edit yourself (text, news, product or service listings) is stored in the database, separately from the site’s files.
In plain terms: you update your content without waiting for anyone, and deploying the code does not touch the database: a new version of the site does not replace your text.
Backup before the first release
Before the first release on your hosting, whatever is already there is backed up and kept for 90 days.
In plain terms: the items already on the server remain recoverable, even those we did not know existed.
What we check, point by point
Our checklist has around thirty items. Each one corresponds to a fault we have actually encountered at least once and do not want to see again.
301 redirects and canonical URL
One address per page: no “www”, no “.php”, no trailing slash. The other forms point to it through a
permanent redirect (HTTP code 301), and the page declares its official address
(canonical tag).
In plain terms: Google receives a clear signal about which address to keep, instead of seeing several copies of the same page. Old addresses that are already known keep leading to the right place.
W3C validation
The HTML and CSS of every page go through the validator of the W3C, the body that writes the web’s standards. Target: zero errors.
In plain terms: it is a spell-check for code. It is not a Google ranking factor and it does not judge the quality of a page, but valid code reduces display differences from one browser to another and leaves less ambiguity for crawlers.
Performance: PageSpeed and Core Web Vitals
We measure speed with PageSpeed Insights, on phone and on desktop. The tool provides a simulated test and, where enough data exists, measurements collected from Chrome users. These include the Core Web Vitals: time to display the main content, layout stability and responsiveness.
In plain terms: the simulated test is for fixing, the real measurements decide. On our sites, the phone almost always gets the lower score: a perfect desktop score is not enough.
Measured contrast (WCAG)
The contrast ratio between each text and its background is calculated. The WCAG accessibility guidelines require 4.5 to 1 for body text and 3 to 1 for large text; we aim for 4.5 everywhere.
In plain terms: a colour can be attractive and unreadable. We have seen it happen: a gold on a cream background measured 2.09 to 1. On a well-calibrated screen, it does not always show; on a phone in daylight, it does.
HTTPS and certificate
The TLS certificate must cover the address with and without “www”. After launch, its expiry date is monitored continuously.
In plain terms: the certificate lets the browser verify the server’s identity and encrypt the connection. An invalid or expired certificate triggers a security warning. Its expiry date is known in advance: it has to be monitored to avoid an outage.
Form sending and receipt tested
A message is actually sent from the live site, and its receipt is checked. The protections against spam bots are invisible to visitors.
In plain terms: a form that displays is not a form that works. The decisive test is a message actually received.
We also check the actual display with screenshots at two widths (phone and large screen),
the 404 error page, the robots.txt file, the sitemap (sitemap.xml) and
that no “demo” mention remains on the final site.
Being found on Google
SEO (Search Engine Optimization) covers everything that helps a search engine understand a page and show it to the right people, without paying for advertising.
Studying searches before writing
We study what people search for using search suggestions, volumes and competition. We target the long tail — precise, less frequent queries — and look at the intent behind them: looking for information, comparing or buying.
In plain terms: “agence de communication Paris” is contested by hundreds of players. When we surveyed it, “vidéo témoignage client” (customer testimonial video) was far less so, and the person typing that search is already describing a precise need.
One page, one intent
Each page answers one precise question. Its title (title), its description
(meta description) and its section headings (h1, h2…) all address
the same subject.
In plain terms: the title shown in Google, the main heading of the page and its content answer the same question.
JSON-LD structured data
We add a machine-readable summary to the code, using the Schema.org vocabulary: who you are, what you offer, where, and the frequently asked questions. Strict rule: this summary says nothing the page does not show.
In plain terms: it is an identity card slipped into the page for crawlers. An invented review rating, or one borrowed from another business, would be misleading there: we do not declare any.
Submitting and measuring
The site is verified in Google Search Console and Bing Webmaster Tools, and its sitemap is submitted there. On our sites, every release also notifies Bing and the engines that follow the IndexNow protocol (Google does not take part). Rankings are then tracked over time.
In plain terms: we declare the site, notify the engines that allow it of its updates, and track how its positions in search results change.
Being cited by AI assistants
GEO stands for Generative Engine Optimization. A growing share of searches goes through an assistant (ChatGPT, Gemini, Perplexity, Claude) that writes an answer instead of displaying a list of links. GEO aims for your pages to be among the sources of that answer. Being accessible to crawlers, being indexed, being selected as a source and being cited are four distinct steps: none guarantees the next.
Opening the door to assistant crawlers
The robots.txt file explicitly allows assistant crawlers, which do not all play the
same role. OAI-SearchBot and PerplexityBot read pages for search-based answers; GPTBot and
ClaudeBot collect content for model training; Google-Extended and Applebot-Extended read nothing
themselves: they are usage permissions granted to Google’s and Apple’s AI.
In plain terms: allowing search crawlers lets them consult the pages, without guaranteeing that they will be cited. Permission to use the content for training is separate; we grant it for our own sites.
An llms.txt file
At the root of the site, a text file summarises the company, its services, its figures and the list of pages, in a format designed for language models.
In plain terms: it is the introduction you would hand to a new colleague. The format is recent: its effect on citations has not been demonstrated, and Google states that it does not need it. We publish it because it costs little and sums up the essentials.
Facts rather than adjectives
We write short, quantified, verifiable answers: a date, a floor area, a lead time, an entry price. Frequently asked questions are marked up as structured data.
In plain terms: “9 studios, 630 m², since 2008” gives precise information that can be reused and checked. “A passionate, renowned team” points to no achievement and no concrete result.
Tracking visits and citations
We track the share of visits coming from an assistant and repeat a series of 20 industry questions to record the sources cited in the answers written by a language model.
In plain terms: on our studio rental site, our October 2026 review counted 5.8% of visits coming from an AI assistant (98% of them from ChatGPT), and the site appeared in 7 of the 20 simulated answers. These two surveys serve as a baseline; we repeat them every three months, under the same conditions.
How we build a tool
Business applications and artificial intelligence agents follow the same principles of building, checking and monitoring.
A script first
Whatever can be programmed deterministically is: same input, same result. AI only comes in where judgement is needed. In plain terms: fewer paid calls to a model, fewer surprises, and a tool whose every line can be read and corrected.
Open controls
The AI drives the tool from the outside, through an API — a command interface whose access is protected by a key — or through an MCP (Model Context Protocol) server, which presents these commands according to an open protocol. In plain terms: on our internal tools, we have changed AI provider with a setting, without rewriting the tool.
A preview before writing
Before any change to your data, the tool presents the planned changes. In plain terms: automation does not work silently; an error can be spotted before it is applied.
Testing the real journey
Our automated tests open a real browser, click, type and check the screen. In plain terms: we test the user’s journey, in addition to how each function works on its own.
⚡ Express production, a project at your pace
- 1 Conversation with your project lead You and your project lead clarify your goals, your needs and your first ideas.
- 2 Specification and agreement Scope, schedule and price are set out in the signed quote.
- 3 ⚡ Express technical production We build, test and fix the first version within the agreed scope.
- 4 V1 delivered You receive a first version to review before it goes live.
- 5 ❓ Review at your own pace Your project lead helps you put your feedback into words, whenever you are ready.
- 6 ⚡ Revisions produced Revisions are usually made within 24 hours, depending on what they involve.
- 7 V2 delivered You receive the corrected version to check the changes.
- 8 ❓ Further review if needed With your project lead, you pin down the final adjustments; the cycle repeats if needed.
- 9 Final delivery You approve the version that will go live.
- 10 ⚡ Go-live We run the final checks and publish, subject to external technical lead times.
Our technical production is express ⚡; how long the project takes also depends on its scope and on the exchanges along the way. The project can move at express speed if you do: quick feedback lets the stages follow one another without delay. If you need time to think, we follow your pace. Your project lead is with you from the first conversation and at every review.
Prototype, staging, production. A prototype shows an idea: it is made quickly and serves only to decide. Staging is the real, complete site, at a protected address, where you approve it. Going into production publishes that approved version at the public address, after the technical checks.
Time, debugging, impact, cost and reliability
Express production, adapted schedule. Once the specification is set and the content is available, technical production can move forward in a few hours or a few days depending on the scope. The project can extend over several weeks when several exchanges and approvals are needed. Your project lead supports you through these stages at your pace. Technical checks and your approval remain necessary before publication. Some stages do not depend on us: during our launches, issuing a certificate took about an hour, and propagating a DNS configuration change can take up to 48 hours.
Debugging. All new software has faults nobody has seen yet. We build debugging into the schedule and examine the whole journey, beyond the single problem reported: a fault fixed in one place can still show up elsewhere.
Impact. Search rankings are measured in months. We cannot announce how long it will take for AI assistants to take a change into account. We track the figures and show them to you, including when they have not moved yet.
Cost. It depends more on what the site has to do (payment, booking, client area, several languages) than on the number of pages. The number of days is estimated at scoping and written into the quote. See the budget guide.
Reliability. No site is immune to an outage. Our live sites are checked every fifteen minutes (availability, certificate, signs of hacking), and the quality of every page is measured again each night. The aim is not that no incident ever happens: it is to spot it and deal with it as early as possible.
Method, SEO and GEO — frequently asked questions
What is GEO, and how does it differ from SEO?
How long does it take for a site to rank well?
Can you guarantee a top position on Google or a citation by ChatGPT?
Why plan a debugging phase?
Can you build a website in 24 hours?
Does accelerated delivery mean fewer checks?
Do you use AI to develop faster?
How do you measure visits and citations coming from AI assistants?
What does a project built with this method cost?
A site or a tool to build?
Describe what the site should let your visitors or your team do. We reply within 24 business hours with an initial analysis of the project: what is simple, what will take time and what we would advise against.
Monday to Friday, 9am – 7pm · shoots and sessions around the clock, by appointment · studioleizart@gmail.com