For SEO checks you can use in a tech audit, please see table newr the bottom of this post.

Notes from this course on Udemy

Introduction to the Elements Panel

You can view code in Chrome, by right-clicking on a webpage and clicking “view page source”

You can see the code of the page, but you can’t do much with it.

Instead, you can right click and choose “developer tools”

The elements panel is normally the default panel that you see:

As you hover over items in the Elements tab, it will highlight the relevant part of the webpage too.

You can right-click and choose “Inspect Element” and the Dev Tools window will open up, with the relevant piece of HTML code highlighted.
For example, if you click the main header of a page, and choose “Inspect Element”, there’s a good chance you’ll be taken to the elements tab and have a “<h1>” highlighted.

You can change the text if you like, and the style – by typing and editing it in the styles panel on the right:

You can click the “+” symbol to add a new style (I couldn’t be arsed putting this screen snippet into Paint to used proper type-text):

• You can right click > Inspect an element and click the delete key to get rid of a style
• Click on the colour picker to get a eye-dropped tool and other colour-picker options to change colours used on the webpage:
  

Chrome Developer Tools

Click the mobile icon – to see a website previewed on a mobile phone – you can change the phone model with the drop down menu

Console Tab

You can type console.log javascript code. This allows you to see the output of JavaScript code.

Web developers log messages for 2 general reasons:

• Making sure that code is executing in the right order.
• Inspecting the values of variables at a certain moment in time.
• https://developer.chrome.com/docs/devtools/console/

Sources Tab

Files and folders that have been loaded by the webpage, can be found in the Sources tab – e.g. type Jquery to see if a page is using jquery

It’s often used for debugging JavaScript:

“Top” – The top-level, such as top on the screenshot above, represents an HTML frame. You’ll find top on every page that you visit. top represents the main document frame. (more info here)

The second-level, such as developers.google.com on the screenshot above, represents an origin.

The third-level, fourth-level, and so on, represent directories and resources that were loaded from that origin. For example, on the screenshot above, the full path to the resource devsite-googler-button is developers.google.com/_static/19aa27122b/css/devsite-googler-button.

• You can click individual files to view them in the preview pane in the middle:

• Edit CSS and JavaScript

You can edit code and see the changes immediately on the webpage

Image from Developer.chrome.com

CSS changes take effect immediately, no save needed. For JavaScript changes to take effect, press Command+S (Mac) or Control+S (Windows, Linux). DevTools doesn’t re-run a script, so the only JavaScript changes that take effect are those that you make inside of functions.

• You can save snippets of code and run them on any page

Application Tab

See local storage – Open the local storage section – you can see, well the local storage:

