Illustrative scenario: not a client case study
A marketing team noticed that a polished campaign page received little search discovery. The first useful question was not which plugin to buy; it was whether a crawler, a customer and an analyst could all reach and identify the same page.
Start with a representative sample
Choose home, service, location, article, product and contact URLs across both language versions. Test templates as well as individual pages, because one template defect can affect an entire group.
Keep a list of URLs tested, date, device, language and observed response. Repeating the same sample after a release makes change visible.
Check access and status
A page should return the status intended for it, load without a login and not be blocked accidentally by robots rules or a noindex directive. A redirect should lead to the closest relevant destination.
Investigate chains, loops, soft error pages and orphaned URLs. Do not remove a URL merely because it is inconvenient; first understand links, demand and replacement options.
Check identity and duplication
Use one preferred URL for substantially identical content, with canonical signals that agree with internal links and sitemaps. Canonicals are hints, not a substitute for resolving unnecessary duplication.
Review title, heading, language, structured data and visible business details as a set. Conflicting signals deserve a documented decision.
Check rendering and experience
Test key actions on a real mobile viewport, including menus, forms, filters and accordions. Content hidden behind a broken interaction is a customer problem before it is an SEO problem.
Use field experience data when available and laboratory checks for diagnosis. Prioritise changes that help real users, not a score chased in isolation.
Turn findings into a release plan
Classify each issue by affected URLs, customer impact, confidence and implementation cost. Pair a technical fix with a verification step and an owner.
Capture before and after crawls, Search Console examples, logs where available and conversion observations. This prevents a long audit from becoming a forgotten spreadsheet.
Worked example
Illustrative process using the public gnl.agency site: sample the home page, one service page, one insight page, and their Arabic equivalents. Record status, canonical, language links, title, heading, and the next customer action on the review date. This is a repeatable audit example, not a claim about a client result.
What to take away
- Sample templates and language versions, not just the home page.
- Verify status, access, identity and rendering together.
- Treat canonical tags and structured data as coordinated signals.
- Every recommendation needs an owner and a verification method.
Frequently asked questions
Is a technical audit a one time project?
It is a baseline. Recheck after migrations, template changes, releases and major content work, using a stable sample and current evidence.
Should every warning be fixed?
No. Prioritise issues that block access, create misleading pages, harm important journeys or affect many valuable URLs. Document accepted limitations.
Do higher performance scores guarantee visibility?
No. Experience is one part of a wider system. Use scores to diagnose user experience alongside content, relevance, accessibility and business evidence.