I use Hugo to deploy static web, using Markdown and the problem I would like to sort out is simple.
I would like to find the simplest and compatible with Markdown language way to make my web links open in different tab.
The method I use now is below:
< rawhtml >}}Rasmus Lerdorf</br>{{< /rawhtml >
[link with title](http://nodeca.github.io/pica/demo/ "target="blank")
First method working but it is HTML second method not working.
Thank You.
You need to create a new file at /layouts/_default/_markup/ called render-link.html.
In that file, you can then customise it to something like:
<a href="{{ .Destination | safeURL }}"{{ with .Title}} title="{{ . }}"{{ end }}{{ if strings.HasPrefix .Destination "http" }} target="_blank" rel="noopener"{{ end }}>{{ .Text | safeHTML }}</a>
Here is what would happen:
[link1](../something/ title="title") => link1
[link2](https://example.com) => link2
It will only add it to URLs with "http" and "https".
The documentation for render-hooks is available here: https://gohugo.io/templates/render-hooks/.
Or you could just put the link in as you have it using regular, old HTML.
IMHO, beating yourself up over the failings of Hugo and whatever theme is in use is counter-productive. Markdown was supposed to be a quick and dirty way for users who couldn't grasp the basic fundamentals of html to create and display content on a wiki.
Think about the current situation. Does using Hugo, a theme, and Markdown really save any effort when they simply can't produce the output you need because the features you need don't exist in that combination natively?
When you need to spend hours/days researching and learning how to manipulate the generator's template to generate the output you need from Markdown and Hugo, tell me, where exactly are those time savings?
This is why people using tools such as Flare, RoboHTML, and Paligo laugh at users who brag about how fast they Hugo site generates html pages.
I want to add <link rel="alternate" href="https://www.example.com" hreflang="en-us" /> this kinda of link tag in my bigcommerce site using jQuery or anything else...
Tried code:
1:
if ($("body#home").length > 0) {
$('head').add($('<link rel="alternate" href="https://www.example.com" hreflang="en-us" />'));
}
2:
var page = window.location.pathname;
if (page == '/' || page == '/index.html') {
$('head').add($('<link rel="alternate" href="https://www.example.com" hreflang="en-us" />'));
}
3:
if ($("html").hasClass("home")) {
$("head").append("<link rel=alternate href=https://www.example.com hreflang=en-us>");
}
But nothing worked for me....
Let's first give some background on hreflang and the three valid ways that Google will read it..
HTML link element in header. In the HTML section of http://www.example.com/, add a link element pointing to the Spanish version of that webpage at http://es.example.com/, like this:
<link rel="alternate" hreflang="es" href="http://es.example.com/" />
HTTP header. If you publish non-HTML files (like PDFs), you can use an HTTP header to indicate a different language version of a URL:
Link: <http://es.example.com/>; rel="alternate"; hreflang="es"
To specify multiple hreflang values in a Link HTTP header, separate the values with commas like so:
Link: <http://es.example.com/>; rel="alternate"; hreflang="es",<http://de.example.com/>; rel="alternate"; hreflang="de"
Sitemap. Instead of using markup, you can submit language version information in a Sitemap.
Source: Google 'hreflang' Usage
So Method 2 isn't possible since you can't modify or control the headers from your BigCommerce store.
This leaves us with Method 1 or Method 3.
The big question here though is..
"Will Google index & process a dynamically inserted JavaScript hreflang link tag"?
Unfortunately at the time of writing this, I need to wait several days for the Google Webmaster Tool to become active on my test site so I can be certain; while all the 3rd party hreflang test sites I used failed. My gut feeling is that I would not trust it. However, if you have an active Google Webmaster / Search Console account, you can test this by going to: Dashboard > Search Traffic > International Targeting.
But for the sake of argument, let's assume that it will work, and so to answer your specific question, you would go about this method like so...
Within the <head>...</head> block, create an empty link tag like so: <link id="lang1" /> This will have the link element physically in the DOM awaiting its attributes to be dynamically added.
Next, immediately below the link element created above, let's create the JavaScript that will turn this empty link tag into a complete hreflang reference depending on the current page:
<script>
// If current page is homepage, then append the neccessary attributes to the link tag. Else, do nothing.
// If on homepage, the link tag would become: "<link id="lang1" rel="alternate" href="https://www.example.com" hreflang="en-us" />"
window.location.pathname == '/' ? $("#lang1").attr({"rel": "alternate", "href": "https://www.example.com", "hreflang": "en-us"}) : false;
</script>
And that's about it from the coding side. If you run this and inspect the DOM (it won't be viewable in page source), you can confirm that your link tag now reads as: <link id="lang1" rel="alternate" href="https://www.example.com" hreflang="en-us" />
Again, whether or not Google will process this, I don't know.
But here's an alternative I do know will work...
We can follow Method 3 listed above, and submit language version information via your site's sitemap, which can specify which individual and specific pages have alternative language versions.
Now, you do not have access to directly modify your BigCommerce generated Sitemap. But what you do have access to, is to:
Create your own custom sitemap file, and upload it to your store.
Tell Google to use the URL of this custom sitemap, rather than the default BigCommerce one.
There are plenty of resources online on how to create a sitemap, and there are many tools that can help automate this process. Although beware, if you use a custom sitemap, then you will need to maintain it and manually update it whenever you add new pages or products to your store.
I've taken the time to point you to some specific documentation resources that should help you with this task. I will eventually come back to this post to transcribe the content from these links into this post as I do recognize posting links is bad SO practice. A hardass might say "well why are you doing it then", and well my time is limited and I'm trying to be as helpful as I can now upfront.
Here is a link from the Google Docs with information on creating a sitemap with page specific language versions.
Here is a link from the BigCommerce Docs with information on uploading a custom file to your store which can then be accessible via your domain/URL.
Finally, here is a link from the BigCommerce Docs with information on how to direct Google to use a specific/alternate file as your store's sitemap.
Please attempt the code suggestion I wrote for Method #1 and test it using your Google Webmaster's tool to let us know if the hreflang link tag is successfully crawled by Google when dynamically inserted via JavaScript - you would be doing the community a great service as there is no definite answer around this.
Remember, you can officially test this by logging into your Google Webmaster Console and navigating to Dashboard > Search Traffic > International Targeting
I'm trying to add a new 'project' category to a morea based site, where there will be a page similar to experiences page where I'll collect all course project related experiences and assignments, and maybe even modules.
Is it ok to look for pages with 'project' in their id or maybe better to tag with a new morea tag?
Do I need to also create a new entity type called 'project' or just reuse existing entities
In MoreaGeneraor.rb I couldn't find where module level page collections are prepared, like for example module_page.data['morea_experiences'].
I thought of preparing a similar collection of 'morea_project' pages and then traversing it in the new project page.
Is that done outside of this .rb file? by Jekyll? so how do I inject my collection.
Any simpler idea?...
Thank
p.s. I've also added the following (from line 3) to 'processMoreaFile()', but it does not seem to be visible at later stages:
elsif new_page.data['morea_type'] == "assessment"
site.config['morea_assessment_pages'] << new_page
if new_page.data['morea_id'].include?('project')
site.config['morea_project_pages'] << new_page
puts "--- project page #{new_page.data['morea_id']}\n "
end
but still do not know where to let each module page find out about it's 'project' pages
This is a cool idea. The simplest approach is to avoid making changes to MoreaGenerator.rb, and instead do it using normal Jekyll mechanisms. Here's a sketch:
Add a morea_label called "Project" to each associated module, reading, experience, and assessment.
In master/src, create a new directory called project, containing a file called index.md. This adds a new top-level page to your site (i.e. http://example.com/ics101/project/index.html)
Implement the index.md file with liquid tags to create the desired page layout for your project page. For inspiration, see the index.md files in the other top-level pages (readings, experiences, etc.). You can access YAML content in Liquid.
Once you've got your rocking project page done, you'll want a link to it in the navbar. See add a menu item for instructions.
Good luck! If you get it working to your satisfaction, please post its link as a followup to this question so we can see how it turned out!
I see two issues with AngularJS application regarding search engines and SEO:
1) What happens with custom tags? Do search engines ignore the whole content within those tags? i.e. suppose I have
<custom>
<h1>Hey, this title is important</h1>
</custom>
would <h1> be indexed despite being inside custom tags?
2) Is there a way to avoid search engines of indexing {{}} binds literally? i.e.
<h2>{{title}}</h2>
I know I could do something like
<h2 ng-bind="title"></h2>
but what if I want to actually let the crawler "see" the title? Is server-side rendering the only solution?
(2022) Use Server Side Rendering if possible, and generate URLs with Pushstate
Google can and will run JavaScript now so it is very possible to build a site using only JavaScript provided you create a sensible URL structure. However, pagespeed has become a progressively more important ranking factor and typically pages built clientside perform poorly on initial render.
Serverside rendering (SSR) can help by allowing your pages to be pre-generated on the server. Your html containst the div that will be used as the page root, but this is not an empty div, it contains the html that the JavaScript would have generated if it were allowed to run.
The client downloads the HTML and renders it giving a very fast initial load, then it executes the JavaScript replacing the content of the root div with generated content in a process known as hydration.
Many newer frameworks come with SSR built in, notably NextJS.
(2015) Use PushState and Precomposition
The current (2015) way to do this is using the JavaScript pushState method.
PushState changes the URL in the top browser bar without reloading the page. Say you have a page containing tabs. The tabs hide and show content, and the content is inserted dynamically, either using AJAX or by simply setting display:none and display:block to hide and show the correct tab content.
When the tabs are clicked, use pushState to update the URL in the address bar. When the page is rendered, use the value in the address bar to determine which tab to show. Angular routing will do this for you automatically.
Precomposition
There are two ways to hit a PushState Single Page App (SPA)
Via PushState, where the user clicks a PushState link and the content is AJAXed in.
By hitting the URL directly.
The initial hit on the site will involve hitting the URL directly. Subsequent hits will simply AJAX in content as the PushState updates the URL.
Crawlers harvest links from a page then add them to a queue for later processing. This means that for a crawler, every hit on the server is a direct hit, they don't navigate via Pushstate.
Precomposition bundles the initial payload into the first response from the server, possibly as a JSON object. This allows the Search Engine to render the page without executing the AJAX call.
There is some evidence to suggest that Google might not execute AJAX requests. More on this here:
https://web.archive.org/web/20160318211223/http://www.analog-ni.co/precomposing-a-spa-may-become-the-holy-grail-to-seo
Search Engines can read and execute JavaScript
Google has been able to parse JavaScript for some time now, it's why they originally developed Chrome, to act as a full featured headless browser for the Google spider. If a link has a valid href attribute, the new URL can be indexed. There's nothing more to do.
If clicking a link in addition triggers a pushState call, the site can be navigated by the user via PushState.
Search Engine Support for PushState URLs
PushState is currently supported by Google and Bing.
Google
Here's Matt Cutts responding to Paul Irish's question about PushState for SEO:
http://youtu.be/yiAF9VdvRPw
Here is Google announcing full JavaScript support for the spider:
http://googlewebmastercentral.blogspot.de/2014/05/understanding-web-pages-better.html
The upshot is that Google supports PushState and will index PushState URLs.
See also Google webmaster tools' fetch as Googlebot. You will see your JavaScript (including Angular) is executed.
Bing
Here is Bing's announcement of support for pretty PushState URLs dated March 2013:
http://blogs.bing.com/webmaster/2013/03/21/search-engine-optimization-best-practices-for-ajax-urls/
Don't use HashBangs #!
Hashbang URLs were an ugly stopgap requiring the developer to provide a pre-rendered version of the site at a special location. They still work, but you don't need to use them.
Hashbang URLs look like this:
domain.example/#!path/to/resource
This would be paired with a metatag like this:
<meta name="fragment" content="!">
Google will not index them in this form, but will instead pull a static version of the site from the escaped_fragments URL and index that.
Pushstate URLs look like any ordinary URL:
domain.example/path/to/resource
The difference is that Angular handles them for you by intercepting the change to document.location dealing with it in JavaScript.
If you want to use PushState URLs (and you probably do) take out all the old hash style URLs and metatags and simply enable HTML5 mode in your config block.
Testing your site
Google Webmaster tools now contains a tool which will allow you to fetch a URL as Google, and render JavaScript as Google renders it.
https://www.google.com/webmasters/tools/googlebot-fetch
Generating PushState URLs in Angular
To generate real URLs in Angular, rather than # prefixed ones, set HTML5 mode on your $locationProvider object.
$locationProvider.html5Mode(true);
Server Side
Since you are using real URLs, you will need to ensure the same template (plus some precomposed content) gets shipped by your server for all valid URLs. How you do this will vary depending on your server architecture.
Sitemap
Your app may use unusual forms of navigation, for example hover or scroll. To ensure Google is able to drive your app, I would probably suggest creating a sitemap, a simple list of all the URLs your app responds to. You can place this at the default location (/sitemap or /sitemap.xml), or tell Google about it using webmaster tools.
It's a good idea to have a sitemap anyway.
Browser support
Pushstate works in IE10. In older browsers, Angular will automatically fall back to hash style URLs
A demo page
The following content is rendered using a pushstate URL with precomposition:
http://html5.gingerhost.com/london
As can be verified, at this link, the content is indexed and is appearing in Google.
Serving 404 and 301 Header status codes
Because the search engine will always hit your server for every request, you can serve header status codes from your server and expect Google to see them.
Update May 2014
Google crawlers now executes javascript - you can use the Google Webmaster Tools to better understand how your sites are rendered by Google.
Original answer
If you want to optimize your app for search engines there is unfortunately no way around serving a pre-rendered version to the crawler. You can read more about Google's recommendations for ajax and javascript-heavy sites here.
If this is an option I'd recommend reading this article about how to do SEO for Angular with server-side rendering.
I’m not sure what the crawler does when it encounters custom tags.
Let's get definitive about AngularJS and SEO
Google, Yahoo, Bing, and other search engines crawl the web in traditional ways using traditional crawlers. They run robots that crawl the HTML on web pages, collecting information along the way. They keep interesting words and look for other links to other pages (these links, the amount of them and the number of them come into play with SEO).
So why don't search engines deal with javascript sites?
The answer has to do with the fact that the search engine robots work through headless browsers and they most often do not have a javascript rendering engine to render the javascript of a page. This works for most pages as most static pages don't care about JavaScript rendering their page, as their content is already available.
What can be done about it?
Luckily, crawlers of the larger sites have started to implement a mechanism that allows us to make our JavaScript sites crawlable, but it requires us to implement a change to our site.
If we change our hashPrefix to be #! instead of simply #, then modern search engines will change the request to use _escaped_fragment_ instead of #!. (With HTML5 mode, i.e. where we have links without the hash prefix, we can implement this same feature by looking at the User Agent header in our backend).
That is to say, instead of a request from a normal browser that looks like:
http://www.ng-newsletter.com/#!/signup/page
A search engine will search the page with:
http://www.ng-newsletter.com/?_escaped_fragment_=/signup/page
We can set the hash prefix of our Angular apps using a built-in method from ngRoute:
angular.module('myApp', [])
.config(['$location', function($location) {
$location.hashPrefix('!');
}]);
And, if we're using html5Mode, we will need to implement this using the meta tag:
<meta name="fragment" content="!">
Reminder, we can set the html5Mode() with the $location service:
angular.module('myApp', [])
.config(['$location',
function($location) {
$location.html5Mode(true);
}]);
Handling the search engine
We have a lot of opportunities to determine how we'll deal with actually delivering content to search engines as static HTML. We can host a backend ourselves, we can use a service to host a back-end for us, we can use a proxy to deliver the content, etc. Let's look at a few options:
Self-hosted
We can write a service to handle dealing with crawling our own site using a headless browser, like phantomjs or zombiejs, taking a snapshot of the page with rendered data and storing it as HTML. Whenever we see the query string ?_escaped_fragment_ in a search request, we can deliver the static HTML snapshot we took of the page instead of the pre-rendered page through only JS. This requires us to have a backend that delivers our pages with conditional logic in the middle. We can use something like prerender.io's backend as a starting point to run this ourselves. Of course, we still need to handle the proxying and the snippet handling, but it's a good start.
With a paid service
The easiest and the fastest way to get content into search engine is to use a service Brombone, seo.js, seo4ajax, and prerender.io are good examples of these that will host the above content rendering for you. This is a good option for the times when we don't want to deal with running a server/proxy. Also, it's usually super quick.
For more information about Angular and SEO, we wrote an extensive tutorial on it at http://www.ng-newsletter.com/posts/serious-angular-seo.html and we detailed it even more in our book ng-book: The Complete Book on AngularJS. Check it out at ng-book.com.
You should really check out the tutorial on building an SEO-friendly AngularJS site on the year of moo blog. He walks you through all the steps outlined on Angular's documentation. http://www.yearofmoo.com/2012/11/angularjs-and-seo.html
Using this technique, the search engine sees the expanded HTML instead of the custom tags.
This has drastically changed.
http://searchengineland.com/bing-offers-recommendations-for-seo-friendly-ajax-suggests-html5-pushstate-152946
If you use:
$locationProvider.html5Mode(true);
you are set.
No more rendering pages.
Things have changed quite a bit since this question was asked. There are now options to let Google index your AngularJS site. The easiest option I found was to use http://prerender.io free service that will generate the crwalable pages for you and serve that to the search engines. It is supported on almost all server side web platforms. I have recently started using them and the support is excellent too.
I do not have any affiliation with them, this is coming from a happy user.
Angular's own website serves simplified content to search engines: http://docs.angularjs.org/?_escaped_fragment_=/tutorial/step_09
Say your Angular app is consuming a Node.js/Express-driven JSON api, like /api/path/to/resource. Perhaps you could redirect any requests with ?_escaped_fragment_ to /api/path/to/resource.html, and use content negotiation to render an HTML template of the content, rather than return the JSON data.
The only thing is, your Angular routes would need to match 1:1 with your REST API.
EDIT: I'm realizing that this has the potential to really muddy up your REST api and I don't recommend doing it outside of very simple use-cases where it might be a natural fit.
Instead, you can use an entirely different set of routes and controllers for your robot-friendly content. But then you're duplicating all of your AngularJS routes and controllers in Node/Express.
I've settled on generating snapshots with a headless browser, even though I feel that's a little less-than-ideal.
A good practice can be found here:
http://scotch.io/tutorials/javascript/angularjs-seo-with-prerender-io?_escaped_fragment_=tag
As of now Google has changed their AJAX crawling proposal.
Times have changed. Today, as long as you're not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers.
tl;dr: [Google] are no longer recommending the AJAX crawling proposal [Google] made back in 2009.
Google's Crawlable Ajax Spec, as referenced in the other answers here, is basically the answer.
If you're interested in how other search engines and social bots deal with the same issues I wrote up the state of art here: http://blog.ajaxsnapshots.com/2013/11/googles-crawlable-ajax-specification.html
I work for a https://ajaxsnapshots.com, a company that implements the Crawlable Ajax Spec as a service - the information in that report is based on observations from our logs.
I have found an elegant solution that would cover most of your bases. I wrote about it initially here and answered another similar Stack Overflow question here which references it.
FYI this solution also includes hard coded fallback tags in case JavaScript isn't picked up by the crawler. I haven't explicitly outlined it, but it is worth mentioning that you should be activating HTML5 mode for proper URL support.
Also note: these aren't the complete files, just the important parts of those that are relevant. I can't help with writing the boilerplate for directives, services, etc.
app.example
This is where you provide the custom metadata for each of your routes (title, description, etc.)
$routeProvider
.when('/', {
templateUrl: 'views/homepage.html',
controller: 'HomepageCtrl',
metadata: {
title: 'The Base Page Title',
description: 'The Base Page Description' }
})
.when('/about', {
templateUrl: 'views/about.html',
controller: 'AboutCtrl',
metadata: {
title: 'The About Page Title',
description: 'The About Page Description' }
})
metadata-service.js (service)
Sets the custom metadata options or use defaults as fallbacks.
var self = this;
// Set custom options or use provided fallback (default) options
self.loadMetadata = function(metadata) {
self.title = document.title = metadata.title || 'Fallback Title';
self.description = metadata.description || 'Fallback Description';
self.url = metadata.url || $location.absUrl();
self.image = metadata.image || 'fallbackimage.jpg';
self.ogpType = metadata.ogpType || 'website';
self.twitterCard = metadata.twitterCard || 'summary_large_image';
self.twitterSite = metadata.twitterSite || '#fallback_handle';
};
// Route change handler, sets the route's defined metadata
$rootScope.$on('$routeChangeSuccess', function (event, newRoute) {
self.loadMetadata(newRoute.metadata);
});
metaproperty.js (directive)
Packages the metadata service results for the view.
return {
restrict: 'A',
scope: {
metaproperty: '#'
},
link: function postLink(scope, element, attrs) {
scope.default = element.attr('content');
scope.metadata = metadataService;
// Watch for metadata changes and set content
scope.$watch('metadata', function (newVal, oldVal) {
setContent(newVal);
}, true);
// Set the content attribute with new metadataService value or back to the default
function setContent(metadata) {
var content = metadata[scope.metaproperty] || scope.default;
element.attr('content', content);
}
setContent(scope.metadata);
}
};
index.html
Complete with the hardcoded fallback tags mentioned earlier, for crawlers that can't pick up any JavaScript.
<head>
<title>Fallback Title</title>
<meta name="description" metaproperty="description" content="Fallback Description">
<!-- Open Graph Protocol Tags -->
<meta property="og:url" content="fallbackurl.example" metaproperty="url">
<meta property="og:title" content="Fallback Title" metaproperty="title">
<meta property="og:description" content="Fallback Description" metaproperty="description">
<meta property="og:type" content="website" metaproperty="ogpType">
<meta property="og:image" content="fallbackimage.jpg" metaproperty="image">
<!-- Twitter Card Tags -->
<meta name="twitter:card" content="summary_large_image" metaproperty="twitterCard">
<meta name="twitter:title" content="Fallback Title" metaproperty="title">
<meta name="twitter:description" content="Fallback Description" metaproperty="description">
<meta name="twitter:site" content="#fallback_handle" metaproperty="twitterSite">
<meta name="twitter:image:src" content="fallbackimage.jpg" metaproperty="image">
</head>
This should help dramatically with most search engine use cases. If you want fully dynamic rendering for social network crawlers (which are iffy on JavaScript support), you'll still have to use one of the pre-rendering services mentioned in some of the other answers.
With Angular Universal, you can generate landing pages for the app that look like the complete app and then load your Angular app behind it.
Angular Universal generates pure HTML means no-javascript pages in server-side and serve them to users without delaying. So you can deal with any crawler, bot and user (who already have low cpu and network speed).Then you can redirect them by links/buttons to your actual angular app that already loaded behind it. This solution is recommended by official site. -More info about SEO and Angular Universal-
Use something like PreRender, it makes static pages of your site so search engines can index it.
Here you can find out for what platforms it is available: https://prerender.io/documentation/install-middleware#asp-net
Crawlers (or bots) are designed to crawl HTML content of web pages but due to AJAX operations for asynchronous data fetching, this became a problem as it takes sometime to render page and show dynamic content on it. Similarly, AngularJS also use asynchronous model, which creates problem for Google crawlers.
Some developers create basic html pages with real data and serve these pages from server side at the time of crawling. We can render same pages with PhantomJS on serve side which has _escaped_fragment_ (Because Google looks for #! in our site urls and then takes everything after the #! and adds it in _escaped_fragment_ query parameter). For more detail please read this blog .
The crawlers do not need a rich featured pretty styled gui, they only want to see the content, so you do not need to give them a snapshot of a page that has been built for humans.
My solution: to give the crawler what the crawler wants:
You must think of what do the crawler want, and give him only that.
TIP don't mess with the back. Just add a little server-sided frontview using the same API
I am working on a website that will marketed in China, and I would like to know if there is a method to create "share" buttons for Renren (Similar to Facebook), Weibo (Similar to Twitter) and Baidu Like (Similar to Google's +1) using only HTML.
For example, for Facebook, Twitter and Google's +1 you would use the following:
http://twitter.com/share?url=http://example.com&text=Description
http://www.facebook.com/sharer.php?u=http://example.com
https://plusone.google.com/_/+1/confirm?hl=en&url=http://example.com
I know that Renren uses the following:
http://share.renren.com/share/buttonshare.do?link=http://example.com&title=Description
However, I would love to know what the HTML only URLs for Weibo and Baidu Like are.
Here is the documentation for the Javascript version of the share buttons if that helps:
http://wiki.dev.renren.com/wiki/Xn:share-button
http://open.weibo.com/sharebutton
http://share.baidu.com/like/get-codes
Hopefully this can help someone in the future; here is how to implement HTML only share/like buttons for Renren, Weibo, and Baidu Like/Space/Forums/Bookmarks:
Renren
As mentioned above, use the following URL format to share a link on Renren:
http://share.renren.com/share/buttonshare.do?link=http://example.com&title=Description
Weibo
The following URL format will allow you post to your Weibo account, in the same manner as you would for Twitter:
http://service.weibo.com/share/share.php?url=http://example.com&appkey=&title=Description&pic=&ralateUid=&language=zh_cn
Baidu
Baidu has multiple services that can be posted to; the one relevant to this post is Baidu Like, but I have provided URLs for Baidu Space, Forums, and Bookmarks for reference as well:
To like a link in in the same manner as Facebook/Google +1, using the following URL structure:
http://like.baidu.com/set?buttontype=small&cb=bdShare.ajax._callbacks.bd4bb141b&index=0&url=http://example.com
I tracked the above URLs down using a packet analyser, and as far as I can tell, Baidu Like has to be called from the referring page, or at the very least, the referring domain. The callback function bd4bb141b does not seem to be specific to any domain or user ID.
Please note that I have not tested the following URLs structures thoroughly:
To share a link on Baidu Space, use the following URL structure: http://apps.hi.baidu.com/share/?url=http://example.com&title=Description
To share a link on Baidu Tieba (Forums), use the following URL structure: http://tieba.baidu.com/i/app/open_share_api?link=http://example.com
To save a link to Baidu Cang (Bookmarks), use the following URL structure: http://cang.baidu.com/do/add?it=Description&iu=http://example.com
Also for reference, a good Chinese alternative to FeedBurner is FeedSky.
With my own site (currently) the share button does not show up when using httpS ... but it does with http
Here is the link to the most recent (November 10th, 2015) Weibo share button code generator (scroll to the bottom to get the code):
http://open.weibo.com/sharebutton