When I started learning cybersecurity, I thought I was stepping into a completely different world.
SEO was search engines, websites, content, rankings and analytics.
Cybersecurity was networks, hackers, threats, vulnerabilities and protecting systems.
The more I learn, though, the more I keep running into things I’ve already encountered during my SEO career.
DNS. Servers. HTTP. Bots. Log files. JavaScript. Redirects. Website migrations.
I’m starting to realise that SEO and cybersecurity aren’t separate worlds.
They’re often looking at the same technology and asking different questions about it.
We both care about what happens when someone visits a website
Technical SEO forces you to understand at least some of what happens when a search engine requests a page.
Can Googlebot access it?
What status code does the server return?
Does the page redirect?
Can the content be rendered?
Is something blocking the crawler?
Cybersecurity looks at that same interaction from another perspective.
Who is making the request?
Should they have access?
Is the request legitimate?
Is someone trying to exploit something?
What information is being exposed?
It’s the same internet.
The questions are different.
DNS matters to both of us
I’ve dealt with DNS plenty of times through SEO.
It becomes particularly important during website migrations, domain changes and technical troubleshooting.
But cybersecurity has made me think about DNS beyond whether a website resolves correctly.
DNS is part of the infrastructure that allows us to navigate the internet in the first place.
Understanding it better means understanding more about how websites actually work — and how things can go wrong.
That’s becoming a recurring theme in my cybersecurity learning.
I’m revisiting technology I’ve encountered through SEO and discovering there is another layer underneath it.
HTTPS isn’t just an SEO checkbox
For years, HTTPS has appeared on SEO audit checklists.
Does the website use HTTPS?
Are HTTP URLs redirecting correctly?
Are there mixed-content issues?
Is the canonical version secure?
Tick the box. Move on.
Security gives HTTPS a much more meaningful context.
We’re talking about protecting information as it travels between systems.
Suddenly the little padlock we’ve all become used to represents something much bigger than an SEO best practice.
That’s something I’m enjoying about learning cybersecurity.
Things I’ve known about for years are starting to make more sense.
Security changes can affect SEO
This is where the relationship becomes very practical.
A security team can make a perfectly reasonable change that has unintended consequences for search engines.
A firewall rule might block legitimate crawlers.
A CDN configuration could change how content is served.
Security headers can affect scripts or resources.
Bot protection can become too aggressive.
Access restrictions can prevent search engines from reaching important content.
That doesn’t mean the security implementation is wrong.
It means websites are systems where one change can affect several other things.
As an SEO, understanding more about security should make those conversations with developers and security teams easier.
Instead of simply saying, “Google can’t crawl this,” I want to understand more about why.
A security incident can become an SEO incident very quickly
This connection is much more obvious.
Imagine someone compromises a website.
They create thousands of spam pages.
They inject links.
They alter existing content.
They create redirects.
They use the domain to promote things that have absolutely nothing to do with the business.
Google can discover those changes.
Suddenly, the security incident has entered the search results.
An SEO might first notice the problem inside Search Console.
Why are these strange URLs being indexed?
Why has crawling suddenly increased?
Where did these pages come from?
Why is Google showing something completely unrelated to the business?
But those are symptoms.
The actual problem may be happening much deeper in the website.
Log files are interesting to both sides
I’ve always found log file analysis interesting from an SEO perspective.
Server logs can help answer questions such as:
How often is Googlebot visiting?
Which URLs is it crawling?
What status codes is it encountering?
Is crawl activity being wasted somewhere?
Cybersecurity looks at logs for very different patterns.
Who accessed something?
When?
From where?
What did they request?
Was the behaviour unusual?
Could it indicate an attack?
Same data.
Different investigation.
That’s probably one of my favourite connections so far.
Bots aren’t automatically good or bad
SEO people spend a lot of time thinking about bots.
We actively want some of them visiting our websites.
Googlebot?
Come in.
Please crawl everything important.
Cybersecurity introduces a more cautious question:
Who exactly is knocking on the door?
The internet is full of automated activity.
Search crawlers, AI crawlers, monitoring tools, scrapers, malicious bots and countless other automated systems are constantly requesting websites.
The challenge becomes understanding which traffic you want, which you tolerate and which you should probably stop.
That feels increasingly relevant as the web becomes even more automated.
Website migrations look different through a security lens
I’ve been involved with enough website migrations to know how many things can go wrong from an SEO perspective.
Redirects.
Canonicals.
Internal links.
XML sitemaps.
Tracking.
Robots directives.
DNS.
Indexation.
But migrations can also involve changes to hosting, servers, DNS configurations, certificates, permissions, applications and infrastructure.
The SEO checklist is only one part of a much larger process.
Understanding more about that surrounding technology helps me see the bigger picture.
Cybersecurity is making me better at asking technical questions
I don’t expect to become the person responsible for securing the websites I work on.
That’s an important distinction.
Knowing something about cybersecurity doesn’t suddenly make me a security engineer any more than understanding JavaScript makes every technical SEO a software developer.
But it changes the questions I can ask.
Instead of only seeing that something isn’t working, I can start thinking about the systems involved.
Was access changed?
Is something being blocked?
What is the server returning?
Could a security control be involved?
Is the traffic legitimate?
What do the logs show?
Sometimes knowing the right question is almost as valuable as knowing the answer.
SEO might have prepared me for cybersecurity more than I realised
There are also similarities in how problems are investigated.
Something changes.
You gather evidence.
You check logs and data.
You look for patterns.
You develop a theory.
You test it.
You eliminate possibilities.
You document what happened.
I’ve done versions of that process countless times when investigating SEO problems.
Cybersecurity applies that investigative mindset to problems with much higher stakes and completely different consequences.
The technical knowledge is different.
The curiosity feels familiar.
The web doesn’t care about our job titles
I think this is the bigger lesson I’m taking from all of this.
We divide technology into disciplines because we need specialists.
SEO.
Development.
Analytics.
Cybersecurity.
Infrastructure.
UX.
But the website doesn’t experience those things separately.
It’s one system.
A security decision can affect crawling.
A development decision can affect security.
A JavaScript change can affect analytics.
A server configuration can affect performance.
A compromised website can affect search visibility.
Everything touches something else.
That’s why I’m enjoying learning cybersecurity alongside SEO.
I’m not trying to turn every cybersecurity concept into an SEO tactic.
I’m trying to understand more of the environment I’ve spent years working in.
And the deeper I go, the more I realise:
I’ve been standing next to cybersecurity for much of my SEO career. I just didn’t always know what I was looking at.
