Most people tweet out when they stream. It's a good way to inform people they're going live and a good way to bring in viewers that may not be following yet. RTs and likes can boost visibility of a stream, and Twitter includes this neatly formatted Twitter card when you include your Twitch link, so your stream details and Twitch avatar pop onto the timeline. It's a win/win.

However, Twitch's Twitter card has several issues. The primary one is that you have very limited control over what's displayed. In addition to this, the data on the card can frequently be outdated due to how Twitter pulls in card data. I know I personally stopped linking my Twitch page in my go-live announcements because I didn't like these shortcomings. Eventually I sat down and sussed out an alternate solution.

This write-up will guide you on how to set up a replacement for Twitch's Twitter cards, hosted on your own web space, so that your go-live announcements will contain the data you want, as well as discuss some additional benefits to hosting your own Twitter card for traffic analysis to your stream.

Background Info: Anatomy of a Twitter Card

A Twitter card is a special block of data within a web page that instructs Twitter on assembling a summary of the page along side a tweet linking to that page. If someone tweets a link to a specific page, Twitter will grab that page and check if this block of data exists. If so, it'll pull out the data therein and construct a Twitter Card. Practically every major page in your Twitch profile (your stream page, VOD pages, clip pages, etc) has a Twitter Card data block. Some of these blocks instruct Twitter to embed video within Twitter timelines, some just include a formatted block containing your Twitch account name and avatar.

The Twitter Card that appears when you link your main Twitch profile looks like this:

And for curiosity sake, here's the block of HTML that generates it:

            <meta property='og:site_name' content='Twitch'>
            <meta property='twitter:site' content='@twitch'>
            <meta property='og:title' content='Trysdyn - Twitch'>
            <meta property='og:url' content=''>
            <meta property='og:description' content='Kusogrand3 Race: Watch this crapsack at Brossentia's channel'>
            <meta property='og:type' content='video.other'>
            <meta property='og:image' content=''>
            <meta property='og:video' content=''>
            <meta property='og:video:secure_url' content=''>
            <meta property='og:width' content='620'>
            <meta property='og:height' content='378'>
            <meta property='og:video:type' content='text/html'>
            <meta name='twitter:card' content='summary'>
            <meta name='twitter:image' content=''>

The format for this card is rather simplistic: it will always contain your account name, avatar, and stream title. Clicking it will take you to the stream. Simple, yeah? However, there's two major problems with this.

  1. You have no control over this data. If you want to embed more here, such as a blurb about your stream or who you are, you just can't.
  2. Twitter only refreshes cards every 7 days. As a result, if you stream more than once a week, your stream title within your card will be wrong most of the time.

You can work around problem #2 by adding garbage to the end of your URL as a GET parameter. In layman's terms, you can tweet your Twitch link as, for example, one stream, then the next. Twitter will see these as different URLs and refresh the card instantly, while both will take you to your stream when clicked. Twitter actually recommends this as the official way to force more frequent updates to your Twitter Card than weekly.

What if you want more control though? Well, that's where my solution comes in.

How This Works and What We Need

We're going to host our own web page, generating our own Twitter Card. This page, when visited, will automatically redirect human-operated web browsers to your stream while only serving the Twitter Card data to robots (Twitter, Facebook, etc). This guide is going to be written under the assumption that you have limited access to your web host, so it will not require tweaking your server configs or anything. As such we're going to assume you have...

  1. A place to throw a static HTML web page. This can be a web server you run, a free web host, or Github Pages
  2. A Twitter account, as the Twitter Card API requires a Twitter account to "own" the card data
  3. A streaming account of some kind. I'm going to assume Twitch, but this works with Youtube,, Mixer, whatever
  4. The know-how to get documents onto your chosen web host. Depending on who you are using to host the page, getting data onto that server can vary wildly, so I can't step-by-step guide you there
  5. Optionally: ownership of a domain name to point at the web page. You can just use whatever URL your web server throws out as a default, but having a short pithy domain name can make your stream URL more memorable

Once you have this scratched together, we can get started.

First Decision: Figure Out Your Site's URL -- Sub-path or Not?

