Technical SEO audit and on-page optimisation

What is a technical SEO audit, and why start there?

You have published service pages, articles, perhaps product pages. Yet a search for your own line of business does not bring them up, or it surfaces an old version, a test page, a forgotten PDF. The problem is not always the content. Often, Google simply does not see your pages the way you do.

A technical SEO audit answers one plain question: what stands between your pages and Google's index? It examines how crawlers discover the site, what they receive when they request it, what they decide to index and what they understand of each page. The on-page side carries that work down to page level: title tag, main heading, subheadings, internal links, structured data.

As long as those foundations are fragile, publishing more is like stocking a shop whose door is locked.

Why does a useful page stay invisible on Google?

Before it appears in results, a page goes through four stages. Failing any one of them is enough to keep it out, however good the text.

Search Console often points the way. Its Page indexing report lists excluded URLs with reasons such as "Crawled – currently not indexed" or "Alternate page with proper canonical tag". Each reason calls for a different response, and some are perfectly normal. The audit exists precisely to separate intended exclusions from genuine losses.

What does the audit actually check?

We crawl the entire site with an audit crawler, then cross-check the results against your sitemap, Search Console and, when your host provides them, the server logs. The checks fall into six families:

• Crawling: pages blocked by mistake, 404 and server errors, chained or looping redirects, old http or non-www versions still reachable.
• Indexing: noindex tags, canonical tags, URL parameters and filters that generate duplicates, pages too thin to deserve a place in the index.
• Rendering: whether the main text and links are present in the served HTML, not only after JavaScript runs. Some crawlers, including those of several AI assistants, do not execute scripts.
• Architecture and internal linking: how deep the pages that sell sit, orphan pages, broken links, vague anchors such as "click here".
• On-page markup: unique, descriptive title tags, a single main heading per page, a clear heading hierarchy, meta descriptions, image alt text.
• Structured data and languages: JSON-LD that matches the visible content, reciprocal hreflang tags between language versions, and a mobile version equivalent to desktop, since Google primarily indexes the mobile version (source: Google Search Central).

Speed is part of the diagnosis but has its own workstream: when Core Web Vitals are the issue, we handle them through our performance and Core Web Vitals service.

How do we move from diagnosis to fixes?

A report listing hundreds of alerts in no particular order helps nobody. We tie each issue to its page template, because fixing the "service page" template fixes every page built on it at once. Then we rank the work by impact:

1. Whatever prevents pages that bring in business from being indexed: an offer, a contact page, a category.
2. Whatever scatters signals: duplicates, conflicting canonicals, misdirected redirects.
3. Whatever blurs understanding: generic titles, muddled structure, missing or incorrect structured data.
4. Whatever is merely cosmetic: minor alerts with no measurable effect on your key pages.

Our team also builds websites, and that changes what happens next. On Next.js, we apply the fixes ourselves in your repository. On WordPress or PrestaShop, we work on the theme, the plugins and the configuration. If another provider keeps control, we write precise tickets: the URL concerned, the expected behaviour and how to verify it. Each batch goes through staging, then production, without touching your forms or your analytics.

Finally, we verify: a fresh crawl, fix validation in Search Console, then a review once Google has revisited the pages concerned.

What changes depending on your market?

In Tunisia, many company websites have passed through several successive providers. You find versions living side by side, http and https, with and without www, French and Arabic pages with no link between them, and service pages never connected to the menu. Your customers often browse on their phones, so the mobile version must carry all the content, not a trimmed-down copy.

In Europe, the stakes are often multi-country: one French-language content set for France, Belgium and Switzerland, versions to distinguish without creating duplicates, hreflang to connect properly. We also work white-label for agencies that sell SEO without an in-house developer, on Paris time in winter and one hour apart in summer.

In the Middle East, an Arabic-first site raises its own questions: URLs in Arabic script or transliterated, an aligned English version, an RTL layout that crawlers read correctly. These decisions are best made early, with our multilingual & RTL websites team, because changing them later means redirects.

Do you need Next.js to rank well?

No. A well-configured WordPress or PrestaShop site can be crawled and indexed perfectly well. What matters is that the served HTML contains the text and links, that URLs stay stable and that you keep control over the tags.

Next.js makes that control easier: server-side rendering, metadata defined per template, a sitemap generated from actual content. But switching technology carries a cost and a risk. We only recommend it when the current platform blocks the fixes. In that case, the redesign and migration is prepared URL by URL, following the method in our article on website migration and SEO continuity.

What does technical SEO not do?

It does not replace content. A perfectly indexable site that does not answer your customers' questions will not rank: that is the job of SEO content and topic clusters. Nor does it guarantee any position, because Google alone decides what it ranks.

Some decisions stay with Google. A canonical tag is a hint it may choose not to follow, and valid structured data does not guarantee a rich result (source: Google Search Central). We tell you this before we start. Likewise, crawl budget is only a real concern for very large sites, according to Google: for most SMEs, the problem lies elsewhere.

Finally, a crawler-friendly site is a prerequisite for being cited by AI assistants, not a guarantee. Our GEO guide explains what comes on top.

How do we get started?

Start with the free audit, through the project form. This SEO & GEO audit reviews your key pages, your local presence and your citations in AI assistants, then hands you three written priorities. If the blocker turns out to be technical, the full audit described on this page is then scoped on a quote. For ongoing support, the retainer formulas from our SEO, GEO & local search practice are listed on the Offers page.

To save time, prepare read-only access to Search Console, the list of pages that bring you enquiries, and the name of whoever holds access to the code. Your access stays in your name, and every fix is documented: if we stop working together, nothing leaves with us.