SEO
Technical SEO
Technical SEO is where the gap between a consultant and a developer is widest. Not because the problems are hard to find, but because most of them have to be solved in the code.
- Same-day reply
- Fixed price
- No lock-in
- Crawl and indexing
- JavaScript rendering
- Hreflang and canonicals
- Log file analysis
Service
Technical SEO
What I go through
- What the crawler actually sees, run through a real crawl rather than a single page test.
- Rendering: whether content exists in the HTML or only appears after JavaScript has run.
- Canonicals, including the cases where they point at a page that itself points somewhere else.
- Hreflang in both directions. It is nearly always set up one way only.
- Status codes: 404s answering 200, redirect chains, and pages redirecting to the front page instead of somewhere relevant.
- Sitemap and robots.txt, which surprisingly often contradict each other.
JavaScript and rendering
Google can run JavaScript, but it happens in a later pass than the first crawl and there is no guarantee when. On sites with many pages that becomes a real problem.
I check whether the content that needs to rank exists in the initial HTML. If the answer is no, we look at whether it can be rendered on the server instead and what that would cost.
Large sites
On sites with hundreds of thousands of URLs, crawl budget becomes a real constraint. Then it is about closing off what should not be crawled — filter parameters, sorting, search results — so there is capacity left for what matters.
Here log files are worth more than any tool. They show what Googlebot actually spends its time on instead of guessing.
Deliverables
What you get
Concrete deliverables, not a report of recommendations someone else has to find time for.
- A crawl report
What the crawler actually sees, run across the whole site rather than a single page test.
- A rendering check
Whether content exists in the initial HTML, or only appears after JavaScript has run.
- Hreflang and canonicals
Set up and verified in both directions. They are nearly always only configured one way.
- Log file analysis
On large sites: what Googlebot actually spends its time on, rather than what you hope it does.
Process
How it works
Four steps. You know what happens when, and you can stop after any of them.
- 01
Find what blocks you
I start with a full crawl and a review of Search Console. There is nearly always something technical in the way that makes the rest of the work wasted if it is not cleared first.
- 02
A prioritised list
Everything I find gets sorted by return on effort. You can see the reasoning behind each item, so you can judge for yourself whether I am right.
- 03
The fixes get made
I deliver the work as pull requests in your own repository, not as recommendations someone else has to find time for. That is the whole reason to hire a developer for SEO.
- 04
Measurement and follow-up
We measure before and after on real visitors. You get a short monthly update, including the months where nothing happened, because that is information too.

Who does the work
I am the person you will be working with
My name is Mikkel and I have been building for the web since 2010. There is no project manager in between, and you will not get a junior on the job because the senior was busy. What you agree is what gets built, and I am the one building it.
Day to day I am a partner at Bigum&Co, and I have worked on more than 400 projects across ecommerce, pharma, construction and the public sector. Call or write — I usually reply the same day, and I will say straight away if the job is not a fit.
- Experience
- 16 yrs
- Projects
- 400+
- Rating
- 5.0
- Reply time
- Same day
In depth
Technical SEO
What technical SEO covers
Technical SEO is about whether a search engine can find, fetch, understand and store your pages. Not about what is on them. It is a different discipline from content, and it is the one most often skipped, because it needs access to code and servers.
In practice there are four layers. Can the crawler find the page — are there links to it, is it in the sitemap, is it not blocked. Can it fetch it — does the server respond fast enough, with the right status code. Can it understand it — is the content in the HTML, are the headings sane, does the structured data match. And should it store it — or is there a canonical, a noindex or a duplicate saying otherwise.
The failures across those four layers are rarely spectacular, and they are often invisible in a browser. A page that looks perfectly fine can happily return 200 on a URL that should not exist, or point its canonical at the front page. You only find that by looking.
On large sites a fifth layer appears: crawl budget. Googlebot does not have unlimited time for your site. If it spends it on filter parameters and sort orders, there is less left for the pages that make money. Log files are the only place you can see that directly.
JavaScript and what Google actually sees
Google can run JavaScript. That is true, and it gets used as an argument for not thinking about it. The problem is that it happens in a later pass than the first crawl, and there is no guarantee when that pass arrives.
On a small site with sixty pages it hardly matters. On a site with thirty thousand pages it means a share of them never get rendered, and those pages effectively do not exist in the index. You can see it in Search Console, where pages sit as discovered but not indexed for months.
The test is simple enough: fetch the page without JavaScript and see whether the content that needs to rank is there. If it is not, the question is whether it can be rendered on the server instead, and what changing that would cost. On a Next.js or Nuxt site it is often a manageable change. On a pure single page app it is a larger project.
Reviews
What people say about me
Mikkel delivered competent, professional work setting up my website. Everything ran quickly and without a hitch.
Sisse Find(translated from Danish) Mikkel Tschentscher is my lifeline when something is urgent and nobody else can work it out.
Torben Wiese(translated from Danish) Mikkel is a man after my own heart. Executes at lightning speed, has an eye for detail and is always there when you need him. It does not get better than that.
Tini Owild(translated from Danish)
Services
Why me
- 16 years of experience
I have built for the web since 2010 and seen most of the ways a project can come off the rails. It makes the estimates more honest.
- 400+ projects
Across ecommerce, pharma, construction and the public sector. Chances are I have seen something close to your job before.
- You talk to the person coding
No project manager in between, and no junior on the job because the senior was busy. What you agree is what gets built.
Brands I have worked with
A selection. Some freelance, some through agencies, some across several years.
Questions
Frequently asked questions
- What does a technical SEO audit cost?
- It depends on the size of the site and how many systems are involved. Send me a link, I will take a quick look and give you a fixed price.
- Do you fix the issues as well?
- Yes, if you want. It is usually the cheapest route because I am already inside the code. If you would rather have your own team do it, I write it up so it can be carried out without me.
- How often should this be done?
- A thorough review once a year, plus ongoing monitoring so you catch it when a deploy changes something. That is cheaper than discovering it three months later.
- Can you do the audit without access to our code?
- Yes, a crawl only needs the site to be public. But access to Search Console, and ideally to server logs, makes the audit markedly better, and access to the code is needed if I am to fix things too.
- We just had a site built. Is this needed already?
- A check right after launch is actually one of the best moments. That is when redirects, canonicals and sitemaps are usually half finished, and it is cheaper to fix now than in six months.
- Can you monitor it continuously?
- Yes, and I recommend it on sites that deploy often. A weekly crawl that reports changes is cheaper than discovering three months later that a section was accidentally set to noindex.