The first thing you need to decide is if you're going to point your entire domain/address at your stream, or if you're going to fork off a sub-path. For example, I own the domain but I host other things on there too, so I made the path throw up the Twitter Card and redirect to my stream. Some people buy a domain specifically for their stream (for example: protomagicalgirl and the domain; some people do what I do.

If you want to dedicate your entire domain to this purpose, simply create a file named "index.html" within your web server directory. We will add the Twitter Card and redirection data to this soon. If you're going to create a sub-path for this, make a directory with the same name as the path you want, and create your index.html file there. For example, since I want to use, I created a directory named "stream", and put index.html in there. If you want to test that this is working, put something silly in the file like "Hello World!" and then visit the URL you wish to use for the Card in your web browser. The document should appear exactly as you wrote it.

Once you're able to pull the document down in your browser we can move on.

Step Two: Adding Your Twitter and Twitch Data

Hopefully you have an idea of what you want your Twitter Card to look like. We're going to add that now. Open your index.html file back up, delete whatever text you put in there for testing and add this instead:

            <meta http-equiv="refresh" content="0;url=" />

            <!-- Twitter Card specific fields -->
            <meta name='twitter:card' content='summary' />
            <meta name='twitter:site' content='@YOURTWITTERHANDLE' />
            <!-- End Twitter Card -->

            <!-- OpenGraph, for most other automated unfurls (Discord, Slack). Twitter uses this data too. -->
            <meta property='og:type' content='website' />
            <meta property='og:url' content='https://THIS PAGE URL HERE'>
            <meta property='og:title' content="YOURTWITCHNAMEs Twitch Stream" />
            <meta property='og:description' content="A DESCRIPTION OF YOUR TWITCH STREAM" />
            <meta property='og:image' content='https://IMAGE-HERE' />
            <!-- End OpenGraph -->

            <!-- Page Body (displayed for a moment during the redirect) -->
            Redirecting to the <a href="">stream</a>

This will create a card that looks roughly like this:

If you don't know HTML this may look kind of daunting, but let's go through it. This is divided into three major sections: Twitter Card data, OpenGraph data, and a page body. Twitter Card data tells Twitter what to populate as a card. OpenGraph data is identical to this, but targets other services like Slack, Facebook, etc. It's basically the exact same thing as Twitter cards, but a more "open" format other services can use without worry that Twitter will change the format on them. Then the page body will be (very briefly) displayed while redirecting to your Twitch stream.

A Twitter Card is supposed to be more data than twitter:card and twitter:site, but any field missing can be pulled in from OpenGraph data, so the OpenGraph tags are doing double duty here. Don't nix them.

You will need to tweak a lot of things here. Starting from the top:

  1. meta http-equiv="refresh" content="0;url=" is the tag that redirects visitors to your stream. You should update that URL to be your Twitch URL. Don't touch the 0 in the tag. That's supposed to be there.
  2. meta name='twitter:site' content='@YOURTWITTERHANDLE' must be changed to reflect your Twitter handle, or the cards may not embed in Twitter.
  3. meta property='og:url' content='https://THIS PAGE'S URL HERE' should be edited to include the URL of the page itself. So if your web page is, this URL should also be
  4. meta property='og:title' content="YOURTWITCHNAME's Twitch Stream" can be anything. It will be the title of the Twitter Card.
  5. meta property='og:description' content="A DESCRIPTION OF YOUR TWITCH STREAM" can also be anything. It will be the body of the Twitter Card.
  6. meta property='og:image' content='https://IMAGE-HERE' will be a link to the image on the left of the Twitter Card. This image should be uploaded to your web space and the link edited to reflect where it is properly.
  7. "Redirecting to the <a href="">stream</a>" is a link visitors can click if the automatic redirect fails. It should be updated to your Twitch URL.

Step Three: Testing

You're ready to test now. There's two major tests you want to do:

Test #1: Redirection

First, visit your web page in your browser. What should happen is you'll see a flash of white with the text "Redirecting to the stream" (or whatever you put in the body tags), and then you should redirect automatically to your Twitch stream. If it doesn't redirect at all, you may have accidentally broken the meta http-equiv="refresh" tag in the document. If it redirect to the wrong place or an error page, you may have malformed the URL of your Twitch page.

If the white flash doesn't happen and you go straight to an error, you may have a problem with your web server or how you created the file. Troubleshooting that is slightly beyond the scope of this guide. Make sure the file is where you expect and is named index.html as a start.

Once you verify the redirect is working, we can test Twitter.

Test #2: Twitter Cards

A warning before we begin: Twitter caches Twitter Card data for seven days. If you tweet the URL of the redirect page, and it's wrong, it will take a week for Twitter to "forget" that wrong info. So don't tweet the URL as is. Instead, add garbage GET parameters to the end of the URL. So if your redirection URL is, instead test with, then, and so on. Once you're sure you have it right, you an use the real URL.

You can tweet to test the card, but let's do something less spammy. If you kept the Twitter Card data above, you can use Twitter's own testing tool to check if your card is correct. Visit the Card Validator and inset the URL of your redirection page with garbage parameters appended as instructed in the paragraph above. You should either get an error explaining what to do to fix your card if it's broken, or a preview of exactly how the card will look in a tweet. Make any tweaks you need to to the page and test again to see the new card. Once it looks the way you want, you should be good to go.

In the future, any time you tweet the redirection URL, the card will appear below your tweet and anyone clicking it should be redirected to your stream. You can test it now if you like, without the parameters on the URL since we verified the card works and looks as you expect.

If you care about other formsts such as Facebook, Slack, etc you can test there too. Do the same thing as before with the GET parameters, to make sure those platforms don't cache incorrect data.

Assuming your card looks the way you want and sends you where you want people to go, you're all set. You can tweet, chat, etc that URL anywhere you want and the embed will appear (if the platform supports it). Have fun!

Bonus Points 1: What Data Does This Give us?

A few years ago, anyone who made a Twitter Card could access a cache of data on who clicked their link. This didn't give specifics but broke down demographics if you care about that sort of thing. Unfortunately (or maybe fortunately if you're a privacy advocate), this data got moved sometime recently and is now only accessible to ad partners of Twitter. So Twitter isn't going to give you a ton of data, but there's one important bit you may be interested in. If you view any tweet with your redirection link in it, you can click the vertical bar graph glyph to get analytics including how many clicks your link got. So you at least know how many times people are clicking your link from your tweets.