I have no fucking idea what any of this stuff means at the time of writing. I think the {“url” etc is some type of JSON

Screenshot from Mozilla

• Cookies

You can also see what cookies are loaded:

Screenshot source

Network Tab

Shows a timeline of all the assets that are loaded

Security Tab

You can view security info, like info about the secure certificate/server/https thing

Audits Tab – This doesn’t exist anymore – use Lighthouse/Performance Insights Tab

SEO Checks Using Chrome Dev Tools

Notes from SearchEngineJournal article

1. Check If You Content Is Accessible

The DOM – can be seen in the Elements Tab of Inspect-Element, allows you to:

• Review various content elements includng meta title
• Verify if Google can crawl it
  
• A key thing to look for here is the differences between source-code and the contents of the elements tab.
  
  Fucking JavaScript
  When auditing websites that have heavy JavaScript usage, content – such as page headers – sometimes appears fine in the HTML source code. But if injected via JavaScript, it may just show as a JS block in the Elements tab.

This can potentially be an issue, later verified through performing a site:example.com/page “content you’re looking for” advanced search and checking the cached version of the page.

The blog heading here, appears to be fine and stuff:

2. Check on mobile devices

Use the mobile icon on the top menu-bar, next to the “elements | Console” tab options, to see the page in different mobile devices

3. Site Speed

This can really be useful if you’ve blocked your staging website and 3rd party tools can’t access your URL

From the three-dot burger menu in the top right of the screen, you can access Network Conditions (found under More Tools).

you can throttle the network to slow 3G etc

Disable broswer cache

You can also select from a number of user agents ranging from Googlebot Smartphone through to various Microsoft Edge UAs, and Opera.

Once you have setup the setting for the network – go to the NetWork Tab, and see the page load

4. Render Blocking Resources

As mentioned previously, from the Network tab you can identify which JavaScript and CSS resources are being loaded before the DOM.

While this isn’t necessarily an issue on all websites, having resources load ahead of the DOM can potentially lead to it being blocked, which is one of the more common and resolvable site speed issues.

These can be identified by filtering for JS and CSS in the Network tab:

• You can also see which elements, JS, CSS etc have a 200 status code, and which 404 or are blocked

Notes from another SearchEngineJournal Article

Switch Your User-Agent

In order to switch your user-agent in Chrome, use the Network Conditions tab in the console drawer.

Sometimes security measures on a website might stop Googlebot from crawling

Using the User-Ageny tool in dev tools, it’s possible to see if bots are getting blocked

Diagnosing Core Web Vitals in DevTools

Within the timings section, users can see flags for things like FCP (First Contentful Paint), and LCP (Largest Contentful Paint), one of our Core Web Vitals.

In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.

In order to help detect layout shift, use the Rendering tab in the console drawer:

Check the option for Layout Shift Regions, which will highlight areas of the page that undergo a layout shift as content is loaded. (when you go back to the performance tab and refresh)

Layout shifts will then be highlighted in blue as you interact with the page.

3. Double-Check Your HTTP Headers & Review Unused Code

 it’s helpful to see the HTTP response codes for every page and resource.

Go to Network Tab

After selecting a resource, the Headers sub-menu in the Network tab allows us to see a host of information regarding the selected file. (headers appears when you click and choose a file)

This includes all HTTP header information, like the Request URL, the Request Method, the Status Code, content-encoding, last-modified date, server, and so much more.

You can lean on this info to:

• Verify GZip compression is enabled.
• Double-check that cache-control is working as expected.
• Verify we’re sending Googlebot and other user-agents the appropriate status code.

Review Unused Code

Use the console tab

Refresh the page

Click “Issues” section, next to the filter:

SearchEngineLand notes

• View the DOM in the Elements panel, to make sure Google can see it

Use this to review the content of any of the page’s elements (such as the title, meta description or page text) to verify that the desired relevant information is shown in each case, to make sure it’s accessible to Google.

When identifying these differences between the content shown in both, you can then take the appropriate steps to verify it’s being indexed correctly: reviewing the page cached version in Google, verifying if the text is being shown in Google’s results when searching for it, using the “Fetch as Googlebot” in Google Search Console and so on.

3. Find Unused JavaScript & CSS

To look for unused JavaScript & CSS open the Chrome Web Devtools, go to elements and press ctrl+shift+P and type coverage; and then select [Show Coverage]

After selecting show coverage you will see the below screen, now you have to click on reload button as you can see in the screenshot and that will finally lead you to the coverage report that will show you the JS & CSS files.

Chrome DevTools for SEO: 8 Brilliant Ways to Audit a Webpage

How to use Lighthouse in Google Chrome Dev Tools

Using Dev Tools Console Panel to Run JavaScript

Notes from Udemy course you can find here.

You can do a few nifty things, that seem a bit pointless at this point, like for example, calling and seeing how many paragraph <p> tags are on a page:

There are 5 paragraph tags, in the example shown above^

You can change the background colour of elements, like paragraphs:

Put the elements in a variable, and then change them with a loop^

Here i’ve changed the background colour of the paragraphs on vanilla-js.com:

Sources Tab & Basic Debugging

Right click on an element and select “inspect”

Go to the sources tab

You can click on lines of code to create a “breakpoint” so the code stops on that particular line of code

Breakpoints – pauses the code at a specific point

More info on setting up breakpoint to pause code in the Google documentation here

Line-of-code breakpoints

Use a line-of-code breakpoint when you know the exact region of code that you need to investigate. DevTools always pauses before this line of code is executed.

To set a line-of-code breakpoint in DevTools:

1. Click the Sources tab.
2. Open the file containing the line of code you want to break on.
3. Go to the line of code.
4. To the left of the line of code is the line number column. Click on it. A blue icon appears on top of the line number column.

You can view the local and global scope of the code

The “Filesystem” panel, tells you all the files that make up the current page:

Official Google Documentation for Chrome Dev Tools

Google has their own info and tutorial stuff on dev tools here.

Some Tips from Reddit

document.body.innerHTML = [...document.getElementsByTagName("a")].map(el => el.href).join("<br>");

Note from video^

• Elements tab – we can see HTML representation of DOM – check page elements are in the DOM
• Network tab – see what happens between the server and our browser.
  Reload page – and see each request from the server and the response
  You can see where time is spent. We can see each element/request – we can see how long it took including the time the server and download took.
  We can also see http/response headers – make sure there’s no X-robots tags if you want it indexed
  You can click on an element/request, then click on “initiator” and see what requested it:
  

Network tab can also be used to disable the cache, set network speed and the user agent.

Please note that Googlebot might not always work as expected, real Googlebot will respect robots.txt and some sites might do IP lookups to see if a request is really from a data centre.

Some SEO Checks using Developer Tools:

Dev Tools Checks

Inspect main elements – are they visible in the inspect window? e.g. right click and inspect the Headings – check <head> has meta title and desc

Check on mobile devices

Check all the elements result in a 200 – view the Network tab

Network Tab – Check with Googlebot

Console tab – refresh page – what issues are flagged?

Unused JS in the elements tab – coverage

Check for client rendered links using the code above , using the console tab

You can also use a “diff tool” to check the difference between a live DOM copied from dev tools and the view source code.

Add the chrome extension here – https://chrome.google.com/webstore/detail/dom-size-analyzer/mcneiimlodlbmohipgdbbglgbmaoojen

when you right click > Inspect

In the menu with the two arrows >> – you can click that and it has an option to analyze the DOM – which then gives you the number of elements and a few other bits

Just click the arrows, and then “Analyze DOM Size” and click the play icon

• You can also right-click and inspect and type:

Home – click on a website to view their rankings

Dashboard Tab

Graph at the bottom is arguably the most helpful.

• Ranking Averages vs. Distribution Graph
• If you use the date-picker to a date range of less than 2 weeks, you see daily fluctuations
• It can be easier to click the # on the bottom left and view the number of KWs in the top 3

Keywords Tab

Click “show/Hide” on top right

Click “google base rank” and “ranking change” and “ranking URL”

Click on the “change” column. Those keywords with a positive change number, have gone down in rankings

Click on each Keyword to see ranking changes over a set date-range (use date-picker on top right)

Competitive Landscape

Compare latest column, to what the share of voice was 7 days ago, 30 days ago, up to 180 days ago.

Click the “site” menu on the top left column of the whole GUI – and pick a category of keywords to see specific changes

Summary

For an SEO Audit

You want to check that href links and H1s etc are in the source and the rendered HTML

• Rendered HTML, is basically HTML after all the JS has run.

You can view rendered HTML using right click and “inspect” from the drop down menu
This shows the Live DOM, which includes changes made by JavaScript.

• Source HTML – is static HTML, as it was sent from the server to your browser.

This is the raw HTML before anyclient-side JavaScript has been run/executed.

You also want to check that the rendered HTML is not too different to the source HTML.

View the site with JS turned off. Ideally images should still be there and href links should definitely still work with JS turned off.

---

Rendering process – start with the source HTML and CSS.

The browser parses the source html and CSS which creates the DOM and CSSOM.

The DOM is more important for SEO

The browser creates a DOM tree to identify elements on the website and where everything belongs and relates

The browsers takes the DOM and CSSOM and creates a render tree to lay everything out.

The tree is then used to create the actual pixels and layout of what you see.

JS may then be added to manipulate the DOM

You can turn the final DOM Tree, back into HTML – this is Rendered HTML

When you click View Source in your browser

This shows the SOURCE HTML

Developer Tools – Sources – SOURCE HTML

Network Tab in developer tools – SOURCE HTML

In the elements tab in Chrome in Dev Tools – you get the current DOM Content

https://support.google.com/webmasters/answer/11626894?hl=en

Overview

When you visit a page, the website sends HTML code to your browser. Often this source code includes additional resources such as scripts, which must be loaded, and which may alter the page code.

How to view Source HTML (Ctrl + U)

Right-clicking “show source” typically shows only the original page code returned to the browser, before scripts and other resources have been loaded and run. But there are many instances, particularly when troubleshooting your page, when you need to see the code of the final, rendered page on the browser, after all resources have been loaded, and any scripts run. For example:

• To search for Google Analytics or Google Tag Manager tags used in verification.
• To debug page loading and display (that is, to check that all libraries and other resources that you want to be loaded are).
• To look at structured data on the served page.

How to view the rendered source (Inspect Element)

Here are a few methods to view the rendered source code for a web page:

• In the Chrome browser: Right-click any part of the page and select Inspect to see all the HTML from the rendered page. Search for items in the rendered HTML with Control + F (Windows) or Command + F (Mac).
• For a page on your own site:
  1. Inspect the URL, either by entering the URL directly in the URL Inspection tool, or by clicking an inspection link next to a URL shown in most Search Console reports.
  2. Click Test live URL > View tested page.
  3. The HTML tab shows the rendered HTML for the page.
• For a page on any site, not just a site that you own:
  1. Open the Mobile-friendly Test.
  2. Enter the URL of the page. The page must be available to Google without a login, and not blocked by robots.txt.
  3. Click View tested page.
  4. The HTML tab shows the rendered HTML for the page.