I check what the server sends and what a crawler sees after JavaScript runs. I turn what is wrong into tickets for your developer. After the release I measure again, with a date on every change.
Technical SEO makes sure Google can find, read and index your pages. It covers the HTML the server sends, status codes, redirects, canonicals, hreflang, structured data and the sitemap.
Content and links only help once that base is right. A mistake in a template can quickly end up on hundreds of pages at once.
As a technical SEO specialist I work next to your developer or builder. I describe what is wrong, how to reproduce it and how we check that the fix works.
You have your own developers, but nobody who guards SEO in every release. I deliver tickets that fit your sprint and check after the release.
With a custom build in React, Astro or PHP, no standard plugin handles SEO for you. Titles, canonicals and schema have to live in the templates.
In a migration the domain, the platform or the design changes. I make sure existing addresses keep working and check redirects and canonicals before and after launch.
An app in the browser can change titles and tags after the server has sent them. I compare the raw HTML with the page after rendering.
Hreflang, language folders and the lang attribute have to be right in every language. A mistake in the template repeats itself in all of them.
In 15 minutes we discuss your site, your platform and what is going on. I will tell you honestly whether technical SEO is the right step now.
I fetch the raw HTML with curl and crawl the site with JavaScript on. That shows what the server sends and what a crawler sees after rendering, which is closer to what Google indexes.
Every issue gets a ticket with the cause, a reproduction and the URLs where it occurs. I put them in order of impact.
After the release I crawl again with the same settings. I write down the date of every change and report what is still open.
A crawl in two layers: the raw HTML from the server and the page after JavaScript.
A list of issues in order of impact, with the number of pages per issue.
Tickets for your developer with the cause, a reproduction and how we check the fix.
For a migration: a list of addresses that stay or get a 301. Then a check of the test site and a live check after launch.
A structured-data setup per page type, in the HTML the server sends.
A follow-up measurement after the release, with a date and a source for every figure.
0 of 1,228 Indexable pages with only the brand name as the title after JavaScript ran, on 2 October 2026. On 31 August it was 1,139 of 1,164. A JavaScript app overwrote, in the browser, the correct title the server had already sent. It also added a second canonical and a second set of hreflang tags. I sent the developer a ticket with a reproduction and the fixes went live on 13 September. The crawl of 2 October found one canonical on every page and six hreflang tags on 1,224 of 1,228 pages. Source: two Screaming Frog crawls with JavaScript on, 31 August and 2 October 2026. Still open on 29 October 2026: the homepage and the dish pages show almost nothing without JavaScript. Period: June to October 2026.
View case3 of 3 Old shortcuts that redirect with a 301 to the right page, checked with curl on 29 October 2026. When the site moved to a new custom build, existing addresses and links had to keep working. I wrote the SEO brief and made the design. The studio phi.studio built the site. Existing pages kept the same address. /booking was a 301 to Treatwell and became its own page with status 200. All 55 deeplinks on /massages returned status 200 with a canonical to /booking, so Google sees one booking page. This case makes no statement about traffic or rankings. Sources: Screaming Frog crawl of 1 October 2026 and of the test site on 8 October 2026; curl, 29 October 2026. Period: from 29 September 2026.
View case60 of 60 HTML pages set to index, follow in the Screaming Frog crawl of 5 October 2026. My report of 13 February 2026 records that the site had been set to noindex. On 28 December 2025 the homepage carousel carried six H1 tags. That day I sent the developer three changes: one H1 per page and URLs without .php. The third covered the HTML attributes that Google Tag Manager needs. The crawl of 5 October found one H1 on each of the 60 pages. An external developer rebuilt the site from WordPress to PHP. On 28 September 2025 the site still ran on WordPress, and PageSpeed Insights gave a mobile layout shift of 1.005. After the rebuild, Lighthouse gave 0.000 to 0.001 in three runs on 30 October 2026. That tool is not the one used in 2025. The Largest Contentful Paint did not improve, so I do not claim a faster site. Sources: Screaming Frog, 5 October 2026; PageSpeed Insights, 28 September 2025; Lighthouse 12.2.1, 30 October 2026. Period: since September 2025.
View caseA technical SEO specialist makes sure Google can find, read and index the pages of a site. I check status codes, redirects, canonicals, hreflang, structured data and the HTML the server sends. I turn what is wrong into tickets for the developer.
I check every page in two layers: the raw HTML from the server and the page after JavaScript runs. Then I count the canonical and hreflang tags in the rendered DOM. An app can add tags there that are not in the source.
Before the new site goes live. Then I crawl the test site, and your developer fixes blockers while that is still easy. After launch I check redirects, canonicals and the sitemap on the live site.
Yes. I deliver tickets with the cause, a reproduction and the URLs where it occurs. After the release I check whether the fix is live and on which pages.
I measure before and after in the same way and write down the date of every change. For Yasemin Maaltijdservice I compared two Screaming Frog crawls with JavaScript on, from 31 August and 2 October 2026. That let me tie the change in titles, canonicals and hreflang to the release of 13 September.
Send me your domain and your platform. In 15 minutes you will know whether technical SEO is the right step now.
hello@sahardid.comAmsterdam