Chrome Develop Tools – for SEO (2023) (inspect Element)

By Geoff Griffiths @mmatraining1980

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:

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