Webpage Calling Card
You type in a URL and press enter. A webpage loads, and you begin to read. You experience the text provided by the website creator as well as images, all organized (usually) by the site’s CSS file(s). This is all you are going to see, but it’s the bulk of the webpage, and the most important part.
There’s obviously more to a webpage than just that, though. Search engines, social media, apps like Discord, browsers, and other websites, when sniffing your pages, often look in a different place for information about your site. They’ll specifically, and first, check the <head> part of your HTML document for (amongst other things) meta tags.
These will determine things like the site’s title and description when linked in various places, summaries shown by search engines and previews in apps, etc. All of this, put together, produce a nice little calling card of sorts. I believe this makes your site more presentable as a whole. Plus, certain tags provide valuable information to the user as part of the preview and more, of course.
This page covers what bits I’ve picked up over the years about creating and implementing meta tags. It should not by any means be considered comprehensive. While I’d consider myself relatively fluent in HTML, that’s mostly below the <body> tag, not the <head>, and there’s plenty I still need to learn.
At the end, I’ll talk a bit about favicons, another interesting, optional site feature. These are a little different than the meta tags, but help with the calling card aspect of the site, I think, so I included them here.
Note: All of the HTML mentioned in here would go between the <head> and </head> tags in your webpages. I think it’s advantageous to label all of these various parts within the header with comments in the HTML, but that’s just me - I include those in these snippets, but they’re optional.
What's a meta tag?
Meta tags are a way of inserting metadata into an HTML document. They predate Mark Zuckerberg renaming Facebook to Meta and predate many people, as well. “Meta,” you see, is merely a Greek root word that means “beyond,” roughly. This is why “metaphysics” refers to studying that which exists beyond physics. I don’t recommend studying that, though, at least not formally.
Uhm, anyways, metadata means data about data on top of the existing data. It provides information about its creation and stipulations about how it is to be processed and used. For HTML documents like webpages, this was once much more important, but can still be useful. A lot of them can get weirdly specific or specialized, and some are likely to be the same for most pages regardless - I’m still learning all about that, and won’t address what I don’t know, naturally. Thankfully, the general meta tags are easy to customize.
The HTML itself for this is below. You are going to want to edit the first four meta tags in this, each portion beginning with “INSERT…” of course.
Add your page title and your description. Your page title should be the same as the, well, title of the page in question, not necessarily your site title. If you’ve got a page about your favorite dragons, title it My Site: Favorite Dragons or something. The title (and description) should be reasonably unique for every page on your site if at all possible. This tells search engines, social media, and places like Discord exactly what each page is about rather than just cluing them into the site as a whole.
There is also the, uhhh, option of adding keywords. This is sort of a cute formality to me nowadays, . Back in the Before Times (ie, the early 2000s) we would often stuff this part with tons of words. I saw a list of porn-related terms in the source code of a friend’s site after she asked me to look at another part of it. She explained that, while her site wasn’t porn, obviously, inserting the terms would (she thought) boost its search engine rankings. This doesn’t work in today’s world, and arguably never did.
Sometimes, people would hide inside jokes here, too.
Plus, now, search engines seem to barely notice things like keywords in the <head> and tend to focus more on a site’s actual content below the <body> tag. But still… you can go ahead and list what your site is about in keyword form - just don’t stuff the tag with the dictionary or anything…
As always, you can see I’ve included an HTML comment noting that the calling card and meta tags begin here, to help with legibility and future editing of the code itself. Since the description, title, and perhaps even keywords should be unique to most pages on your site (describing them in particular), you will need to find this again and again in source code.
If you’re curious about the two remaining meta tags at the end there (“robots” and ”revisit-after”), these tell search engines and other robots that crawl the web how to behave on the page. In the above case, they instruct these creatures to index the page and follow links within it to other pages, and also to frequently reindex it.
If you wanted to, you could set it as follows, instead:
This would discourage search engines (and other bots) from indexing or visiting your site. Note that word, though - discourage. Not prevent. In other words, you could use that line of HTML code in the <head> of your document to politely ask bots to avoid your page - it’d be up to the robots to actually respect your request.
Do you really think they (and their corporate overlords) comply at this point? Try anyways, if you want...
Open Graph Images
Is this as awful as the word implies? For some reason, it sends little sparks of nervousness, the kind only afforded by deeply corporate intrusion, through me. Actually, it does have a bit of an evil origin story, having originally been the work of Facebook in its heyday. Still, the tenacity and spread of the feature proves its usefulness…
It defines the aspects of the calling card that are going to appear on social media if you past the link there, or, for example, on Discord. I think. We are in an era where, like it or not, social media reigns. Those little banners are important replacements for the dull default site previews one would see otherwise.
Please note: many websites do include customized Twitter tags in addition to the normal Open Graph tags I’ll be discussing here. If you’re really interested in setting up those, there are resources for them elsewhere. With just the normal Open Graph tags, though, your site will display as a link rather fluently on Twitter, so I wouldn’t worry. This is especially true since Twitter’s a carnival of nonsense lately.
The image itself should ideally be about 1200 pixels wide and 630 pixels tall. Making it smaller might cause pixelation on some platforms. Making it larger might increase file size a bit too much, depending on how detailed the image will be.
As to file formats, it depends - I use a JPG image on my other site, which features a rich, flowery Open Graph image with scanned ephemera. Here, where the image is simple lines, text, and some squares, I use PNG. I think that works well.
You have many options for making or choosing an Open Graph image. Make your own using free resources in Photoshop, GIMP, Procreate, or any other image editing program you’d like. You really shouldn’t just download a generic sizable image and upload it as your Open Graph, though - you’ll at least want it to have your site title, and, ideally, tagline and URL.
As you might expect, I used Canva to create mine, because I use Canva for most things. I cannot take much credit for things like the delicate roses on the Open Graph image for my (other) website, for example. They’re Canva-provided clipart, and I remixed them a bit. I see nothing wrong with this, given that it’s precisely the point of Canva, other programs like it, and premade linkware resources, too.
Gasp! Must the image be the same throughout…?
No, of course not! As you’ve likely noticed on most social media, websites often have a different Open Graph image displayed for every article or page. This is possible if you want to alter the URL for the Open Graph images on each page, uploading a new one for each. You could also consider linking to an existing image from the page (if large enough) as the Open Graph image.
For my sites, I’ve kept things simple and used the same Open Graph image throughout, just a general splash of my site title and tagline in image form. This works well for highly-focused sites. You can make your own decision here - is a custom Open Graph image for each page or section on your site worth the extra effort? Will it help convey your particular message better? If so, do it! If not, I would stick to one.
The text description and page title, of course, change depending on which page of your site you’re working on. They simply must, because they tell the browser (and other websites) about the specific page’s contents. Each page needs a unique description, title, and such, even if you do leave the Open Graph image itself the same throughout.
Anyways, here’s the HTML. To get started, add your information where it says insert here. I recommend labeling this code snippet, as always, with a comment in the HTML, as seen below.
Be mindful that the Open Graph image link address must be the full URL - it cannot be a relative path. In other words, if your Open Graph image is called meta.png and located in a folder called image, you mustn’t type /image/meta.png.
Instead, you’d need the full URL - https://yoursiteurl.whatever/image/meta.png. If you do not use the full URL, it will not work. Open Graph images are accessed by the other sites loading the preview, not yours - they need the exact location.
Favicons
Way back in 1999, Microsoft Internet Explorer (they are to blame, yes) introduced the concept of favicons. These were, at the time, supposed to just be small images representative of a website in the visitor’s bookmarks folder, provided by the website itself.
Many other browsers ended up adopting, and expanding upon this concept. Now, Microsoft Internet Explorer is (mostly) a thing of the past, but almost every popular site will have a favicon appearing in the corner of the browser window when you view it.
This site’s favicon, visible in the expected place, features a yellow-and-orange sun with the site’s initial, F, inlayed. It’s a rounded, transparent square. Depending on your settings, browser, and operating system, you may not be able to see it. Most visitors will, though.
Why even have a favicon? They certainly make your site look more finished, more complete, and more detailed. They’ve been a fixture of the web for some time. They can be helpful for some users who have zillions of tabs open at once. In short, yes, it isn’t strictly necessary, but why not? Most sites have them nowadays. Give them a try.
You needn’t make a brand new favicon image from scratch, really. If you’ve any square user profile pictures (fitting the aesthetic), you can work with those. Failing that, you can use clipart or other premade resources, provided you’re not stepping into any unpleasant areas with copyright.
I used Canva to make this site’s favicon in raw image form, and the sun image is a petit piece of clipart provided by the program. There’s also the option of using a screen grab of your favorite anime character, I suppose - it isn’t as if Gainax is keen on suing small sites, anyways…
Regardless of where you get your favicon image, you’ll be processing it a bit before you upload it to your site. Beforehand, make sure it’s of a decent size. While your (processed) favicon images will end up rather small, it’s best to begin with an image of at least 250 pixels squared.
I used RedKetchup’s (actually quite formidable) free favicon generator to turn my image into a favicon. It has options to round your image’s corners, turn it into a circle, or even create one from scratch with text. While most free resources online are clickbait, this one isn’t so bad.
Once you’ve fiddled with it a bit, you can click to generate your favicon in various sizes, which will be downloaded (along with your site.webmanifest file, which will control a bit of how your favicon appears on mobile. I’ll admit an abject lack of understanding of the latter. That said, RedKetchup handles manifesting this manifest quite easily.
After generating them, they’ll download as a zip file from RedKetchup; unzip this, and upload all the files within it into your root directory (I’d recommend). If you’re not putting them in your root directory, make sure to change the paths in the HTML below to point to the proper location of the favicons.
You’ll be adding a few lines to the <head> portion of your document, pointing to the files you’ve just uploaded. It’s advantageous to label with a short line of comment (just noting that the favicons section begins) to make finding it within the head of your various documents easier.
Ideally, as noted, you’ve uploaded them to the root directory, so your code would look something like below. If you’ve uploaded somewhere else, you’ll have to change the URLs, of course. Unlike Open Graph images, you do not have to use the full URL for the favicon images, but can rather use a path, like below. I still recommend uploading them to the root directory like so…
Resist the temptation to use an animated favicon. And yes, it’s possible to do that.
It may seem like a perfect way to draw repeated attention to your site within a user’s browser on desktop. Really, a lot of people find it annoying, especially if the animation is particularly flashy or attention-getting to begin with.
I suppose a slow, gradient effect might be interesting (I haven’t tried it). Be mindful that your visitors are on your site to read your content, not to deal with the distraction of a flashing favicon.