I wish to implement a timeline feature on a website I am developing for a Twitter timeline. One option I have is crawlable and available directly under Twitter's settings under "widgets:
<a class="twitter-timeline" href="https://twitter.com/hyttetomter" data-widget-id="289297710840954880">Tweets by #hyttetomter</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>
The code is firstly not valid script for XHTML so I looked for a plugin or script that was and foundthis plugin that was and found a plugin called Tweet for jQuery as it's customizable for CSS, but is this crawler friendly?
What are the tecnicalities that seperate script that is crawlable from that which isn't? Should I just turn of JavaScript to see for myself? Is jQuery content ever crawl-able and what actions must (assuming there are) I take to make any of my own jQuery-generated content crawlable? I have found mixed references online regarding this so please direct me to a trustworthy resource if you feel it can assist me.
Crawlers fetch HTML pages. That is their only functions. They get the name of your stylesheets and javascripts because they are part of your HTML document head (as link and script tags) but their purpose is neither to style the pages nor enhance the behaviour. They fetch HTML static information and parse in order to make assumptions about its content. If your content is being generated after a javascript trigger, then the crawlers are not going to get it.
One solution to make it crawler-friendly is to make a fallback for them. But this has to involve rendering your twitter information on the server-side. Facebook does this:
<noscript>
<meta http-equiv="refresh" content="0; URL=/home.php?_fb_noscript=1" />
</noscript>
Facebook inserts this meta tag in its document header. It is only triggered for noscript cases (hence, crawlers), and refreshes the page with the given url, which in the facebook case means "render the wall on the server-side, dude doesn't have javascript". Of course, crawlers have to know how to proceed with this tag.
Related
I am currently building a project, which is a survey creator. I created a Rest API on the backend with pure Node.js, and am also working on the frontend.
Obviously, rendered pages need to be rendered depending whether a user is logged in or not, the current survey, etc. Normally, I use Express.js and integrate a template engine like Pug. However this project was designed to be as dependency-less as possible, so no template engines. Instead I simply send "static" HTML files to the client when the user sends a request. Then, on the frontend, I use template strings to "fill in" HTML like this:
document.querySelector('cta').insertAdjacentHTML('beforeend', `<div class="login" style=${isLoggedIn? "display: none;" : ""}`); // etc.
This made me wonder if I am really building a dynamic website. Technically, I am "dynamically" generating the HTML?
But there seem to be conflicting messages from the Wikipedia definition and a Udemy course, both which seem to say that dynamic websites are generated on the server side like this:
When user hits request:
Backend builds template --> compiled to html --> file served to user
The way I do it looks like this:
Html file served --> JavaScript generates html
The terminology is very important here - is my website dynamic or static?
TLDR: it is a hybrid page. If you do not care on SEO it may be redundant to worry about such things, just do in a way that convenient for you.
So, your thinking way is valid, if you provide clients with the page which contents never changes on the client's side - it is the static page. You may show/hide the existing pre-rendered elements (like changing style attribute from display: none;). Any manipulations with shadow DOM or attaching HTML elements on the runtime promotes the page from "static" to dynamical or hybrid page.
Next, if you navigate to a new page on your website and you see the browser fetches a new .html file for the new page to display, it is a mark for the static page. But, if contents of the fetched page are changed afterwards by the script of your website on the client side the page cannot be called "static" anymore, is more like hybrid or dynamic page. Re-rendering the same page is about single-page-applications, all the pages of it are pure dynamic pages.
The main point why we care about is it static page, dynamic page, or hybrid page is SEO optimisation. Web crawlers analyze your page contents to detect what is your page about, to show later in Google, Bing, etc. The crawlers may (and mostly will) analyze your dynamical content in a bit unexpected way for you, so some your target audience risk never see your page. Thus, if you need the crawlers to analyze your page as "internet toy shop" you should fetch all the promotional and descriptional contents from the server and never change it afterwards. If you are making something like users personal cabinet, you can omit worrying on such stuff and just generate contents on the client's side.
As long as it works without the JS I would say that it is a static website with progressive enhancement, as the pages are not generated by the server on each request and then JS (if enabled) is used the provide additional non essential features or functionality.
A static website contains Web pages with fixed content. Each page is coded in HTML and displays the same information to every visitor. Static sites are the most basic type of website and are the easiest to create. Unlike dynamic websites, they do not require any Web programming or database design. A static site can be built by simply creating a few HTML pages and publishing them to a Web server.
Source
So in my opinion plain html without any frontend, any backend generation is static website, what you describing is dynamic website.
So it is something very basic, consider it as generated pdf, you cannot change it, in order to modify it you would need to go to file edit it, save, and then publish to end users
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>My static website</title>
</head>
<body>
<p> Static means no process </p>
</body>
</html>
I want to include an external (external domain) html page into my page. For SEO reasons iframe, object or embed are not useful, there are just a link in my source file. PHP's include function is very helpful but it causes many problems for UI. I want contents of include function and view of iframe.
How can I do that?
Thanks.
There's no reasonable alternative to <iframe>.
Who knows if you could extract the markup from the site from the server-side and print that HTML inside a <div> in your own site, but I doubt that this could ever work, because if the whole target site does AJAX requests, WebSockets or whatever, it should be secure enough to block you from performing them from other domains than allowed ones by themselves (i.e. their official domains).
If you are adding content from an external source the it should really have 0 impact on your SEO. Needs to be your own content as far as I am aware. You could try scraping the external source and using Ajax add it to your page using $().load() or similar... Wouldn't recommend though!
Here's the thing.
Recently I've tried to add FB like button to some website I'm administrating and that was easy, but now I have a request I don't know how to handle.
The thing is, when you like some website, on your FB wall is posted a link (and some other stuff maybe) to that website, its by default and I know I can change that.
What I need is this, on my page I have a (html)div that is loaded dinamycally with some important data and I need to post that particular data on my FB wall.
I tried using javascript and open graph meta tags but it seems to me that these meta tags cannot be changed dinamycally.
If anyone has an idea how to do this, feedback is more than welcome.
Sincerely,
Milos
No, you technically cannot do this.
When you share a link on Facebook, Facebook servers visits the URL specified on sharing, collents META information and displays those.
However, Javascript runs after content is loaded and on browsers, and I don't think Facebook servers run javascripts before getting META information.
Therefore, even if you change Open graph meta tags dynamically, FB still uses old tags (which is set on initial page load).
You should figure out a way to set content before sending HTML to client.
I found a solution to this issue. This can be done using iframe to integrate FB like button. Piece of infrormation you need to do this can be found here.
It shows the FB like button and you can add your url in without having to mess up with meta tags
I am quite new to web application development and I need to know how would I make other sites use it.
My webapp basically gets a username and returns some data from my DB. This should be visible from other websites.
My options are:
iframe. The websites owners embed an iframe and they pass the userid in the querystring. I render a webpage with the data and is shown inside the iframe.
pros: easy to do, working already.
cons: the websites wont know the data returned, and they may like to know it.
javascript & div. They paste a div and some javascript code in their websites and the div content is updated with the data retrieved by the small javascript.
pros: the webside would be able to get the data.
cons: I could mess up with their website and I don't know wow would I run the javascript code appart from being triggered by a document ready, but I wouldn't like to add jquery libraries to their sites.
There must be better ways to integrate web applications than what I'm thinking. Could someone give me some advice?
Thanks
Iframes cannot communicate with pages that are on a different domain. If you want to inject content into someone else's page and still be able to interact with that page you need to include (or append) a JavaScript tag (that points to your code) to the hosting page, then use JavaScript to write your content into the hosting page.
Context Framework contains embedded mode support, where page components can be injected to other pages via Javascript. It does depend on jQuery but it can always be used in noConflict-mode. At current release the embedded pages must be on same domain so that same-origin-policy is not violated.
In the next release, embedded mode can be extended to use JSONP which enables embedding pages everywhere.
If what you really want is to expose the data, but not the visual content, then I'd consider exposing your data via JSONP. There are caveats to this approach, but it could work for you. There was an answer here a couple of days ago about using a Web Service, but this won't work directly from the client because of the browser's Same Origin policy. It's a shame that the poster of that answer deleted it rather than leave it here as he inadvertently highlighted some of the misconceptions about how browsers access remote content.
If i would have such script on website
<noscript>
<meta http-equiv="refresh" content="0; URL=/Noscript">
</noscript>
The content of my /Noscript saying that user cannot properly use web site without JavaScript enabled and contains information how to turn JavaScript on
So it will redirect each request to /Noscript page if client javascript is disabled.
But it is a bit scary because i think what would happend if search engine bot come to my web site, is it will be redirected to that page was well?
So i mean would it affect SEO(Bing, Google etc) somehow ?
Does search engine bots ignored <noscript> tags?
Take a page from Stack Overflow, and other good sites...
Don't require javascript for basic operation!
Then gently prod the user:
"This site requires javascript for full functionality."
And, yes, having a separate page for non-JS browsers will hurt your SEO.
Google frowns on having different content for JS and non-JS users, too.
Search engine spiders will not follow META Redirect tags. In addition, using the META Redirect tag forces your visitors to first load the old page, then load the new page, which is a drain on a site with substantial traffic.
Sorry, Forget to paste the reference page:
http://www.seologic.com/faq/url-redirect-script.php
And I think the biggest problem with using this method is that the web page is included in the visitor's page history, and when the user clicks the "back" button and reaches the redirection page again they will be immediately returned to the redirection-target page.