The great site barrier for content in SharePoint has been
the pivot for development projects for long. Ranging from custom event
handlers, custom timer jobs, even custom windows services etc. to harvest data
from cross sites have been common talk.

And then SharePoint 2013 walks in like a boss and turns off
the switch on all of above. The question is how this fits with your needs and
where/how can you avoid custom code?

A simple example can be when you want to publish the content
secured behind your intranet to extranet or to the internet site. With this
feature you can pull news/blog entries from the company’s intranet and publish
them on your public website. This will act like a passive hot link to the item
on your secured site with the refresh rate dependent on the search crawl.

Basics

There are a few logical components to consider

An authoring site is where content is created
and hosted

A catalog is an attribute that you can add to a
list or a library in the authoring site. Marking a list or a library as a
catalog makes the content easily accessible to other site collections.

Search is the engine/glue that connects your
catalog to a publishing site.

The term store holds metadata terms that are
used to organize content for publishing on target sites.

A publishing site is where visitors go to see
and read content.

Limitation

The content which can be indexed is the requirement for
cross site publishing. The files (images, documents) still need to be handled traditionally.

Benefits of Using Cross Site Publishing

Site architectures will have a broader canvas (Do
remember to plan the assets).