Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Section for legacy or situational meta? #59

Closed
scottaohara opened this issue May 3, 2016 · 3 comments
Closed

Section for legacy or situational meta? #59

scottaohara opened this issue May 3, 2016 · 3 comments

Comments

@scottaohara
Copy link
Collaborator

scottaohara commented May 3, 2016 •
edited

In doing a bunch of research on meta elements, I was thinking that it may make sense to section out some of the meta content into different buckets of usefulness / don't-use categories.

For example, the following meta data I've found to not really be recommended for inclusion in the head, as there are better ways to declare this sort of information:

<meta name="language" content="en">

Used to declare a language for the document, but is not really well supported. It's better to use <html lang="">

<meta name="robots" content="index,follow">

Often ignored by search engines, it's far more beneficial to use a robots.txt file or to modify the .htaccess file instead.

<meta name="revised" content="Sunday, July 18th, 2010, 5:15 pm">

There's no real evidence that this is actually used by any search engines. Instead set a published or edited date in the mark-up.

<meta name="reply-to" content="email@example.com">

Don't use this, use a contact page instead. Doing this provides an easy way for malicious bots to scrape emails from websites

<meta name="author" content="name, email@example.com">
<meta name="designer" content="">
<meta name="owner" content="">

Use a <link rel="author"> to humans.txt file or author website/page instead.

<meta http-equiv="refresh" content="300;url=https://example.com/">

Google has gone on record of strongly recommending this not being used.
Set up appache redirects instead.

<meta http-equiv="Expires" content="0">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">

Better to do caching server side rather than in meta data

I want to be clear that I think these elements should not be removed from the list of meta elements, but that they should instead be sectioned off as meta elements that people could come across, but really shouldn't be used anymore for the reasons mentioned above.

Thanks!
@scottaohara scottaohara mentioned this issue May 4, 2016
Merged
@joshbuchea
Copy link
Owner

I couldn't agree with you more @scottaohara! All excellent points. If you'd like to submit one or more PRs for this, I'd gladly accept 😄 And I'll work on adding these in if I don't see a PR for them. Thanks @scottaohara!

@khaosdoctor khaosdoctor mentioned this issue May 4, 2016
Merged
@scottaohara
Copy link
Collaborator Author

Again, thank you to both @joshbuchea and @khaosdoctor.

Very happy to help out as I can here.

@joshbuchea
Copy link
Owner

Thanks @scottaohara and @khaosdoctor! Definitely appreciate the help.

@khaosdoctor khaosdoctor mentioned this issue May 7, 2016
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@joshbuchea @scottaohara