- Jul 26, 2016
- 2,267
- 3,646
The model I use to do audit is worth emphasizing, because it helps place my recommendations for clients in the right context and helps me prioritize those recommendations. So, it all starts with search engines. We’ve got the crawler, the indexer, and the ranker. Google themselves outline it roughly like this, and it shows how Google models their own internal search structure. When I do SEO and perform site audits, I use the three pillars of SEO model, technology, relevancy, and authority. Technology is primarily focused on optimizing websites with the crawler.
Relevancy is about making sure the Indexer can properly render the pages. Authority is about making sure the content actually ranks the search engine that speed drives traffic. These tactics do tend to overlap here and there.
When you do one thing, sometimes it overlaps with other aspects of the search engine as well. So, Technical SEO is primarily crawl optimization, load speed optimization, mobile, JavaScript, International SEO, etc. Relevancy on page SEO, that’s classic SEO with keywords, page structure, content, quality, accessibility. Everything that is related to code isn’t necessarily technical SEO.
My technical SEO audit actually encompass all three elements of this. The emphasis is primarily on the first two aspects in my technical audit. I will look at how a page can be indexed by Google. So, roughly that’s what I focus on in my audit. That is the model that I use. It helps clarify for my clients and make it more digestible for them.
Before the Audit
The audit itself is just part of a longer process. I will never start an audit before I have a signed agreement. It’s not a very long agreement, but it does cover a lot of bases. The nondisclosure section is in there as well. I have never not been paid for an audit. By having this signed agreement, it always makes sure that you have some sort of legal fall back mechanism. I always ask for 50% up front. I always make very clear to my clients I’m not even going to schedule or start the work until we have the advanced payment. It also means it will start the internal financial status on their end, and then the second payment tends not to be a big issue, because you’re already in the system and it becomes very easy for them.
Always start with Google Search Console. This is really the only must have access. I can do a perfectly well technical audit with just Search Console access. I like to get web analytics and server log files, because it makes my audit better, but it’s not necessary. I actually put it in my agreement that I get Google Search Console access before I start the work. What I always do, as well, is do a very quick initial scan. I like Little Warden for that, which is a monitoring tool that keeps track of stuff that goes wrong on websites and gives alerts when that happens. It can also can find some basic SEO problems right off the bat.
Audit Tools
There are certain number of tools that I like to use in my tool stack that I tend to come back to again and again. My preferred crawler is DeepCrawl. It’s quite simple to use. I don’t necessarily crawl an entire site with DeepCrawl. If it’s a site with over half a million pages, I tend to have more focus crawls. It’s about finding patterns. You can do a limited crawl, between 100,000 to 500,00 pages, and you have a pretty good idea what’s working or not. I then do a lot of partial site crawls to just get a narrow view of specific site sections that might need further attention. I then like to do two crawls back to back on the same site section, one with Googlebot and one with Googlebot-Smartphone, so we get a direct comparison between the desktop and mobile versions of website.
I think every SEO needs to have Screaming Frog. I have to admit it has started to be replaced in some context with Sitebulb, because their crawl map is really cool. The only problem I have with Sitebulb is that it overheats my laptop. I use them for more focused crawls where you don’t need to run the whole cloud crawler. Search Console is the biggest tool that we have and that I use pretty much every single report for my technical SEO. There is almost no report in Search Console I don’t at least have a look at as part of the audit.
Then there are a whole bunch of tools which I called paid testing tools, for example, GTmetrix. I get specific feedback on particular aspects of the page. You can’t do these sitewide, because they work on per URL basis, so you have to just be focused with the tests. I have also started using Lighthouse a bit. I tend to ignore the performance report in Lighthouse. I do look at accessibility, best practices, and SEO reports. I think they can be quite useful.
There are couple of extensions I tend to use, for example, Ayima Redirect Path, Ayima Page Insights, Wappalyzer, HTML5 Document Outline, Hreflang Handler, Majestic, Nofollow. I find that if you optimize a webpages document outline, it makes it easier to understand it. I do use other tools as and when required, but it depends on the type of audit I’m doing.
The Actual Audit
I do still use Excel as a checklist. For me, every little entry in my SEO audit checklist is a starting point for a potential rabbit hole. As you go through the, for example, Search Console reports or the DeepCrawl reports, you find yourself already digging into certain elements of website, and the checklist makes sure that I don’t forget to look at other aspects of a website. The checklist is more for me to make sure I cover all the bases. You don’t want to make it needlessly complex. A group audit is all about identifying pattern. I see a lot of SEO audit reports that client send to me that they have commissioned earlier that suggest glorified tool export with no understanding of the context or the problem, root cause of the problem, and the potential impact of it. And for me, that separates a shit audit from a good audit. If you can identify the root cause, the patterns, and the interdependencies on the website that caused the problem in the first place, you’re already a step ahead of your competitors. Some technology platforms just have issues that you can’t resolve, that’s stuff that is just part of the system that’s baked into it.
What I find very useful is to identify the different templates that drive a website. Each template might have its own peculiar little problems that apply specifically to those types of pages. I had a website recently that had two different blog/news sections, and they had different problems based on the platform that they used. Nothing beats walking through a website yourself, clicking on links, looking at the page and plug ins that tell you about that specific page. You can’t perform an audit purely just by looking at the tools as a window into the website. You have to become a user to that website, and see what you can then do to make the website perform better. WordPress website tend to have the same issues again, and again, and again. Because of the accessible nature of WordPress, you come across some really shit templates that people who call themselves web developers have designed. Magento is another one of those platforms that is an absolute beast of a system, and there’s a lot of typical problems with Magento as well. When looking at the hosting platform, which does run on its own PPS, it should be perfectly fast, but it does like 300 database codes to single product base, and most of those are a result of extensions that have been installed for one specific purpose, but don’t need to be loaded on every single page.
If you’re ever unlucky enough to audio Microsoft ASP.NET websites, you will know that you come across multiple issues. ASP.NET websites tend to (inaudible – 00:29:08) are case sensitive. And you also have trailing slash issues with ASP.NET. There are typical technical SEO issues you find on every single website no matter how it’s coded. Basically, is it web developers doing stupid things. I have worked with some really smart web developers over the years, and even they do stupid things now and again, because they don’t know any better. We have to work together with them to fix them and hopefully advocate them to not make these errors again later down the line. I will show you a couple of example issues that have come across in the last couple of months to give you an idea of the types of things I look at when it comes to technical SEO audits. We have a rep site here which has more than 10,000 pages get traffic from Search Console. That’s what I like about DeepCrawl, you can combine multiple data sources, and then see if there’s any source gaps there. You’ve got then see what would be the best way to solve this. Is there a lot of value in these PDF files? Can we do anything with them?
Another example is where I ran two crawls on the same section of the website, using Googlebot desktop and Googlebot-Smartphone. Not a huge difference in the amount of pages, but there were some differences with the linking. These changes reports showed me that there’s a very huge difference in how these versions link out and link to other pages within the website. For websites that tend to use a lot of clients like JavaScript, I tend to use Diffchecker to computer the difference between the pre-rendered code and the post-rendered code. I see multiple cases where the rendered JavaScript canonical tag gets picked up, and the HTML canonical tag is ignored once the page is completely rendered. This is one of those problems that you don’t necessarily catch straight away, because you have to make sure your crawler has JavaScript enabled to even start seeing these things. You can give them an ideal scenario to aim for, but the underlying problems that are the root cause of this are so fundamental to how the platform is coded that they can’t really change this on a dime.
Another example is a crawl on DeepCrawl that’s more than 96,000 non-indexable pages. It turns out all of these pages are canonicalized to a different URL. This is a very simple fix, because all of those non-indexable pages, the only difference they really had was missing (inaudible – 00:38:14). Sometimes it might be simpler to start a crawl once we move forward or Sitebulb before you spend a lot of credit on DeepCrawl to do the completely cycle.
Writing The Report
So, you end up with a lot of different issues in your SEO checklists, and you’re like, what do we actually have to do to report this to the client and make sure that they can make sense of it? When you write your report, you have to keep in mind it will be shared, and not just within the company. But you don’t necessarily give away the whole process in the report. Keep it simple, keep it concise, and focus on what the clients needs to do and what the ideal scenario would be.
Most audit reports are between 2000 and 6000 words. Keep it as short and simple as you can, but at the same time, don’t be too concise. You have to explain things in the proper way. The most important thing in the actual report is to prioritize it properly. I use the three pillars of SEO, but I do this in a backwards way. I start with ranking issues. There is a very technical reason why it’s not ranking. That is propriety one, because it’s a relatively easy fix. Then go a step back, the page is being crawled, but it might not be index properly. Then, the third type of priority is the page is not being crawled at all. What can we do to fix that? I find this helps me prioritize it properly, because when they start fixing the ranking issues, they tend to have a very big payoff. Then the indexing issues tend to have quicker results than just fixing the crawling issues, unless you find an absolutely critical crawl issue.
Only include what needs to be improved, so keep it as short as possible. Don’t put any of the trivial stuff in, and try to explain it without using too much jargon. As a general rule, if you can’t explain it to a teenager, then you don’t really understand it yourself. I try to not tell developers what or how they need to fix it; I just tell them why it’s important and why it needs to be fixed. You have to make sure this is the scenario, but we are going to have to make a compromise, so let’s work together to find the best approach. And keep your audience in mind. The three main audiences are executors, the marketers, and the tech team. For the executives, you have to provide a summary, and don’t blame anybody.
Give them some kind of projection. The marketers are the ones you tend to be working with the most, and your job is to make them look good. You have to make sure they understand this stuff is a process, and that they don’t need to focus on what their competitors are doing. I find it very useful if you give your marketing contacts a bit of the tools themselves. The tech team are the ones you’re really gonna have to win over, because for them you are the enemy, but at the same time, you absolutely need them to get shit done. So, you have to have a basic understanding of the context in which they work and try to speak their language a bit. Let’s be honest, most developers want to work at Google, so if you explain to them this is what Google expects of websites, they tend to become allies. Don’t tell them how, but tell them why.
Questions
If you’re running an audit and the client has a bunch of things already set up correctly, right, they’ve got the chronicles, the site maps, etc., all in a good place, and there wasn’t a massive list of benefits to show the client you don’t necessarily have a ton of those quick wins, how do you tend to try and show the value in what you’re doing in an audit if you don’t necessarily have a ton of these great recommendations, because they’re actually doing a bunch of stuff well in the first place?
In the SEO checklist, I tend to tell the client there’s a lot of green marks in there. Again, it shows that I’ve actually checked these things. I don’t put in the report, but you can put it in the checklist. You have to sort of put them in the right context. But in the end, you’re probably better off focusing your efforts on maybe content, or link building, or whatever it is, rather than these technical fixes. Giving the developers compliments, you’ll make the developers very happy, but it also means that the marketers can then say, we get more budget, because the tech team doesn’t need it. If there’s not a lot we can do to improve the website from a technical point of view, I have on occasion said to the client there’s nothing I can do for you here. It can pay off to just be nice about these things and tell the client honestly that your website is in great shape.
What happens if at initial look at website, you identify something extremely wrong, but it’s really simple to fix, like a rogue canonical tag, or a rogue no index, like something that will immediately yield very positive results and it’s so simple? Do you give that up front, or do you wait until you’ve got a signed contract?
I give them that straight away, and it always results in them commissioning me. If it’s something that obvious wrong with it, what else is going wrong? Maybe later down the line we can do a complete audit once you’ve got that one ticked off.
Can you go into a little detail on how canonicalization is done well in your book? Like, what would be like red flags for why you would say canonicalization is really not been done well? And what would you usually look to as a recommendation as a kind of best practice, if you like, or —
In an ideal scenario, you shouldn’t need canonical tags, because every unique piece of content on the website should have its own unique URL, and Google can only find that unique URL, and rank that URL. That’s sort of the ideal awesome scenario you work backwards from. That’s never gonna happen. Every website is gonna have some sort of duplicating issue somewhere. Then you can work backwards and say how can we get closest to this in your particular scenario, and when do we need to use canonical tags?
Google is pretty good at picking canonical version, so that’s a fairly low priority fix. It’s more of an issue if there’s actually completely different URLs that serve the same or very similar content. Google tends to ignore them if it thinks they’ve been implemented in the wrong way. The site structure is still the strongest signal you have to identify to what a page’s canonical version is. It tends to be the version that has the most incoming link value and the most ranking potential that Google will pick. It really depends on the context or the particular website.
What is the best practice for navigations that rely on JavaScript to function? Is it still worth it to make sure that navs work without JavaScript enabled, or is less an issue nowadays?
It’s still a big issue. I’ll refer back to my three pillars of SEO model. Google indexes JavaScript, yes. It doesn’t crawl JavaScript. It downloads HTML, extracts links, goes onto to the next page. If it can’t extract links, it has to wait for the indexer to render the page to see if there’s any links found. If you rely on JavaScript to insert links, you’re making this a terribly inefficient process and end up with Googlebot maybe going two or three levels deep on your website max, and then just crawling the same pages over and over again. So, yes, absolutely, have the links in old-fashioned HTML completely working without any JavaScript.
Relevancy is about making sure the Indexer can properly render the pages. Authority is about making sure the content actually ranks the search engine that speed drives traffic. These tactics do tend to overlap here and there.
When you do one thing, sometimes it overlaps with other aspects of the search engine as well. So, Technical SEO is primarily crawl optimization, load speed optimization, mobile, JavaScript, International SEO, etc. Relevancy on page SEO, that’s classic SEO with keywords, page structure, content, quality, accessibility. Everything that is related to code isn’t necessarily technical SEO.
My technical SEO audit actually encompass all three elements of this. The emphasis is primarily on the first two aspects in my technical audit. I will look at how a page can be indexed by Google. So, roughly that’s what I focus on in my audit. That is the model that I use. It helps clarify for my clients and make it more digestible for them.
Before the Audit
The audit itself is just part of a longer process. I will never start an audit before I have a signed agreement. It’s not a very long agreement, but it does cover a lot of bases. The nondisclosure section is in there as well. I have never not been paid for an audit. By having this signed agreement, it always makes sure that you have some sort of legal fall back mechanism. I always ask for 50% up front. I always make very clear to my clients I’m not even going to schedule or start the work until we have the advanced payment. It also means it will start the internal financial status on their end, and then the second payment tends not to be a big issue, because you’re already in the system and it becomes very easy for them.
Always start with Google Search Console. This is really the only must have access. I can do a perfectly well technical audit with just Search Console access. I like to get web analytics and server log files, because it makes my audit better, but it’s not necessary. I actually put it in my agreement that I get Google Search Console access before I start the work. What I always do, as well, is do a very quick initial scan. I like Little Warden for that, which is a monitoring tool that keeps track of stuff that goes wrong on websites and gives alerts when that happens. It can also can find some basic SEO problems right off the bat.
Audit Tools
There are certain number of tools that I like to use in my tool stack that I tend to come back to again and again. My preferred crawler is DeepCrawl. It’s quite simple to use. I don’t necessarily crawl an entire site with DeepCrawl. If it’s a site with over half a million pages, I tend to have more focus crawls. It’s about finding patterns. You can do a limited crawl, between 100,000 to 500,00 pages, and you have a pretty good idea what’s working or not. I then do a lot of partial site crawls to just get a narrow view of specific site sections that might need further attention. I then like to do two crawls back to back on the same site section, one with Googlebot and one with Googlebot-Smartphone, so we get a direct comparison between the desktop and mobile versions of website.
I think every SEO needs to have Screaming Frog. I have to admit it has started to be replaced in some context with Sitebulb, because their crawl map is really cool. The only problem I have with Sitebulb is that it overheats my laptop. I use them for more focused crawls where you don’t need to run the whole cloud crawler. Search Console is the biggest tool that we have and that I use pretty much every single report for my technical SEO. There is almost no report in Search Console I don’t at least have a look at as part of the audit.
Then there are a whole bunch of tools which I called paid testing tools, for example, GTmetrix. I get specific feedback on particular aspects of the page. You can’t do these sitewide, because they work on per URL basis, so you have to just be focused with the tests. I have also started using Lighthouse a bit. I tend to ignore the performance report in Lighthouse. I do look at accessibility, best practices, and SEO reports. I think they can be quite useful.
There are couple of extensions I tend to use, for example, Ayima Redirect Path, Ayima Page Insights, Wappalyzer, HTML5 Document Outline, Hreflang Handler, Majestic, Nofollow. I find that if you optimize a webpages document outline, it makes it easier to understand it. I do use other tools as and when required, but it depends on the type of audit I’m doing.
The Actual Audit
I do still use Excel as a checklist. For me, every little entry in my SEO audit checklist is a starting point for a potential rabbit hole. As you go through the, for example, Search Console reports or the DeepCrawl reports, you find yourself already digging into certain elements of website, and the checklist makes sure that I don’t forget to look at other aspects of a website. The checklist is more for me to make sure I cover all the bases. You don’t want to make it needlessly complex. A group audit is all about identifying pattern. I see a lot of SEO audit reports that client send to me that they have commissioned earlier that suggest glorified tool export with no understanding of the context or the problem, root cause of the problem, and the potential impact of it. And for me, that separates a shit audit from a good audit. If you can identify the root cause, the patterns, and the interdependencies on the website that caused the problem in the first place, you’re already a step ahead of your competitors. Some technology platforms just have issues that you can’t resolve, that’s stuff that is just part of the system that’s baked into it.
What I find very useful is to identify the different templates that drive a website. Each template might have its own peculiar little problems that apply specifically to those types of pages. I had a website recently that had two different blog/news sections, and they had different problems based on the platform that they used. Nothing beats walking through a website yourself, clicking on links, looking at the page and plug ins that tell you about that specific page. You can’t perform an audit purely just by looking at the tools as a window into the website. You have to become a user to that website, and see what you can then do to make the website perform better. WordPress website tend to have the same issues again, and again, and again. Because of the accessible nature of WordPress, you come across some really shit templates that people who call themselves web developers have designed. Magento is another one of those platforms that is an absolute beast of a system, and there’s a lot of typical problems with Magento as well. When looking at the hosting platform, which does run on its own PPS, it should be perfectly fast, but it does like 300 database codes to single product base, and most of those are a result of extensions that have been installed for one specific purpose, but don’t need to be loaded on every single page.
If you’re ever unlucky enough to audio Microsoft ASP.NET websites, you will know that you come across multiple issues. ASP.NET websites tend to (inaudible – 00:29:08) are case sensitive. And you also have trailing slash issues with ASP.NET. There are typical technical SEO issues you find on every single website no matter how it’s coded. Basically, is it web developers doing stupid things. I have worked with some really smart web developers over the years, and even they do stupid things now and again, because they don’t know any better. We have to work together with them to fix them and hopefully advocate them to not make these errors again later down the line. I will show you a couple of example issues that have come across in the last couple of months to give you an idea of the types of things I look at when it comes to technical SEO audits. We have a rep site here which has more than 10,000 pages get traffic from Search Console. That’s what I like about DeepCrawl, you can combine multiple data sources, and then see if there’s any source gaps there. You’ve got then see what would be the best way to solve this. Is there a lot of value in these PDF files? Can we do anything with them?
Another example is where I ran two crawls on the same section of the website, using Googlebot desktop and Googlebot-Smartphone. Not a huge difference in the amount of pages, but there were some differences with the linking. These changes reports showed me that there’s a very huge difference in how these versions link out and link to other pages within the website. For websites that tend to use a lot of clients like JavaScript, I tend to use Diffchecker to computer the difference between the pre-rendered code and the post-rendered code. I see multiple cases where the rendered JavaScript canonical tag gets picked up, and the HTML canonical tag is ignored once the page is completely rendered. This is one of those problems that you don’t necessarily catch straight away, because you have to make sure your crawler has JavaScript enabled to even start seeing these things. You can give them an ideal scenario to aim for, but the underlying problems that are the root cause of this are so fundamental to how the platform is coded that they can’t really change this on a dime.
Another example is a crawl on DeepCrawl that’s more than 96,000 non-indexable pages. It turns out all of these pages are canonicalized to a different URL. This is a very simple fix, because all of those non-indexable pages, the only difference they really had was missing (inaudible – 00:38:14). Sometimes it might be simpler to start a crawl once we move forward or Sitebulb before you spend a lot of credit on DeepCrawl to do the completely cycle.
Writing The Report
So, you end up with a lot of different issues in your SEO checklists, and you’re like, what do we actually have to do to report this to the client and make sure that they can make sense of it? When you write your report, you have to keep in mind it will be shared, and not just within the company. But you don’t necessarily give away the whole process in the report. Keep it simple, keep it concise, and focus on what the clients needs to do and what the ideal scenario would be.
Most audit reports are between 2000 and 6000 words. Keep it as short and simple as you can, but at the same time, don’t be too concise. You have to explain things in the proper way. The most important thing in the actual report is to prioritize it properly. I use the three pillars of SEO, but I do this in a backwards way. I start with ranking issues. There is a very technical reason why it’s not ranking. That is propriety one, because it’s a relatively easy fix. Then go a step back, the page is being crawled, but it might not be index properly. Then, the third type of priority is the page is not being crawled at all. What can we do to fix that? I find this helps me prioritize it properly, because when they start fixing the ranking issues, they tend to have a very big payoff. Then the indexing issues tend to have quicker results than just fixing the crawling issues, unless you find an absolutely critical crawl issue.
Only include what needs to be improved, so keep it as short as possible. Don’t put any of the trivial stuff in, and try to explain it without using too much jargon. As a general rule, if you can’t explain it to a teenager, then you don’t really understand it yourself. I try to not tell developers what or how they need to fix it; I just tell them why it’s important and why it needs to be fixed. You have to make sure this is the scenario, but we are going to have to make a compromise, so let’s work together to find the best approach. And keep your audience in mind. The three main audiences are executors, the marketers, and the tech team. For the executives, you have to provide a summary, and don’t blame anybody.
Give them some kind of projection. The marketers are the ones you tend to be working with the most, and your job is to make them look good. You have to make sure they understand this stuff is a process, and that they don’t need to focus on what their competitors are doing. I find it very useful if you give your marketing contacts a bit of the tools themselves. The tech team are the ones you’re really gonna have to win over, because for them you are the enemy, but at the same time, you absolutely need them to get shit done. So, you have to have a basic understanding of the context in which they work and try to speak their language a bit. Let’s be honest, most developers want to work at Google, so if you explain to them this is what Google expects of websites, they tend to become allies. Don’t tell them how, but tell them why.
Questions
If you’re running an audit and the client has a bunch of things already set up correctly, right, they’ve got the chronicles, the site maps, etc., all in a good place, and there wasn’t a massive list of benefits to show the client you don’t necessarily have a ton of those quick wins, how do you tend to try and show the value in what you’re doing in an audit if you don’t necessarily have a ton of these great recommendations, because they’re actually doing a bunch of stuff well in the first place?
In the SEO checklist, I tend to tell the client there’s a lot of green marks in there. Again, it shows that I’ve actually checked these things. I don’t put in the report, but you can put it in the checklist. You have to sort of put them in the right context. But in the end, you’re probably better off focusing your efforts on maybe content, or link building, or whatever it is, rather than these technical fixes. Giving the developers compliments, you’ll make the developers very happy, but it also means that the marketers can then say, we get more budget, because the tech team doesn’t need it. If there’s not a lot we can do to improve the website from a technical point of view, I have on occasion said to the client there’s nothing I can do for you here. It can pay off to just be nice about these things and tell the client honestly that your website is in great shape.
What happens if at initial look at website, you identify something extremely wrong, but it’s really simple to fix, like a rogue canonical tag, or a rogue no index, like something that will immediately yield very positive results and it’s so simple? Do you give that up front, or do you wait until you’ve got a signed contract?
I give them that straight away, and it always results in them commissioning me. If it’s something that obvious wrong with it, what else is going wrong? Maybe later down the line we can do a complete audit once you’ve got that one ticked off.
Can you go into a little detail on how canonicalization is done well in your book? Like, what would be like red flags for why you would say canonicalization is really not been done well? And what would you usually look to as a recommendation as a kind of best practice, if you like, or —
In an ideal scenario, you shouldn’t need canonical tags, because every unique piece of content on the website should have its own unique URL, and Google can only find that unique URL, and rank that URL. That’s sort of the ideal awesome scenario you work backwards from. That’s never gonna happen. Every website is gonna have some sort of duplicating issue somewhere. Then you can work backwards and say how can we get closest to this in your particular scenario, and when do we need to use canonical tags?
Google is pretty good at picking canonical version, so that’s a fairly low priority fix. It’s more of an issue if there’s actually completely different URLs that serve the same or very similar content. Google tends to ignore them if it thinks they’ve been implemented in the wrong way. The site structure is still the strongest signal you have to identify to what a page’s canonical version is. It tends to be the version that has the most incoming link value and the most ranking potential that Google will pick. It really depends on the context or the particular website.
What is the best practice for navigations that rely on JavaScript to function? Is it still worth it to make sure that navs work without JavaScript enabled, or is less an issue nowadays?
It’s still a big issue. I’ll refer back to my three pillars of SEO model. Google indexes JavaScript, yes. It doesn’t crawl JavaScript. It downloads HTML, extracts links, goes onto to the next page. If it can’t extract links, it has to wait for the indexer to render the page to see if there’s any links found. If you rely on JavaScript to insert links, you’re making this a terribly inefficient process and end up with Googlebot maybe going two or three levels deep on your website max, and then just crawling the same pages over and over again. So, yes, absolutely, have the links in old-fashioned HTML completely working without any JavaScript.
