Learn the fundamentals of Search Engine Optimization (SEO) from the perspective of a web developer. Determine the optimal way to structure and render HTML for bots https://fireship.io/courses/react-next-firebase/

PRO Membership Discount 30% Code: fZGT5HZT

*Discount Expires on Friday 2/12

Technical overview https://developers.google.com/web/updates/2019/02/rendering-on-the-web
ISR https://nextjs.org/docs/basic-features/data-fetching#incremental-static-regeneration

00:00 What is SEO
02:01 Create Good Content
03:54 HTML Structure
07:09 Rendering Strategies

#webdev #seo #100SecondsOfCode

My VS Code Theme

- Atom One Dark 
- vscode-icons
- Fira Code Font
2024-02-04T05:58:10.686Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
59f4df74-dbe6-4fad-8bb9-4db4b2617794
3e9004c3695d1f33a0231d584894ea9b91a153ab67f247e132535c488c5d8490
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
The first rule of search engine optimization is create really good content.
The second rule of search engine optimization is create really good content.
If human beings don't want to engage with your content, then Google doesn't want to either.
We live in the age of machine learning and quantum computing.
You can't just stuff a bunch of keywords into a page and expect to do well.
When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had.
People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank.
Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts.
The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats.
But some say it's a dying industry.
3.
Don't wanna see a dead body.
Because it's becoming harder and harder to manipulate Google's technology.
There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site.
Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content.
Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots.
Your main content goes inside the body tags.
When Google crawls your site, it will use semantic HTML elements to understand the content on the page.
You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about.
Furthermore, your HTML should be accessible.
Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices.
In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing.
The 4th rule of SEO is to get your fully rendered HTML loaded fast.
If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site.
But going fast is easier said than done.
That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization.
If you're new here, like and subscribe.
And today, I have a big announcement.
My full Next JS Firebase course is now available.
If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course.
Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly.
The first two rules are very subjective and depend entirely on your audience.
But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible.
There are a few metrics that you'll wanna be aware of here.
The first one is the click through rate or CTR.
That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP.
The higher the CTR, the better, and that usually means you have a very relevant title and description.
Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce.
And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant.
If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results.
The longer the dwell time, the better.
But the best possible thing that can happen is that the user never clicks back.
Their session will last forever, and they'll never need to go to another website ever again.
That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session.
These are metrics that you want to maximize.
There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more.
If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good.
Let's move on to rule 3 where we talk about the actual structure of the HTML.
I'll be using my site, FireShip I o, as an example.
On a lesson or article page, you can right click and hit inspect element or hit control shift I.
This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup.
We have a head and a body.
Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article.
An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page.
In addition, you'll notice a couple of extra attributes here.
1 is item scope and the other is an item type as a schema dot org article.
Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret.
It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page.
Now, in this case, we have a bunch of metadata that make up an article.
And one thing that is known to improve search ranking is when an article is written by a known author.
Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page.
That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author.
Outbound links on a page are really important because they further signal what the page is about.
In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is.
A good strategy is to use outbound links to other really good sites that are related to the content on a given page.
Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility.
One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image.
This metadata can be used by search engines and also by screen readers for those with disabilities.
For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page.
At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO.
Most importantly, this is where you have the title.
You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating.
In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that.
These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook.
When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there.
If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags.
So that gives you some things to think about when it comes to the actual structure of your HTML.
But the bigger question is how do you render that HTML?
Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user.
There are 3 fundamental ways to render HTML.
The first one we'll look at is client side rendering.
If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application.
On the initial page load, the user gets a shell of HTML without any meaningful content.
The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI.
Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android.
The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it.
If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell.
You won't see any additional meta tags that were generated by Java script after the fact.
That's not great for social media, but Google, as a search engine, is able to index client rendered apps.
But the reliability is questionable.
And personally, I wouldn't trust client rendering if SEO was a business critical requirement.
So another option is to pre render or statically generate HTML in advance.
Let's imagine your web app has a 100 different routes or pages.
Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN.
So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive.
That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page.
It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data.
The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site.
That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale.
And that brings us to option number 3, server side rendering.
In this paradigm, when the user makes a request to a page, the HTML is generated on the server.
This is also great for SEO because bots get fully rendered HTML on the initial request.
In addition, the data will always be fresh because you're making a new request to the server each time.
But the drawback here is that it's generally less efficient.
You might be fetching and rendering the same HTML over and over again.
It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale.
And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO.
So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity.
But what if there is a way we could have our cake and eat it too?
Allow me to introduce you to incremental static regeneration.
This is the way.
This is the way.
This is the way.
This is a new form of rendering available in the Next JS framework.
Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site.
What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site.
That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data.
That eliminates all of the trade offs that we've talked about, but it's not without a cost.
Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment.
For most of us, that means paying for a host that supports it like Vercel.
But hosting anywhere else will likely be much more painful until more companies start adopting these techniques.
Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering.
That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered.
So you're not pigeonholed into just one rendering technique.
You can pick and choose what works best for a given page.
And in my opinion, that's the future of full stack web development.
I'm gonna go ahead and wrap things up there.
If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio.
You'll get access to the next course along with a whole bunch of other pro content.
Thanks for watching, and I will see you in the next one.

Speaker 0: The first rule of search engine optimization is create really good content. The second rule of search engine optimization is create really good content. If human beings don't want to engage with your content, then Google doesn't want to either. We live in the age of machine learning and quantum computing. You can't just stuff a bunch of keywords into a page and expect to do well.

When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had. People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank. Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts. The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats. But some say it's a dying industry.

3. Don't wanna see a dead body. Because it's becoming harder and harder to manipulate Google's technology. There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site. Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content.

Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots. Your main content goes inside the body tags. When Google crawls your site, it will use semantic HTML elements to understand the content on the page. You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about. Furthermore, your HTML should be accessible.

Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices. In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing. The 4th rule of SEO is to get your fully rendered HTML loaded fast. If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site. But going fast is easier said than done.

That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization. If you're new here, like and subscribe. And today, I have a big announcement. My full Next JS Firebase course is now available. If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course.

Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly. The first two rules are very subjective and depend entirely on your audience. But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible. There are a few metrics that you'll wanna be aware of here. The first one is the click through rate or CTR.

That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP. The higher the CTR, the better, and that usually means you have a very relevant title and description. Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce. And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant. If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results.

The longer the dwell time, the better. But the best possible thing that can happen is that the user never clicks back. Their session will last forever, and they'll never need to go to another website ever again. That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session. These are metrics that you want to maximize.

There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more. If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good. Let's move on to rule 3 where we talk about the actual structure of the HTML. I'll be using my site, FireShip I o, as an example. On a lesson or article page, you can right click and hit inspect element or hit control shift I.

This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup. We have a head and a body. Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article. An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page. In addition, you'll notice a couple of extra attributes here.

1 is item scope and the other is an item type as a schema dot org article. Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret. It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page. Now, in this case, we have a bunch of metadata that make up an article. And one thing that is known to improve search ranking is when an article is written by a known author.

Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page. That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author. Outbound links on a page are really important because they further signal what the page is about. In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is. A good strategy is to use outbound links to other really good sites that are related to the content on a given page.

Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility. One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image. This metadata can be used by search engines and also by screen readers for those with disabilities. For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page. At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO.

Most importantly, this is where you have the title. You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating. In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that. These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook. When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there.

If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags. So that gives you some things to think about when it comes to the actual structure of your HTML. But the bigger question is how do you render that HTML? Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user. There are 3 fundamental ways to render HTML.

The first one we'll look at is client side rendering. If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application. On the initial page load, the user gets a shell of HTML without any meaningful content. The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI. Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android.

The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it. If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell. You won't see any additional meta tags that were generated by Java script after the fact. That's not great for social media, but Google, as a search engine, is able to index client rendered apps. But the reliability is questionable.

