We don’t agree on what “Technical Search Engine Optimization” is supposed to be so we won’t agree on what comprises “Technical SEO Skills”. Here are my definitions and why I think these skills are important.
Technical search engine optimization delves into code and operating systems. It’s got nothing to do with keyword research and link placement. Here is why you need these four skills.
HTML coding and analysis are important to any search engine optimization specialist who is asked to assess the design of a Website’s documents. For example, if you think that links embedded in Javascript are a problem for crawlers you need to learn more about crawlers (which falls into the area of “theoretical knowledge for SEO”). If you think that using 10 different formats for internal relative URLs is a bad idea for SEO, you’re on the right path.
If you are still arguing “tables versus CSS” you never graduated from SEO 101. If, however, you notice that CSS is being used to hide text on a site that has received a penalty, you may be on to something.
If you use “View Source” and see nothing wrong with a page that has a lot of white space in the code, you’re probably not ready to handle your own SEO accounts. If, however, you just look at the rendered page and hit PAGE DOWN five times before you get to the obviously keyword-stuffed, link-bloated footer that is “hidden” below the fold by 100 blank lines that most users will never scroll past — you’re well-versed in simple Web spam techniques and won’t be easily fooled by naive clients who are running around with spam shotguns blowing their own feet off every five seconds.
If you think in terms of “PageRank Hoarding”, “Sculpting PageRank”, and Siloing you will probably find lots of opportunities to speak at conferences but most likely you hand off the real technical SEO to someone who doesn’t fall for buzzword philosophy.
Server operating system administration and analysis is vital to technical SEO because this is where a lot of technical SEO mistakes happen. People write HTACCESS files with thousands of lines of code and ask why their Websites take so long to render. They drop 10,000 files into a folder/directory on their server and complain that it takes the server a long time to do anything.
If you can read a raw server log you’re ten miles ahead of the guy who trusts whatever Google Analytics shows him. And you probably know enough to filter your own IP address out of any analytics report after having to skip past it so many times in the raw server data. That Google Analytics guru is lucky if he doesn’t crap in his pants when he clicks on the ADMIN link.
There are two schools of thought when it comes to Web server operating systems: Microsoft and Apache. In reality there are MORE than these two environments but they are the big dogs who slug it out the most. Unhappily I’m not the best Microsoft IIS search engine optimization expert I know but I am at home on an Apache server.
If you spit and say, “Webmin! Fah! Plex! Ick!” because you’re a command line jockey, you need to take a time out. And if you seriously believe that UNIX-style pattern matching is actually a powerful tool — you’re just a Preschooler playing with the big boys. Regular expressions are an analyst’s nightmare for two reasons: they MISS a lot of stuff and they INCLUDE a lot of crap. “Why, hell, any EGREP guru can get around that,” you say confidently.
In 30+ years of working on UNIX systems, I never met or heard of such a person. Your mileage may vary but I’ll trust my judgment more than yours in these matters any day. Regular expressions are hard for most people to use because they are STUPID.
Real programmers don’t use regular expressions. ‘Nuff said.
You need to understand where the Web server software is installed and configured, how its configured, and how it differs from the operating system software. You need to understand how to manage operating system accounts, permissions, tools, and reporting functions. If someone says, “My Website keeps getting hacked” you need to know where the backdoors are so that you can look at what the hacker is probably seeing. Maybe it’s all coming in through the login screen, maybe not.
Knowing which operating system a Website (component) runs on tells you a lot about what kind of server-side optimization, presentation, and organization the Website can use. Waiting for the O/S guru to call in on Skype means you shouldn’t be doing this job.
Website architecture design and analysis is where a lot of people break into real technical SEO. It’s the easiest and yet the most complex of the four basic skill areas. It’s the easiest because you basically just start out by clicking on the pages of a site. You test the usability, findability, indexability, informability of a Website by trying to use it. Somewhere along the way you start to look under the hood to see if all the code is written in the same style or if it’s a hodgepodge of coding philosophies and scripts.
You really have to understand WHAT THE NAVIGATION IS DOING and HOW THE NAVIGATION IS IMPLEMENTED.
You have to be able to explain HOW THE PAGE LAYOUT WORKS and HOW THE PAGE PRESENTATION INTERACTS WITH BACKGROUND FUNCTIONS.
Are there widgets on a page? Are they internal or external widgets (same site or remote site)? Are they Javascript, Perl, PHP, or maybe some esoteric blend of things only a dark worshipper of Clark Ashton Smith would recognize?
Does the user have to battle his way through popups, automatically-loading videos and audio files, advertising boxes, and signup forms before getting to the boilerplate stub content that says, “No results found for [INJECTED KEYWORD]“?
If you look at a Web page and think it looks okay you’re not ready for technical SEO. There is *always*something wrong, somewhere on a page. It may not need fixing but it’s broken, out-of-place, and just plain technically wrong. You’re supposed to know that (and also to know when it needs to be fixed and when it can be tolerated).
If you’re thinking, “Well, the page titles and meta tags are unique” you seriously need to stop reading SEO comic books. It’s not about uniqueness. It’s about what things are doing. “Why is this here?” should be the most common question you ask. “What is this trying to do?” should be the next most common question you ask.
It doesn’t matter if you’re looking under the hood or at the rendered page. If you’re not questioning everything you see, you’re not being technical enough.
The conversation with the client or vice president may have to be dumbed down to “Here’s your problem right here, Herb. You’ve got a loose — BZZZZT!” But you still have to be able to explain to someone like me (or you) why that is Herb’s problem. Otherwise you’re just guessing.
PHP, Javascript, Perl, and similar language coding knowledge is important to technical SEO because you need to have a feel for how much time it takes a typical Web browser (or search engine spider) to assemble the content for a page and then render it. You don’t have to know how many microseconds each fetch requires — but if you look at a PHP script with 14 function calls in it and you don’t think in terms of “here are 14 function calls”, you’re sucking wind as soon as you look under the hood.
It’s not about how many scripts a Web page invokes — it’s about how many things (function calls and other codey stuff) a Web page is trying to do. In today’s bloated CMS environment a typical Web page may execute 100-200 functions just to assemble itself and render in a browser. That’s before the lights start flashing, the bells whistle, the videos fire off, and the advertising shows up.
You need to be able to scan all this crap and figure out quickly if it might have an unforeseen impact on search engine performance. You need to have a keen radar for mistyped code, mistyped file references, mistyped links, etc. Programmers or coders or the dumb guy who pasted all this crap together from 15 different Websites may have no idea of why they need to do something so they do it in what they think is the most efficient way possible.
I once had to load and read between 6 and 10 PHP scripts just to get to a function call that loaded a file, all because I was analyzing a Website that had created multiple layers of code with a PLATFORM, a THEME, a PLUGIN, and a MOD. PHP is a hellish coding landscape that sacrifices sense and sensibility for momentary convenience. Back when you were lucky to get 16K of memory to work with on a mainframe, PHP would have been laughed out onto the street. That kind of coding efficiency would help the Web tremendously today, but those days are gone.
All the Real Programmers have gone to the Havens and Sailed Over Sea. Either that or they got old and retired.
You don’t have to write your own themes and plugins. You just need to be able to sort through the dozens, hundreds, thousands of PHP files that a typical Web forum or blog or ecommerce site uses to find THE ONE YOU NEED (for whatever your need may be). If you are lost in that forest of files you have no business claiming to be versed in technical SEO.
The technical side of the job is not to supervise the creation of Web applications and software. There are coders (developers) who are much better at doing that than you or I will ever be. Once in a blue moon you get an SEO who can code or a coder who can do SEO. Most people fall into one category or another.
If the Web were written in Business Basic I would pwn you all. Instead it’s written in HTML and PHP and I have to “evaluate” platforms and plugins and themes along with most everyone else.
So technical SEO is not about creating the forests of files; it’s about finding the problem that is causing the whole kit and kaboodle to wheeze and clunk and steam in all the wrong places. Your responsibility as a technical SEO is to dig through all the moving parts and find the one that is broken, jammed up, discombobulated, or otherwise neck deep in twisted wires and burned out fuses.
There are no keywords in technical search engine optimization. There are those who can do it and those who wish they had never tried. It’s not that hard once you learn the basic skills but it’s a time-consuming process.
You know someone has done real technical SEO when they provide you with clear, explicit step-by-step instructions on where to find the problem and how to fix it.
I’ll leave you with examples of bullet points that people who wish they had never tried to do technical SEO include in their blog posts when they try to write about technical SEO.
Source : http://www.seo-theory.comTechnical Search Engine Optimzation
These skills break down into four areas:- HTML coding and analysis
- Server operating system administration and analysis
- Website architecture design and analysis
- PHP, Javascript, Perl, and similar language coding knowledge
Technical search engine optimization delves into code and operating systems. It’s got nothing to do with keyword research and link placement. Here is why you need these four skills.
HTML coding and analysis are important to any search engine optimization specialist who is asked to assess the design of a Website’s documents. For example, if you think that links embedded in Javascript are a problem for crawlers you need to learn more about crawlers (which falls into the area of “theoretical knowledge for SEO”). If you think that using 10 different formats for internal relative URLs is a bad idea for SEO, you’re on the right path.
If you are still arguing “tables versus CSS” you never graduated from SEO 101. If, however, you notice that CSS is being used to hide text on a site that has received a penalty, you may be on to something.
If you use “View Source” and see nothing wrong with a page that has a lot of white space in the code, you’re probably not ready to handle your own SEO accounts. If, however, you just look at the rendered page and hit PAGE DOWN five times before you get to the obviously keyword-stuffed, link-bloated footer that is “hidden” below the fold by 100 blank lines that most users will never scroll past — you’re well-versed in simple Web spam techniques and won’t be easily fooled by naive clients who are running around with spam shotguns blowing their own feet off every five seconds.
If you think in terms of “PageRank Hoarding”, “Sculpting PageRank”, and Siloing you will probably find lots of opportunities to speak at conferences but most likely you hand off the real technical SEO to someone who doesn’t fall for buzzword philosophy.
Server operating system administration and analysis is vital to technical SEO because this is where a lot of technical SEO mistakes happen. People write HTACCESS files with thousands of lines of code and ask why their Websites take so long to render. They drop 10,000 files into a folder/directory on their server and complain that it takes the server a long time to do anything.
If you can read a raw server log you’re ten miles ahead of the guy who trusts whatever Google Analytics shows him. And you probably know enough to filter your own IP address out of any analytics report after having to skip past it so many times in the raw server data. That Google Analytics guru is lucky if he doesn’t crap in his pants when he clicks on the ADMIN link.
There are two schools of thought when it comes to Web server operating systems: Microsoft and Apache. In reality there are MORE than these two environments but they are the big dogs who slug it out the most. Unhappily I’m not the best Microsoft IIS search engine optimization expert I know but I am at home on an Apache server.
If you spit and say, “Webmin! Fah! Plex! Ick!” because you’re a command line jockey, you need to take a time out. And if you seriously believe that UNIX-style pattern matching is actually a powerful tool — you’re just a Preschooler playing with the big boys. Regular expressions are an analyst’s nightmare for two reasons: they MISS a lot of stuff and they INCLUDE a lot of crap. “Why, hell, any EGREP guru can get around that,” you say confidently.
In 30+ years of working on UNIX systems, I never met or heard of such a person. Your mileage may vary but I’ll trust my judgment more than yours in these matters any day. Regular expressions are hard for most people to use because they are STUPID.
Real programmers don’t use regular expressions. ‘Nuff said.
You need to understand where the Web server software is installed and configured, how its configured, and how it differs from the operating system software. You need to understand how to manage operating system accounts, permissions, tools, and reporting functions. If someone says, “My Website keeps getting hacked” you need to know where the backdoors are so that you can look at what the hacker is probably seeing. Maybe it’s all coming in through the login screen, maybe not.
Knowing which operating system a Website (component) runs on tells you a lot about what kind of server-side optimization, presentation, and organization the Website can use. Waiting for the O/S guru to call in on Skype means you shouldn’t be doing this job.
Website architecture design and analysis is where a lot of people break into real technical SEO. It’s the easiest and yet the most complex of the four basic skill areas. It’s the easiest because you basically just start out by clicking on the pages of a site. You test the usability, findability, indexability, informability of a Website by trying to use it. Somewhere along the way you start to look under the hood to see if all the code is written in the same style or if it’s a hodgepodge of coding philosophies and scripts.
You really have to understand WHAT THE NAVIGATION IS DOING and HOW THE NAVIGATION IS IMPLEMENTED.
You have to be able to explain HOW THE PAGE LAYOUT WORKS and HOW THE PAGE PRESENTATION INTERACTS WITH BACKGROUND FUNCTIONS.
Does the user have to battle his way through popups, automatically-loading videos and audio files, advertising boxes, and signup forms before getting to the boilerplate stub content that says, “No results found for [INJECTED KEYWORD]“?
If you look at a Web page and think it looks okay you’re not ready for technical SEO. There is *always*something wrong, somewhere on a page. It may not need fixing but it’s broken, out-of-place, and just plain technically wrong. You’re supposed to know that (and also to know when it needs to be fixed and when it can be tolerated).
If you’re thinking, “Well, the page titles and meta tags are unique” you seriously need to stop reading SEO comic books. It’s not about uniqueness. It’s about what things are doing. “Why is this here?” should be the most common question you ask. “What is this trying to do?” should be the next most common question you ask.
It doesn’t matter if you’re looking under the hood or at the rendered page. If you’re not questioning everything you see, you’re not being technical enough.
The conversation with the client or vice president may have to be dumbed down to “Here’s your problem right here, Herb. You’ve got a loose — BZZZZT!” But you still have to be able to explain to someone like me (or you) why that is Herb’s problem. Otherwise you’re just guessing.
PHP, Javascript, Perl, and similar language coding knowledge is important to technical SEO because you need to have a feel for how much time it takes a typical Web browser (or search engine spider) to assemble the content for a page and then render it. You don’t have to know how many microseconds each fetch requires — but if you look at a PHP script with 14 function calls in it and you don’t think in terms of “here are 14 function calls”, you’re sucking wind as soon as you look under the hood.
It’s not about how many scripts a Web page invokes — it’s about how many things (function calls and other codey stuff) a Web page is trying to do. In today’s bloated CMS environment a typical Web page may execute 100-200 functions just to assemble itself and render in a browser. That’s before the lights start flashing, the bells whistle, the videos fire off, and the advertising shows up.
You need to be able to scan all this crap and figure out quickly if it might have an unforeseen impact on search engine performance. You need to have a keen radar for mistyped code, mistyped file references, mistyped links, etc. Programmers or coders or the dumb guy who pasted all this crap together from 15 different Websites may have no idea of why they need to do something so they do it in what they think is the most efficient way possible.
I once had to load and read between 6 and 10 PHP scripts just to get to a function call that loaded a file, all because I was analyzing a Website that had created multiple layers of code with a PLATFORM, a THEME, a PLUGIN, and a MOD. PHP is a hellish coding landscape that sacrifices sense and sensibility for momentary convenience. Back when you were lucky to get 16K of memory to work with on a mainframe, PHP would have been laughed out onto the street. That kind of coding efficiency would help the Web tremendously today, but those days are gone.
All the Real Programmers have gone to the Havens and Sailed Over Sea. Either that or they got old and retired.
You don’t have to write your own themes and plugins. You just need to be able to sort through the dozens, hundreds, thousands of PHP files that a typical Web forum or blog or ecommerce site uses to find THE ONE YOU NEED (for whatever your need may be). If you are lost in that forest of files you have no business claiming to be versed in technical SEO.
Technical Search Engine Optimization Is About…
Needles in haystacks. Remember that image.The technical side of the job is not to supervise the creation of Web applications and software. There are coders (developers) who are much better at doing that than you or I will ever be. Once in a blue moon you get an SEO who can code or a coder who can do SEO. Most people fall into one category or another.
If the Web were written in Business Basic I would pwn you all. Instead it’s written in HTML and PHP and I have to “evaluate” platforms and plugins and themes along with most everyone else.
So technical SEO is not about creating the forests of files; it’s about finding the problem that is causing the whole kit and kaboodle to wheeze and clunk and steam in all the wrong places. Your responsibility as a technical SEO is to dig through all the moving parts and find the one that is broken, jammed up, discombobulated, or otherwise neck deep in twisted wires and burned out fuses.
There are no keywords in technical search engine optimization. There are those who can do it and those who wish they had never tried. It’s not that hard once you learn the basic skills but it’s a time-consuming process.
You know someone has done real technical SEO when they provide you with clear, explicit step-by-step instructions on where to find the problem and how to fix it.
I’ll leave you with examples of bullet points that people who wish they had never tried to do technical SEO include in their blog posts when they try to write about technical SEO.
- Think creatively
- Figure out what keywords you want to use
- Use Screaming Frog
- Read this blog post here
- Ask yourself, “Would Matt Cutts tell me to do this?”
- Check back for more information later
- Get your team together for some quality time
- Quality content
- Quality links
- Google Penguin
- A picture of (a cat, a snowball, the most interesting man in the world, etc.) with some words on it
- A screen capture from Google Analytics
- [Insert Danny Sullivan quote here]
- [Insert Matt Cutts video]
- Some complaint about how Google is evil and trying to screw everyone
- A warm reassuring sentence about how Google is your friend
- Some reference to weird food or drinks that only someone in Silicon Valley thinks is cute
- Some reference to bicycling, triathlons, workouts, or vacations that only Googlers can afford
- A self-congratulatory paragraph about their latest tool
- Something to do with Twitter
- Something to do with Facebook
- Something to do with Pinterest
- An aphorism about Social Media, Socia Media Marketing, or Mobile Search (what the HELL is freaking “mobile search” anyway?)
- Glowing adulation for the company founder
- A mild rebuke for someone who questioned a previous blog post
- Any list of vague, obscure nonsense that obviously says nothing specific about anything in particular
****Note : I am just sharing this Great Post Written by Michael Martinez The visitor of this blog can directly view the original post by clicking on the source link given Below*****