As a bonus, the Twitch Stats page will break out your domain as a source of clicks for analytics so that will tell you how many viewers actually showed up in your stream as a result of the link too. You can see that in action under the "Views From Outside Twitch" section of the stats.

In addition, if you have access to server logs or analytics from your web host, you can see how many times your redirection page has been hit, and exactly when. This could show you things like how long it is before people notice your link (to help you calibrate a startup routine so you're not doing anything important before people are viewing, or even when to stream in general). You could also maybe get IP information on who clicked your link, to better understand where your viewers are from.

Again, this isn't super interesting to most people unless they're going for partner or full time streamer status.

Bonus Points 2: A Cool Redirection Page

Your redirection page displays its contents in the body tags in the 0.2-0.5 seconds it's trying to redirect. Right now, if you followed the guide verbatim, that's only a white page with black text reading "Redirecting to the stream" but what if you wanted to put something substantial here instead? There's a few reasons you'd want to do this:

  1. A momentary display of your stream info and rules
  2. You stream to more than one service and want to give people a choice
  3. You just want some extra flashiness in your redirect, and want to display a logo or image or something before your viewers are redirected

You should consider this carefully. Right now the redirect is (mostly) transparent. Making your users wait, or click another link, may drive them away from clicking next time. That said, here's how you can do it if you know a bit of HTML:

First, decide how long you want the page to wait before redirecting. If you're just showing a cool image it could be 2 or 3 seconds. If you're displaying rules it should be long enough for the user to read the rules.

After that, design your page. You'll either need to know HTML, or use a web page editor. I'll throw the "this is beyond the scope of this guide" disclaimer here again, but as one thing you should be sure to include is a direct link to your stream to let the viewer skip waiting, or if the redirect fails. Also it goes without saying but don't delete all the tags we included for the Twitter Cards or they will break. Finally, if you've decided to add an actual wait before redirection, you should mention somewhere that the viewer will be redirected in so many seconds, so they don't get confused and leave.

Finally, change how long the page waits to redirect to your stream. Go find this tag again: meta http-equiv="refresh" content="0;url=". The "0" in the content section represents how many seconds to wait before redirecting. Change this to your preference.

If you're streaming to multiple services (such as Twitch and Mixer), you could include links to both streams in this page, and set the auto-refresh to redirect to Twitch if the viewer doesn't make a choice in 5 seconds. If you don't want to force a default choice at all, you can completely remove the meta-refresh tag and make the viewer click one or the other to continue.

If you really wanted to get creative you could skip the redirect altogether, embed your stream in this page, and add a ton of other stuff so you have full control over the viewing experience, but I don't know if I'd recommend that :)

Additional Reading

  1. A Slack Developer's Exhaustive Guide On Unfurls and Cards
  2. Github Pages: A Way to Serve HTML Pages if You Don't Have A Server