And personally, I wouldn't trust client rendering if SEO was a business critical requirement. So another option is to pre render or statically generate HTML in advance. Let's imagine your web app has a 100 different routes or pages. Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN. So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive.

That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page. It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data. The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site. That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale. And that brings us to option number 3, server side rendering.

In this paradigm, when the user makes a request to a page, the HTML is generated on the server. This is also great for SEO because bots get fully rendered HTML on the initial request. In addition, the data will always be fresh because you're making a new request to the server each time. But the drawback here is that it's generally less efficient. You might be fetching and rendering the same HTML over and over again.

It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale. And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO. So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity. But what if there is a way we could have our cake and eat it too? Allow me to introduce you to incremental static regeneration.

This is the way. This is the way. This is the way. This is a new form of rendering available in the Next JS framework. Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site.

What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site. That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data. That eliminates all of the trade offs that we've talked about, but it's not without a cost. Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment. For most of us, that means paying for a host that supports it like Vercel.

But hosting anywhere else will likely be much more painful until more companies start adopting these techniques. Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering. That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered. So you're not pigeonholed into just one rendering technique. You can pick and choose what works best for a given page.

And in my opinion, that's the future of full stack web development. I'm gonna go ahead and wrap things up there. If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio. You'll get access to the next course along with a whole bunch of other pro content. Thanks for watching, and I will see you in the next one.
The first rule of search engine optimization is create really good content. The second rule of search engine optimization is create really good content. If human beings don't want to engage with your content, then Google doesn't want to either. We live in the age of machine learning and quantum computing. You can't just stuff a bunch of keywords into a page and expect to do well. When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had. People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank. Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts. The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats. But some say it's a dying industry. 3. Don't wanna see a dead body. Because it's becoming harder and harder to manipulate Google's technology. There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site. Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content.
google
machine learning
mining
websites
Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots. Your main content goes inside the body tags. When Google crawls your site, it will use semantic HTML elements to understand the content on the page. You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about. Furthermore, your HTML should be accessible. Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices. In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing. The 4th rule of SEO is to get your fully rendered HTML loaded fast. If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site. But going fast is easier said than done. That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization.
google
websites
If you're new here, like and subscribe. And today, I have a big announcement. My full Next JS Firebase course is now available. If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course.
Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly. The first two rules are very subjective and depend entirely on your audience. But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible. There are a few metrics that you'll wanna be aware of here.
commerce
google
The first one is the click through rate or CTR. That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP. The higher the CTR, the better, and that usually means you have a very relevant title and description. Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce.
And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant. If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results. The longer the dwell time, the better. But the best possible thing that can happen is that the user never clicks back.
google
Their session will last forever, and they'll never need to go to another website ever again. That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session.
These are metrics that you want to maximize. There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more. If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good. Let's move on to rule 3 where we talk about the actual structure of the HTML.
animation
graphic design
visualization
youtube
toys
multimedia
I'll be using my site, FireShip I o, as an example. On a lesson or article page, you can right click and hit inspect element or hit control shift I. This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup. We have a head and a body. Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article. An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page. In addition, you'll notice a couple of extra attributes here. 1 is item scope and the other is an item type as a schema dot org article.
Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret. It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page. Now, in this case, we have a bunch of metadata that make up an article. And one thing that is known to improve search ranking is when an article is written by a known author. Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page.
google
magazines
newspaper
intellectual property
publishing
blogging
That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author.
Outbound links on a page are really important because they further signal what the page is about. In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is. A good strategy is to use outbound links to other really good sites that are related to the content on a given page. Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility. One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image. This metadata can be used by search engines and also by screen readers for those with disabilities. For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page.
websites
google
visualization
multimedia
blogging
At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO. Most importantly, this is where you have the title. You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating. In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that.
These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook. When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there. If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags. So that gives you some things to think about when it comes to the actual structure of your HTML.
twitter
But the bigger question is how do you render that HTML? Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user. There are 3 fundamental ways to render HTML. The first one we'll look at is client side rendering. If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application. On the initial page load, the user gets a shell of HTML without any meaningful content. The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI.
Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android. The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it. If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell.
google
You won't see any additional meta tags that were generated by Java script after the fact. That's not great for social media, but Google, as a search engine, is able to index client rendered apps. But the reliability is questionable. And personally, I wouldn't trust client rendering if SEO was a business critical requirement.
google
So another option is to pre render or statically generate HTML in advance. Let's imagine your web app has a 100 different routes or pages. Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN.
So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive. That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page. It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data. The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site.
databases
data management
data
google
That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale. And that brings us to option number 3, server side rendering. In this paradigm, when the user makes a request to a page, the HTML is generated on the server. This is also great for SEO because bots get fully rendered HTML on the initial request. In addition, the data will always be fresh because you're making a new request to the server each time. But the drawback here is that it's generally less efficient. You might be fetching and rendering the same HTML over and over again. It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale.
And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO. So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity. But what if there is a way we could have our cake and eat it too?
commerce
desserts
Allow me to introduce you to incremental static regeneration. This is the way. This is the way. This is the way. This is a new form of rendering available in the Next JS framework. Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site. What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site. That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data. That eliminates all of the trade offs that we've talked about, but it's not without a cost. Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment. For most of us, that means paying for a host that supports it like Vercel. But hosting anywhere else will likely be much more painful until more companies start adopting these techniques. Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering. That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered. So you're not pigeonholed into just one rendering technique. You can pick and choose what works best for a given page. And in my opinion, that's the future of full stack web development. I'm gonna go ahead and wrap things up there. If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio.
You'll get access to the next course along with a whole bunch of other pro content. Thanks for watching, and I will see you in the next one.
entertainment
websites
The first rule of search engine optimization is create really good content. The second rule of search engine optimization is create really good content. If human beings don't want to engage with your content, then Google doesn't want to either. We live in the age of machine learning and quantum computing. You can't just stuff a bunch of keywords into a page and expect to do well. When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had. People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank. Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts. The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats. But some say it's a dying industry. 3. Don't wanna see a dead body. Because it's becoming harder and harder to manipulate Google's technology. There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site. Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content. Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots. Your main content goes inside the body tags. When Google crawls your site, it will use semantic HTML elements to understand the content on the page. You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about. Furthermore, your HTML should be accessible. Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices. In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing. The 4th rule of SEO is to get your fully rendered HTML loaded fast. If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site. But going fast is easier said than done. That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization. If you're new here, like and subscribe. And today, I have a big announcement. My full Next JS Firebase course is now available. If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course. Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly. The first two rules are very subjective and depend entirely on your audience. But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible. There are a few metrics that you'll wanna be aware of here. The first one is the click through rate or CTR. That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP. The higher the CTR, the better, and that usually means you have a very relevant title and description. Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce. And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant. If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results. The longer the dwell time, the better. But the best possible thing that can happen is that the user never clicks back. Their session will last forever, and they'll never need to go to another website ever again. That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session. These are metrics that you want to maximize. There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more. If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good. Let's move on to rule 3 where we talk about the actual structure of the HTML. I'll be using my site, FireShip I o, as an example. On a lesson or article page, you can right click and hit inspect element or hit control shift I. This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup. We have a head and a body. Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article. An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page. In addition, you'll notice a couple of extra attributes here. 1 is item scope and the other is an item type as a schema dot org article. Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret. It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page. Now, in this case, we have a bunch of metadata that make up an article. And one thing that is known to improve search ranking is when an article is written by a known author. Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page. That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author. Outbound links on a page are really important because they further signal what the page is about. In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is. A good strategy is to use outbound links to other really good sites that are related to the content on a given page. Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility. One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image. This metadata can be used by search engines and also by screen readers for those with disabilities. For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page. At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO. Most importantly, this is where you have the title. You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating. In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that. These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook. When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there. If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags. So that gives you some things to think about when it comes to the actual structure of your HTML. But the bigger question is how do you render that HTML? Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user. There are 3 fundamental ways to render HTML. The first one we'll look at is client side rendering. If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application. On the initial page load, the user gets a shell of HTML without any meaningful content. The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI. Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android. The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it. If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell. You won't see any additional meta tags that were generated by Java script after the fact. That's not great for social media, but Google, as a search engine, is able to index client rendered apps. But the reliability is questionable. And personally, I wouldn't trust client rendering if SEO was a business critical requirement. So another option is to pre render or statically generate HTML in advance. Let's imagine your web app has a 100 different routes or pages. Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN. So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive. That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page. It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data. The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site. That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale. And that brings us to option number 3, server side rendering. In this paradigm, when the user makes a request to a page, the HTML is generated on the server. This is also great for SEO because bots get fully rendered HTML on the initial request. In addition, the data will always be fresh because you're making a new request to the server each time. But the drawback here is that it's generally less efficient. You might be fetching and rendering the same HTML over and over again. It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale. And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO. So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity. But what if there is a way we could have our cake and eat it too? Allow me to introduce you to incremental static regeneration. This is the way. This is the way. This is the way. This is a new form of rendering available in the Next JS framework. Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site. What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site. That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data. That eliminates all of the trade offs that we've talked about, but it's not without a cost. Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment. For most of us, that means paying for a host that supports it like Vercel. But hosting anywhere else will likely be much more painful until more companies start adopting these techniques. Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering. That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered. So you're not pigeonholed into just one rendering technique. You can pick and choose what works best for a given page. And in my opinion, that's the future of full stack web development. I'm gonna go ahead and wrap things up there. If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio. You'll get access to the next course along with a whole bunch of other pro content. Thanks for watching, and I will see you in the next one.
The
the
first
first
rule
rule
of
of
search
search
engine
engine
optimization
optimization
is
is
create
create
really
really
good
good
content.
content
The
the
second
second
rule
rule
of
of
search
search
engine
engine
optimization
optimization
is
is
create
create
really
really
good
good
content.
content
If
if
human
human
beings
beings
don't
don't
want
want
to
to
engage
engage
with
with
your
your
content,
content
then
then
Google
google
doesn't
doesn't
want
want
to
to
either.
either
We
we
live
live
in
in
the
the
age
age
of
of
machine
machine
learning
learning
and
and
quantum
quantum
computing.
computing
You
you
can't
can't
just
just
stuff
stuff
a
a
bunch
bunch
of
of
keywords
keywords
into
into
a
a
page
page
and
and
expect
expect
to
to
do
do
well.
well
When
when
Google
google
first
first
came
came
about
about
in
in
the
the
late
late
nineties,
nineties
it
it
was
was
based
based
on
on
an
an
algorithm
algorithm
called
called
PageRank,
pagerank
which
which
weighted
weighted
relevance
relevance
and
and
search
search
ranking
ranking
based
based
on
on
the
the
number
number
of
of
inbound
inbound
links
links
that
that
a
a
site
site
had.
had
People
people
quickly
quickly
learned
learned
how
how
to
to
exploit
exploit
the
the
algorithm
algorithm
by
by
spamming
spamming
backlinks
backlinks
all
all
over
over
the
the
Internet
internet
to
to
increase
increase
a
a
site's
site's
page
page
rank.
rank
Because
because
a
a
high
high
ranking
ranking
in
in
Google
google
can
can
literally
literally
be
be
worth
worth
1,000,000
1,000,000
of
of
dollars,
dollars
it
it
brought
brought
us
us
an
an
entire
entire
industry
industry
of
of
SEO
seo
experts.
experts
The
the
good
good
guys
guys
wear
wear
white
white
hats,
hats
the
the
hackers
hackers
wear
wear
black
black
hats,
hats
but
but
the
the
most
most
effective
effective
ones
ones
wear
wear
gray
gray
hats.
hats
But
but
some
some
say
say
it's
it's
a
a
dying
dying
industry.
industry
3.
3
Don't
don't
wanna
wanna
see
see
a
a
dead
dead
body.
body
Because
because
it's
it's
becoming
becoming
harder
harder
and
and
harder
harder
to
to
manipulate
manipulate
Google's
google's
technology.
technology
There
there
are
are
over
over
200
200
factors
factors
that
that
go
go
into
into
a
a
site's
site's
ranking
ranking
that
that
are
are
geared
geared
mostly
mostly
towards
towards
how
how
useful
useful
a
a
user
user
found
found
your
your
site.
site
Did
did
they
they
immediately
immediately
bounce
bounce
by
by
clicking
clicking
the
the
back
back
button,
button
or
or
did
did
they
they
dwell
dwell
on
on
the
the
page
page
for
for
a
a
long
long
time
time
and
and
click
click
other
other
links,
links
absorbing
absorbing
all
all
kinds
kinds
of
of
useful
useful
content.
content
Content
content
is
is
king,
king
but
but
the
the
third
third
rule
rule
of
of
SEO
seo
is
is
to
to
render
render
HTML
html
that
that
can
can
be
be
reliably
reliably
stood
stood
by
by
bots.
bots
Your
your
main
main
content
content
goes
goes
inside
inside
the
the
body
body
tags.
tags
When
when
Google
google
crawls
crawls
your
your
site,
site
it
it
will
will
use
use
semantic
semantic
HTML
html
elements
elements
to
to
understand
understand
the
the
content
content
on
on
the
the
page.
page
You
you
might
might
put
put
your
your
main
main
content
content
in
in
an
an
article
article
tag,
tag
then
then
put
put
your
your
most
most
important
important
keywords
keywords
and
and
headings
headings
or
or
h
h
tags
tags
to
to
signal
signal
what
what
your
your
page
page
is
is
about.
about
Furthermore,
furthermore
your
your
HTML
html
should
should
be
be
accessible.
accessible
Use
use
alt
alt
tags
tags
and
and
images
images
and
and
ARIA
aria
tags
tags
where
where
needed
needed
to
to
make
make
your
your
site
site
usable
usable
on
on
assistive
assistive
devices.
devices
In
in
the
the
head
head
of
of
the
the
document,
document
we
we
have
have
metadata
metadata
that's
that's
not
not
directly
directly
shown
shown
to
to
the
the
end
end
user,
user
but
but
bots
bots
can
can
use
use
this
this
data
data
to
to
further
further
understand
understand
the
the
page
page
and
and
format
format
the
the
actual
actual
appearance
appearance
of
of
your
your
search
search
engine
engine
listing.
listing
The
the
4th
4th
rule
rule
of
of
SEO
seo
is
is
to
to
get
get
your
your
fully
fully
rendered
rendered
HTML
html
loaded
loaded
fast.
fast
If
if
you
you
have
have
megabytes
megabytes
of
of
blocking
blocking
images,
images
styles,
styles
and
and
JavaScript,
javascript
both
both
users
users
and
and
bots
bots
will
will
pass
pass
on
on
your
your
site.
site
But
but
going
going
fast
fast
is
is
easier
easier
said
said
than
than
done.
done
That's
that's
why
why
today,
today
we're
we're
going
going
beyond
beyond
100
100
seconds
seconds
to
to
look
look
at
at
the
the
many
many
different
different
strategies
strategies
we
we
have
have
to
to
render
render
HTML
html
and
and
how
how
they
they
impact
impact
search
search
engine
engine
optimization.
optimization
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe.
subscribe
And
and
today,
today
I
i
have
have
a
a
big
big
announcement.
announcement
My
my
full
full
Next
next
JS
js
Firebase
firebase
course
course
is
is
now
now
available.
available
If
if
your
your
goal
goal
is
is
to
to
build
build
a
a
highly
highly
interactive
interactive
web
web
app
app
that
that
is
is
also
also
fully
fully
search
search
engine
engine
friendly,
friendly
then
then
you'll
you'll
definitely
definitely
want
want
to
to
check
check
out
out
this
this
course.
course
Now
now
the
the
4
4
most
most
important
important
rules
rules
for
for
SEO,
seo
in
in
my
my
opinion,
opinion
are
are
create
create
awesome
awesome
content,
content
create
create
awesome
awesome
content,
content
render
render
properly
properly
formatted
formatted
HTML,
html
and
and
load
load
your
your
HTML
html
quickly.
quickly
The
the
first
first
two
two
rules
rules
are
are
very
very
subjective
subjective
and
and
depend
depend
entirely
entirely
on
on
your
your
audience.
audience
But
but
the
the
general
general
goal
goal
is
is
that
that
when
when
someone
someone
clicks
clicks
on
on
a
a
link
link
to
to
your
your
site
site
from
from
a
a
search
search
engine
engine
ranking
ranking
page,
page
they
they
should
should
engage
engage
with
with
your
your
site
site
as
as
long
long
as
as
possible.
possible
There
there
are
are
a
a
few
few
metrics
metrics
that
that
you'll
you'll
wanna
wanna
be
be
aware
aware
of
of
here.
here
The
the
first
first
one
one
is
is
the
the
click
click
through
through
rate
rate
or
or
CTR.
ctr
That
that
defines
defines
how
how
likely
likely
a
a
user
user
is
is
to
to
click
click
on
on
your
your
link
link
when
when
displayed
displayed
in
in
a
a
search
search
engine
engine
ranking
ranking
page
page
or
or
SERP.
serp
The
the
higher
higher
the
the
CTR,
ctr
the
the
better,
better
and
and
that
that
usually
usually
means
means
you
you
have
have
a
a
very
very
relevant
relevant
title
title
and
and
description.
description
Now
now
if
if
a
a
user
user
clicks
clicks
on
on
your
your
link
link
and
and
then
then
immediately
immediately
clicks
clicks
the
the
back
back
button,
button
that's
that's
called
called
a
a
bounce.
bounce
And
and
the
the
higher
higher
your
your
bounce
bounce
rate
rate
is,
is
the
the
less
less
likely
likely
your
your
site
site
is
is
to
to
rank
rank
well
well
in
in
the
the
long
long
term
term
because,
because
apparently,
apparently
the
the
content
content
on
on
the
the
page
page
is
is
not
not
very
very
relevant.
relevant
If
if
the
the
user
user
does
does
stay
stay
on
on
the
the
page,
page
Google
google
will
will
keep
keep
track
track
of
of
the
the
dwell
dwell
time,
time
which
which
is
is
the
the
amount
amount
of
of
time
time
they
they
spend
spend
there
there
before
before
clicking
clicking
back
back
to
to
the
the
search
search
results.
results
The
the
longer
longer
the
the
dwell
dwell
time,
time
the
the
better.
better
But
but
the
the
best
best
possible
possible
thing
thing
that
that
can
can
happen
happen
is
is
that
that
the
the
user
user
never
never
clicks
clicks
back.
back
Their
their
session
session
will
will
last
last
forever,
forever
and
and
they'll
they'll
never
never
need
need
to
to
go
go
to
to
another
another
website
website
ever
ever
again.
again
That
that
doesn't
doesn't
happen
happen
very
very
often,
often
so
so
what
what
you
you
keep
keep
track
track
of
of
is
is
the
the
average
average
session
session
duration
duration
and
and
the
the
average
average
number
number
of
of
pages
pages
viewed
viewed
per
per
session.
session
These
these
are
are
metrics
metrics
that
that
you
you
want
want
to
to
maximize.
maximize
There's
there's
no
no
absolute
absolute
rule
rule
for
for
creating
creating
engaging
engaging
content,
content
but
but
the
the
first
first
thing
thing
the
the
user
user
sees
sees
should
should
hook
hook
them
them
in
in
to
to
want
want
to
to
read
read
more.
more
If
if
you
you
look
look
at
at
something
something
like
like
BuzzFeed,
buzzfeed
all
all
all
all
you
you
have
have
to
to
do
do
is
is
put
put
an
an
animated
animated
GIF
gif
at
at
the
the
top,
top
then
then
maybe
maybe
a
a
few
few
more
more
in
in
the
the
body,
body
and
and
you
you
should
should
be
be
good.
good
Let's
let's
move
move
on
on
to
to
rule
rule
3
3
where
where
we
we
talk
talk
about
about
the
the
actual
actual
structure
structure
of
of
the
the
HTML.
html
I'll
i'll
be
be
using
using
my
my
site,
site
FireShip
fireship
I
i
o,
o
as
as
an
an
example.
example
On
on
a
a
lesson
lesson
or
or
article
article
page,
page
you
you
can
can
right
right
click
click
and
and
hit
hit
inspect
inspect
element
element
or
or
hit
hit
control
control
shift
shift
I.
i
This
this
will
will
bring
bring
up
up
the
the
elements
elements
tab
tab
in
in
Chrome
chrome
Dev
dev
Tools
tools
showing
showing
you
you
the
the
fully
fully
rendered
rendered
HTML
html
markup.
markup
We
we
have
have
a
a
head
head
and
and
a
a
body.
body
Let's
let's
go
go
ahead
ahead
and
and
open
open
up
up
the
the
body,
body
find
find
the
the
main
main
element,
element
then
then
inside
inside
the
the
main
main
element,
element
you'll
you'll
notice
notice
we
we
have
have
an
an
article.
article
An
an
article
article
element
element
has
has
semantic
semantic
meaning,
meaning
and
and
although
although
it
it
will
will
never
never
be
be
seen
seen
by
by
the
the
end
end
user,
user
it
it
tells
tells
the
the
search
search
engine,
engine
here
here
is
is
the
the
main
main
content
content
of
of
the
the
page.
page
In
in
addition,
addition
you'll
you'll
notice
notice
a
a
couple
couple
of
of
extra
extra
attributes
attributes
here.
here
1
1
is
is
item
item
scope
scope
and
and
the
the
other
other
is
is
an
an
item
item
type
type
as
as
a
a
schema
schema
dot
dot
org
org
article.
article
Now
now
it's
it's
totally
totally
optional
optional
and
and
whether
whether
or
or
not
not
it
it
will
will
improve
improve
your
your
search
search
engine
engine
ranking
ranking
is
is
debatable,
debatable
but
but
what
what
schema.org
schema.org
allows
allows
you
you
to
to
do
do
is
is
define
define
a
a
bunch
bunch
of
of
metadata
metadata
about
about
the
the
actual
actual
content
content
on
on
your
your
page,
page
making
making
it
it
easier
easier
for
for
search
search
engines
engines
to
to
interpret.
interpret
It's
it's
especially
especially
powerful
powerful
if
if
your
your
content
content
is
is
something
something
like
like
a
a
recipe
recipe
or
or
a
a
star
star
review
review
because
because
Google
google
can
can
then
then
take
take
the
the
schema
schema
data
data
and
and
format
format
it
it
properly
properly
in
in
a
a
SERP
serp
page.
page
Now,
now
in
in
this
this
case,
case
we
we
have
have
a
a
bunch
bunch
of
of
metadata
metadata
that
that
make
make
up
up
an
an
article.
article
And
and
one
one
thing
thing
that
that
is
is
known
known
to
to
improve
improve
search
search
ranking
ranking
is
is
when
when
an
an
article
article
is
is
written
written
by
by
a
a
known
known
author.
author
Further
further
down
down
the
the
HTML
html
tree
tree
here,
here
you'll
you'll
notice
notice
we
we
have
have
an
an
item
item
prop
prop
of
of
author
author
which
which
points
points
to
to
the
the
author's
author's
page.
page
That
that
link
link
goes
goes
to
to
another
another
page
page
on
on
Fireship
fireship
IO,
io
and
and
on
on
that
that
page,
page
we
we
also
also
have
have
an
an
article
article
element,
element
this
this
time
time
with
with
an
an
item
item
type
type
of
of
a
a
schema.org
schema.org
author,
author
along
along
with
with
a
a
bunch
bunch
of
of
links
links
that
that
point
point
to
to
authoritative
authoritative
sites
sites
for
for
that
that
author.
author
Outbound
outbound
links
links
on
on
a
a
page
page
are
are
really
really
important
important
because
because
they
they
further
further
signal
signal
what
what
the
the
page
page
is
is
about.
about
In
in
this
this
case,
case
Google
google
will
will
first
first
crawl
crawl
the
the
article,
article
then
then
crawl
crawl
the
the
author's
author's
page,
page
then
then
crawl
crawl
these
these
other
other
sites
sites
to
to
understand
understand
who
who
that
that
author
author
is.
is
A
a
good
good
strategy
strategy
is
is
to
to
use
use
outbound
outbound
links
links
to
to
other
other
really
really
good
good
sites
sites
that
that
are
are
related
related
to
to
the
the
content
content
on
on
a
a
given
given
page.
page
Now
now
in
in
addition
addition
to
to
schema.org,
schema.org
there's
there's
other
other
ways
ways
you
you
can
can
add
add
metadata
metadata
to
to
your
your
content,
content
and
and
this
this
can
can
be
be
very
very
important
important
for
for
SEO
seo
and
and
also
also
accessibility.
accessibility
One
one
of
of
the
the
most
most
fundamental
fundamental
techniques
techniques
is
is
to
to
add
add
an
an
alt
alt
attribute
attribute
to
to
images,
images
which
which
is
is
basically
basically
just
just
some
some
text
text
that
that
describes
describes
the
the
image.
image
This
this
metadata
metadata
can
can
be
be
used
used
by
by
search
search
engines
engines
and
and
also
also
by
by
screen
screen
readers
readers
for
for
those
those
with
with
disabilities.
disabilities
For
for
other
other
elements
elements
that
that
are
are
a
a
little
little
more
more
complicated,
complicated
like
like
a
a
progress
progress
bar,
bar
for
for
example,
example
you
you
can
can
use
use
ARIA
aria
attributes,
attributes
which
which
stand
stand
for
for
accessible
accessible
rich
rich
Internet
internet
applications,
applications
and
and
they
they
help
help
provide
provide
additional
additional
meaning
meaning
to
to
highly
highly
interactive
interactive
widgets
widgets
on
on
the
the
page.
page
At
at
this
this
point,
point
we've
we've
only
only
been
been
looking
looking
in
in
the
the
body
body
of
of
the
the
document,
document
but
but
the
the
head
head
of
of
the
the
document
document
contains
contains
all
all
kinds
kinds
of
of
useful
useful
metadata
metadata
for
for
SEO.
seo
Most
most
importantly,
importantly
this
this
is
is
where
where
you
you
have
have
the
the
title.
title
You
you
should
should
choose
choose
your
your
title
title
carefully
carefully
because
because
it's
it's
displayed
displayed
in
in
a
a
SERP
serp
page
page
and
and
will
will
ultimately
ultimately
control
control
your
your
CTR
ctr
rating.
rating
In
in
addition
addition
to
to
the
the
title,
title
you
you
you
you
may
may
also
also
wanna
wanna
have
have
meta
meta
tags
tags
here,
here
which
which
define
define
things
things
like
like
the
the
description,
description
featured
featured
image,
image
author,
author
canonical
canonical
URL,
url
and
and
stuff
stuff
like
like
that.
that
These
these
meta
meta
tags
tags
are
are
also
also
essential
essential
if
if
you
you
want
want
your
your
content
content
to
to
be
be
shared
shared
on
on
social
social
media
media
sites
sites
like
like
Twitter
twitter
or
or
Facebook.
facebook
When
when
you
you
post
post
a
a
hyperlink
hyperlink
in
in
social
social
media,
media
it
it
fetches
fetches
that
that
page
page
and
and
looks
looks
for
for
the
the
meta
meta
tags
tags
to
to
understand
understand
what
what
image
image
and
and
title
title
to
to
display
display
there.
there
If
if
you
you
wanna
wanna
see
see
how
how
your
your
site's
site's
doing
doing
right
right
now,
now
you
you
can
can
post
post
a
a
link
link
into
into
the
the
Twitter
twitter
card
card
validator,
validator
and
and
it
it
will
will
tell
tell
you
you
whether
whether
or
or
not
not
it
it
can
can
use
use
your
your
current
current
meta
meta
tags.
tags
So
so
that
that
gives
gives
you
you
some
some
things
things
to
to
think
think
about
about
when
when
it
it
comes
comes
to
to
the
the
actual
actual
structure
structure
of
of
your
your
HTML.
html
But
but
the
the
bigger
bigger
question
question
is
is
how
how
do
do
you
you
render
render
that
that
HTML?
html
Or
or
in
in
other
other
words,
words
what
what
part
part
of
of
your
your
tech
tech
stack
stack
is
is
responsible
responsible
for
for
generating
generating
the
the
actual
actual
HTML
html
markup
markup
it
it
is
is
received
received
by
by
a
a
bot
bot
or
or
end
end
user.
user
There
there
are
are
3
3
fundamental
fundamental
ways
ways
to
to
render
render
HTML.
html
The
the
first
first
one
one
we'll
we'll
look
look
at
at
is
is
client
client
side
side
rendering.
rendering
If
if
you're
you're
building
building
an
an
app
app
with
with
something
something
like
like
React
react
or
or
Angular,
angular
the
the
default
default
mode
mode
is
is
client
client
side
side
rendering
rendering
or
or
a
a
single
single
page
page
application.
application
On
on
the
the
initial
initial
page
page
load,
load
the
the
user
user
gets
gets
a
a
shell
shell
of
of
HTML
html
without
without
any
any
meaningful
meaningful
content.
content
The
the
JavaScript
javascript
code
code
then
then
bootstraps,
bootstraps
then
then
asynchronously
asynchronously
fetches
fetches
any
any
additional
additional
data
data
needed
needed
for
for
the
the
UI.
ui
Apps
apps
like
like
this
this
are
are
great
great
for
for
interactivity
interactivity
because
because
it
it
gives
gives
the
the
end
end
user
user
an
an
app
app
like
like
feel
feel
similar
similar
to
to
what
what
you'd
you'd
expect
expect
on
on
iOS
ios
or
or
Android.
android
The
the
problem
problem
is
is
that
that
because
because
the
the
initial
initial
HTML
html
is
is
just
just
a
a
shell,
shell
search
search
engines
engines
may
may
have
have
a
a
hard
hard
time
time
understanding
understanding
and
and
indexing
indexing
it.
it
If
if
you
you
take
take
a
a
link
link
generated
generated
by
by
JavaScript
javascript
from
from
a
a
single
single
page
page
application
application
and
and
post
post
it
it
into
into
Twitter,
twitter
you'll
you'll
only
only
see
see
the
the
initial
initial
shell.
shell
You
you
won't
won't
see
see
any
any
additional
additional
meta
meta
tags
tags
that
that
were
were
generated
generated
by
by
Java
java
script
script
after
after
the
the
fact.
fact
That's
that's
not
not
great
great
for
for
social
social
media,
media
but
but
Google,
google
as
as
a
a
search
search
engine,
engine
is
is
able
able
to
to
index
index
client
client
rendered
rendered
apps.
apps
But
but
the
the
reliability
reliability
is
is
questionable.
questionable
And
and
personally,
personally
I
i
wouldn't
wouldn't
trust
trust
client
client
rendering
rendering
if
if
SEO
seo
was
was
a
a
business
business
critical
critical
requirement.
requirement
So
so
another
another
option
option
is
is
to
to
pre
pre
render
render
or
or
statically
statically
generate
generate
HTML
html
in
in
advance.
advance
Let's
let's
imagine
imagine
your
your
web
web
app
app
has
has
a
a
100
100
different
different
routes
routes
or
or
pages.
pages
Instead
instead
of
of
sending
sending
a
a
shell
shell
down
down
to
to
the
the
user,
user
we
we
could
could
generate
generate
all
all
the
the
HTML
html
for
for
those
those
pages
pages
in
in
advance,
advance
then
then
upload
upload
the
the
static
static
files
files
to
to
a
a
storage
storage
bucket
bucket
that
that
could
could
be
be
cached
cached
on
on
a
a
global
global
CDN.
cdn
So
so
the
the
first
first
thing
thing
the
the
user
user
sees
sees
is
is
fully
fully
rendered
rendered
content,
content
then
then
the
the
JavaScript
javascript
loads
loads
after
after
that
that
and
and
makes
makes
the
the
page
page
fully
fully
interactive.
interactive
That's
that's
great
great
for
for
SEO
seo
because
because
bots
bots
get
get
fully
fully
rendered
rendered
HTML,
html
and
and
they
they
can
can
easily
easily
interpret
interpret
the
the
content
content
on
on
the
the
page.
page
It's
it's
also
also
highly
highly
efficient
efficient
because
because
if
if
you're
you're
fetching
fetching
data
data
from
from
a
a
database,
database
you
you
only
only
have
have
to
to
do
do
that
that
once
once
at
at
build
build
time,
time
then
then
you
you
can
can
cache
cache
the
the
page
page
on
on
a
a
CDN
cdn
and
and
serve
serve
it
it
to
to
millions
millions
of
of
people
people
without
without
having
having
to
to
re
re
fetch
fetch
your
your
data.
data
The
the
trade
trade
off
off
with
with
this
this
approach
approach
though
though
is
is
that
that
the
the
data
data
in
in
the
the
pre
pre
rendered
rendered
content
content
can
can
become
become
stale,
stale
which
which
means
means
bots
bots
will
will
be
be
getting
getting
outdated
outdated
information
information
until
until
you
you
rebuild
rebuild
and
and
redeploy
redeploy
the
the
entire
entire
site.
site
That's
that's
no
no
big
big
deal
deal
if
if
you
you
have
have
a
a
few
few
100
100
pages
pages
that
that
don't
don't
change
change
very
very
often,
often
but
but
if
if
you
you
have
have
millions
millions
of
of
pages
pages
with
with
highly
highly
dynamic
dynamic
data,
data
then
then
it
it
doesn't
doesn't
really
really
scale.
scale
And
and
that
that
brings
brings
us
us
to
to
option
option
number
number
3,
3
server
server
side
side
rendering.
rendering
In
in
this
this
paradigm,
paradigm
when
when
the
the
user
user
makes
makes
a
a
request
request
to
to
a
a
page,
page
the
the
HTML
html
is
is
generated
generated
on
on
the
the
server.
server
This
this
is
is
also
also
great
great
for
for
SEO
seo
because
because
bots
bots
get
get
fully
fully
rendered
rendered
HTML
html
on
on
the
the
initial
initial
request.
request
In
in
addition,
addition
the
the
data
data
will
will
always
always
be
be
fresh
fresh
because
because
you're
you're
making
making
a
a
new
new
request
request
to
to
the
the
server
server
each
each
time.
time
But
but
the
the
drawback
drawback
here
here
is
is
that
that
it's
it's
generally
generally
less
less
efficient.
efficient
You
you
might
might
be
be
fetching
fetching
and
and
rendering
rendering
the
the
same
same
HTML
html
over
over
and
and
over
over
again.
again
It
it
is
is
possible
possible
to
to
do
do
server
server
side
side
caching,
caching
but
but
that's
that's
not
not
as
as
efficient
efficient
as
as
edge
edge
caching
caching
on
on
a
a
CDN
cdn
and
and
will
will
cost
cost
a
a
lot
lot
more
more
to
to
operate
operate
at
at
scale.
scale
And
and
if
if
things
things
aren't
aren't
cached
cached
efficiently,
efficiently
that
that
means
means
a
a
slower
slower
first
first
time
time
to
to
meaningful
meaningful
content,
content
which
which
can
can
negatively
negatively
impact
impact
SEO.
seo
So,
so
basically,
basically
between
between
these
these
three
three
methods,
methods
we
we
have
have
a
a
trade
trade
off
off
between
between
data
data
freshness,
freshness
performance,
performance
and
and
client
client
side
side
interactivity.
interactivity
But
but
what
what
if
if
there
there
is
is
a
a
way
way
we
we
could
could
have
have
our
our
cake
cake
and
and
eat
eat
it
it
too?
too
Allow
allow
me
me
to
to
introduce
introduce
you
you
to
to
incremental
incremental
static
static
regeneration.
regeneration
This
this
is
is
the
the
way.
way
This
this
is
is
the
the
way.
way
This
this
is
is
the
the
way.
way
This
this
is
is
a
a
new
new
form
form
of
of
rendering
rendering
available
available
in
in
the
the
Next
next
JS
js
framework.
framework
Remember
remember
earlier,
earlier
I
i
said
said
the
the
drawback
drawback
with
with
static
static
pages
pages
is
is
that
that
the
the
data
data
may
may
become
become
stale
stale
and
and
require
require
a
a
redeploy
redeploy
of
of
your
your
site.
site
What
what
ISR
isr
does
does
is
is
allow
allow
you
you
to
to
statically
statically
generate
generate
your
your
pages,
pages
then
then
rebuild
rebuild
and
and
redeploy
redeploy
them
them
on
on
the
the
fly
fly
in
in
the
the
background
background
as
as
new
new
requests
requests
come
come
into
into
your
your
site.
site
That
that
means
means
you
you
get
get
all
all
the
the
performance
performance
benefits
benefits
of
of
static
static
pages
pages
while
while
ensuring
ensuring
that
that
these
these
pages
pages
always
always
contain
contain
fresh
fresh
data.
data
That
that
eliminates
eliminates
all
all
of
of
the
the
trade
trade
offs
offs
that
that
we've
we've
talked
talked
about,
about
but
but
it's
it's
not
not
without
without
a
a
cost.
cost
Deploying
deploying
a
a
static
static
site
site
is
is
as
as
easy
easy
as
as
uploading
uploading
your
your
files
files
to
to
a
a
storage
storage
bucket,
bucket
but
but
incremental
incremental
static
static
regeneration
regeneration
would
would
require
require
a
a
more
more
complex
complex
back
back
end
end
server
server
deployment.
deployment
For
for
most
most
of
of
us,
us
that
that
means
means
paying
paying
for
for
a
a
host
host
that
that
supports
supports
it
it
like
like
Vercel.
vercel
But
but
hosting
hosting
anywhere
anywhere
else
else
will
will
likely
likely
be
be
much
much
more
more
painful
painful
until
until
more
more
companies
companies
start
start
adopting
adopting
these
these
techniques.
techniques
Now
now
one
one
very
very
cool
cool
thing
thing
going
going
on
on
in
in
the
the
web
web
development
development
world
world
right
right
now
now
is
is
that
that
more
more
frameworks
frameworks
like
like
Next
next
and
and
Angular
angular
are
are
supporting
supporting
hybrid
hybrid
rendering.
rendering
That
that
means
means
you
you
can
can
implement
implement
some
some
routes
routes
as
as
static
static
pages,
pages
configure
configure
other
other
routes
routes
to
to
use
use
full
full
server
server
side
side
rendering,
rendering
while
while
other
other
routes
routes
can
can
be
be
fully
fully
client
client
rendered.
rendered
So
so
you're
you're
not
not
pigeonholed
pigeonholed
into
into
just
just
one
one
rendering
rendering
technique.
technique
You
you
can
can
pick
pick
and
and
choose
choose
what
what
works
works
best
best
for
for
a
a
given
given
page.
page
And
and
in
in
my
my
opinion,
opinion
that's
that's
the
the
future
future
of
of
full
full
stack
stack
web
web
development.
development
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
If
if
you
you
want
want
to
to
learn
learn
how
how
to
to
implement
implement
a
a
real
real
hybrid
hybrid
rendered
rendered
application
application
with
with
Next
next
JS,
js
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip
fireship
bio.
bio
You'll
you'll
get
get
access
access
to
to
the
the
next
next
course
course
along
along
with
with
a
a
whole
whole
bunch
bunch
of
of
other
other
pro
pro
content.
content
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
see
see
you
you
in
in
the
the
next
next
one.
one
success
The importance of creating great content and ensuring SEO is timely is emphasized, along with the use of metadata to improve SEO and outbound links. A course on building a fully rendered HTML page and a course on building a fully rendered HTML page are recommended, and outbound links and metadata are also discussed. Consent is given to dynamic rendering websites and a pro member community is encouraged for more pro content. Different options for rendering HTML are discussed, including incremental static regeneration, and the benefits of this method are emphasized.
SEO for Developers in 100 Seconds
The first rule of search engine optimization is create really good content. The second rule of search engine optimization is create really good content. If human beings don't want to engage with your content, then Google doesn't want to either. We live in the age of machine learning and quantum computing. You can't just stuff a bunch of keywords into a page and expect to do well. When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had. People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank. Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts. The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats. But some say it's a dying industry. 3. Don't wanna see a dead body. Because it's becoming harder and harder to manipulate Google's technology. There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site. Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content. Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots. Your main content goes inside the body tags. When Google crawls your site, it will use semantic HTML elements to understand the content on the page. You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about. Furthermore, your HTML should be accessible. Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices. In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing. The 4th rule of SEO is to get your fully rendered HTML loaded fast. If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site. But going fast is easier said than done. That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization. If you're new here, like and subscribe. And today, I have a big announcement. My full Next JS Firebase course is now available. If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course. Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly. The first two rules are very subjective and depend entirely on your audience. But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible. There are a few metrics that you'll wanna be aware of here. The first one is the click through rate or CTR. That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP. The higher the CTR, the better, and that usually means you have a very relevant title and description. Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce. And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant. If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results. The longer the dwell time, the better. But the best possible thing that can happen is that the user never clicks back. Their session will last forever, and they'll never need to go to another website ever again. That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session. These are metrics that you want to maximize. There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more. If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good. Let's move on to rule 3 where we talk about the actual structure of the HTML. I'll be using my site, FireShip I o, as an example. On a lesson or article page, you can right click and hit inspect element or hit control shift I. This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup. We have a head and a body. Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article. An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page. In addition, you'll notice a couple of extra attributes here. 1 is item scope and the other is an item type as a schema dot org article. Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret. It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page. Now, in this case, we have a bunch of metadata that make up an article. And one thing that is known to improve search ranking is when an article is written by a known author. Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page. That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author. Outbound links on a page are really important because they further signal what the page is about. In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is. A good strategy is to use outbound links to other really good sites that are related to the content on a given page. Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility. One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image. This metadata can be used by search engines and also by screen readers for those with disabilities. For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page. At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO. Most importantly, this is where you have the title. You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating. In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that. These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook. When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there. If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags. So that gives you some things to think about when it comes to the actual structure of your HTML. But the bigger question is how do you render that HTML? Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user. There are 3 fundamental ways to render HTML. The first one we'll look at is client side rendering. If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application. On the initial page load, the user gets a shell of HTML without any meaningful content. The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI. Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android. The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it. If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell. You won't see any additional meta tags that were generated by Java script after the fact. That's not great for social media, but Google, as a search engine, is able to index client rendered apps. But the reliability is questionable. And personally, I wouldn't trust client rendering if SEO was a business critical requirement. So another option is to pre render or statically generate HTML in advance. Let's imagine your web app has a 100 different routes or pages. Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN. So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive. That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page. It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data. The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site. That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale. And that brings us to option number 3, server side rendering. In this paradigm, when the user makes a request to a page, the HTML is generated on the server. This is also great for SEO because bots get fully rendered HTML on the initial request. In addition, the data will always be fresh because you're making a new request to the server each time. But the drawback here is that it's generally less efficient. You might be fetching and rendering the same HTML over and over again. It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale. And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO. So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity. But what if there is a way we could have our cake and eat it too? Allow me to introduce you to incremental static regeneration. This is the way. This is the way. This is the way. This is a new form of rendering available in the Next JS framework. Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site. What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site. That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data. That eliminates all of the trade offs that we've talked about, but it's not without a cost. Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment. For most of us, that means paying for a host that supports it like Vercel. But hosting anywhere else will likely be much more painful until more companies start adopting these techniques. Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering. That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered. So you're not pigeonholed into just one rendering technique. You can pick and choose what works best for a given page. And in my opinion, that's the future of full stack web development. I'm gonna go ahead and wrap things up there. If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio. You'll get access to the next course along with a whole bunch of other pro content. Thanks for watching, and I will see you in the next one.
The importance of creating great content and ensuring SEO is timely is emphasized, along with the use of metadata to improve SEO and outbound links. A course on building a fully rendered HTML page and a course on building a fully rendered HTML page are recommended, and outbound links and metadata are also discussed. Consent is given to dynamic rendering websites and a pro member community is encouraged for more pro content. Different options for rendering HTML are discussed, including incremental static regeneration, and the benefits of this method are emphasized.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : SEO for Developers in 100 Seconds 
        and a small summary : The importance of creating great content and ensuring SEO is timely is emphasized, along with the use of metadata to improve SEO and outbound links. A course on building a fully rendered HTML page and a course on building a fully rendered HTML page are recommended, and outbound links and metadata are also discussed. Consent is given to dynamic rendering websites and a pro member community is encouraged for more pro content. Different options for rendering HTML are discussed, including incremental static regeneration, and the benefits of this method are emphasized.
        [/INST]
        
        Generate the video : The first rule of search engine optimization is create really good content. The second rule of search engine optimization is create really good content. If human beings don't want to engage with your content, then Google doesn't want to either. We live in the age of machine learning and quantum computing. You can't just stuff a bunch of keywords into a page and expect to do well. When Google first came about in the late nineties, it was based on an algorithm called PageRank, which weighted relevance and search ranking based on the number of inbound links that a site had. People quickly learned how to exploit the algorithm by spamming backlinks all over the Internet to increase a site's page rank. Because a high ranking in Google can literally be worth 1,000,000 of dollars, it brought us an entire industry of SEO experts. The good guys wear white hats, the hackers wear black hats, but the most effective ones wear gray hats. But some say it's a dying industry. 3. Don't wanna see a dead body. Because it's becoming harder and harder to manipulate Google's technology. There are over 200 factors that go into a site's ranking that are geared mostly towards how useful a user found your site. Did they immediately bounce by clicking the back button, or did they dwell on the page for a long time and click other links, absorbing all kinds of useful content. Content is king, but the third rule of SEO is to render HTML that can be reliably stood by bots. Your main content goes inside the body tags. When Google crawls your site, it will use semantic HTML elements to understand the content on the page. You might put your main content in an article tag, then put your most important keywords and headings or h tags to signal what your page is about. Furthermore, your HTML should be accessible. Use alt tags and images and ARIA tags where needed to make your site usable on assistive devices. In the head of the document, we have metadata that's not directly shown to the end user, but bots can use this data to further understand the page and format the actual appearance of your search engine listing. The 4th rule of SEO is to get your fully rendered HTML loaded fast. If you have megabytes of blocking images, styles, and JavaScript, both users and bots will pass on your site. But going fast is easier said than done. That's why today, we're going beyond 100 seconds to look at the many different strategies we have to render HTML and how they impact search engine optimization. If you're new here, like and subscribe. And today, I have a big announcement. My full Next JS Firebase course is now available. If your goal is to build a highly interactive web app that is also fully search engine friendly, then you'll definitely want to check out this course. Now the 4 most important rules for SEO, in my opinion, are create awesome content, create awesome content, render properly formatted HTML, and load your HTML quickly. The first two rules are very subjective and depend entirely on your audience. But the general goal is that when someone clicks on a link to your site from a search engine ranking page, they should engage with your site as long as possible. There are a few metrics that you'll wanna be aware of here. The first one is the click through rate or CTR. That defines how likely a user is to click on your link when displayed in a search engine ranking page or SERP. The higher the CTR, the better, and that usually means you have a very relevant title and description. Now if a user clicks on your link and then immediately clicks the back button, that's called a bounce. And the higher your bounce rate is, the less likely your site is to rank well in the long term because, apparently, the content on the page is not very relevant. If the user does stay on the page, Google will keep track of the dwell time, which is the amount of time they spend there before clicking back to the search results. The longer the dwell time, the better. But the best possible thing that can happen is that the user never clicks back. Their session will last forever, and they'll never need to go to another website ever again. That doesn't happen very often, so what you keep track of is the average session duration and the average number of pages viewed per session. These are metrics that you want to maximize. There's no absolute rule for creating engaging content, but the first thing the user sees should hook them in to want to read more. If you look at something like BuzzFeed, all all you have to do is put an animated GIF at the top, then maybe a few more in the body, and you should be good. Let's move on to rule 3 where we talk about the actual structure of the HTML. I'll be using my site, FireShip I o, as an example. On a lesson or article page, you can right click and hit inspect element or hit control shift I. This will bring up the elements tab in Chrome Dev Tools showing you the fully rendered HTML markup. We have a head and a body. Let's go ahead and open up the body, find the main element, then inside the main element, you'll notice we have an article. An article element has semantic meaning, and although it will never be seen by the end user, it tells the search engine, here is the main content of the page. In addition, you'll notice a couple of extra attributes here. 1 is item scope and the other is an item type as a schema dot org article. Now it's totally optional and whether or not it will improve your search engine ranking is debatable, but what schema.org allows you to do is define a bunch of metadata about the actual content on your page, making it easier for search engines to interpret. It's especially powerful if your content is something like a recipe or a star review because Google can then take the schema data and format it properly in a SERP page. Now, in this case, we have a bunch of metadata that make up an article. And one thing that is known to improve search ranking is when an article is written by a known author. Further down the HTML tree here, you'll notice we have an item prop of author which points to the author's page. That link goes to another page on Fireship IO, and on that page, we also have an article element, this time with an item type of a schema.org author, along with a bunch of links that point to authoritative sites for that author. Outbound links on a page are really important because they further signal what the page is about. In this case, Google will first crawl the article, then crawl the author's page, then crawl these other sites to understand who that author is. A good strategy is to use outbound links to other really good sites that are related to the content on a given page. Now in addition to schema.org, there's other ways you can add metadata to your content, and this can be very important for SEO and also accessibility. One of the most fundamental techniques is to add an alt attribute to images, which is basically just some text that describes the image. This metadata can be used by search engines and also by screen readers for those with disabilities. For other elements that are a little more complicated, like a progress bar, for example, you can use ARIA attributes, which stand for accessible rich Internet applications, and they help provide additional meaning to highly interactive widgets on the page. At this point, we've only been looking in the body of the document, but the head of the document contains all kinds of useful metadata for SEO. Most importantly, this is where you have the title. You should choose your title carefully because it's displayed in a SERP page and will ultimately control your CTR rating. In addition to the title, you you may also wanna have meta tags here, which define things like the description, featured image, author, canonical URL, and stuff like that. These meta tags are also essential if you want your content to be shared on social media sites like Twitter or Facebook. When you post a hyperlink in social media, it fetches that page and looks for the meta tags to understand what image and title to display there. If you wanna see how your site's doing right now, you can post a link into the Twitter card validator, and it will tell you whether or not it can use your current meta tags. So that gives you some things to think about when it comes to the actual structure of your HTML. But the bigger question is how do you render that HTML? Or in other words, what part of your tech stack is responsible for generating the actual HTML markup it is received by a bot or end user. There are 3 fundamental ways to render HTML. The first one we'll look at is client side rendering. If you're building an app with something like React or Angular, the default mode is client side rendering or a single page application. On the initial page load, the user gets a shell of HTML without any meaningful content. The JavaScript code then bootstraps, then asynchronously fetches any additional data needed for the UI. Apps like this are great for interactivity because it gives the end user an app like feel similar to what you'd expect on iOS or Android. The problem is that because the initial HTML is just a shell, search engines may have a hard time understanding and indexing it. If you take a link generated by JavaScript from a single page application and post it into Twitter, you'll only see the initial shell. You won't see any additional meta tags that were generated by Java script after the fact. That's not great for social media, but Google, as a search engine, is able to index client rendered apps. But the reliability is questionable. And personally, I wouldn't trust client rendering if SEO was a business critical requirement. So another option is to pre render or statically generate HTML in advance. Let's imagine your web app has a 100 different routes or pages. Instead of sending a shell down to the user, we could generate all the HTML for those pages in advance, then upload the static files to a storage bucket that could be cached on a global CDN. So the first thing the user sees is fully rendered content, then the JavaScript loads after that and makes the page fully interactive. That's great for SEO because bots get fully rendered HTML, and they can easily interpret the content on the page. It's also highly efficient because if you're fetching data from a database, you only have to do that once at build time, then you can cache the page on a CDN and serve it to millions of people without having to re fetch your data. The trade off with this approach though is that the data in the pre rendered content can become stale, which means bots will be getting outdated information until you rebuild and redeploy the entire site. That's no big deal if you have a few 100 pages that don't change very often, but if you have millions of pages with highly dynamic data, then it doesn't really scale. And that brings us to option number 3, server side rendering. In this paradigm, when the user makes a request to a page, the HTML is generated on the server. This is also great for SEO because bots get fully rendered HTML on the initial request. In addition, the data will always be fresh because you're making a new request to the server each time. But the drawback here is that it's generally less efficient. You might be fetching and rendering the same HTML over and over again. It is possible to do server side caching, but that's not as efficient as edge caching on a CDN and will cost a lot more to operate at scale. And if things aren't cached efficiently, that means a slower first time to meaningful content, which can negatively impact SEO. So, basically, between these three methods, we have a trade off between data freshness, performance, and client side interactivity. But what if there is a way we could have our cake and eat it too? Allow me to introduce you to incremental static regeneration. This is the way. This is the way. This is the way. This is a new form of rendering available in the Next JS framework. Remember earlier, I said the drawback with static pages is that the data may become stale and require a redeploy of your site. What ISR does is allow you to statically generate your pages, then rebuild and redeploy them on the fly in the background as new requests come into your site. That means you get all the performance benefits of static pages while ensuring that these pages always contain fresh data. That eliminates all of the trade offs that we've talked about, but it's not without a cost. Deploying a static site is as easy as uploading your files to a storage bucket, but incremental static regeneration would require a more complex back end server deployment. For most of us, that means paying for a host that supports it like Vercel. But hosting anywhere else will likely be much more painful until more companies start adopting these techniques. Now one very cool thing going on in the web development world right now is that more frameworks like Next and Angular are supporting hybrid rendering. That means you can implement some routes as static pages, configure other routes to use full server side rendering, while other routes can be fully client rendered. So you're not pigeonholed into just one rendering technique. You can pick and choose what works best for a given page. And in my opinion, that's the future of full stack web development. I'm gonna go ahead and wrap things up there. If you want to learn how to implement a real hybrid rendered application with Next JS, consider becoming a pro member at FireShip bio. You'll get access to the next course along with a whole bunch of other pro content. Thanks for watching, and I will see you in the next one.
        