Social Icons

Pages

Showing posts with label Post URL. Show all posts
Showing posts with label Post URL. Show all posts

Monday, 26 August 2013

Blogger Magic: Pages Vs Posts

Not all blog owners know what pages are - nor how they differ from posts. We see confusion, in Blogger Help Forum: How Do I?.
How do I publish a post, which always appears on the home page?
or
How do I publish a post, which never appears on the home page?
or
How do I publish multiple posts on a page?
Long ago, we used workarounds, like publishing a post, using a future or past date. The workarounds would create a post which would always, or never, appear on the home page - but there were always side effects, from using either technique.

In 2010, Blogger gave us static pages - pages which are created and look like posts - but never appear in archive, label, or main page displays.

We were able to link to the static pages, using tabs lists and linklists, that we could create, as we liked. The pages editor has the same look and feel as the posts editor - and pages have the same look and feel as posts.

In 2011, they gave us the Pages gadget, a prebuilt XML gadget, which we use to index both posts and pages. In 2012, they gave us Custom Permalinks and Redirects, which let us use our posts and pages in imaginative ways.

Some blog owners construct blogs like static websites - until they run up against the Blogger static pages limit.

The static pages limit will be a problem, for those who never bother to note the functional differences between dynamic pages (also known as "posts"), and static pages (also known as "pages") - until their uncontrolled use of static pages restricts continued blog expansion.

Look at some examples of dynamic and static content.

This is a dynamic page URL, from this blog:
http://blogging.nitecruzr.net/2013/08/blogger-magic-pages-vs-posts.html
See the "/2012/04/"? That denotes a dynamic page, with a date.

This is a second dynamic page URL, from this blog:
http://blogging.nitecruzr.net/search/label/Pages
The "/search/label/" also denotes a dynamic page.

This is a third dynamic page URL, from this blog:
http://recipes.nitecruzr.net/
External pages are also dynamic, because their content is not controlled as part of this blog.

This is a static page URL, from this blog:
http://blogging.nitecruzr.net/p/topics.html
See the "/p/"? That denotes a static page. A static page can appear like a single post, with slight differences.

The limit on static pages is a resource issue. Static pages require specific resources, pre allocated to every blog. Increasing the limit on static pages, as with increasing the limit on number of labels, would require a change to all blogs. Such resources are limited, just as everything is limited, in some way.

Even if you can have only up to 20 static pages, you can index an unlimited amount of dynamic pages, using the Pages gadget, and adding "Web address" entries. There is no limit, with dynamic pages.

When you add the combinations of dynamic and static pages, with the possibilities of custom redirects, you get many different possibilities, and different possible advantages - and this will look like magic, to the untrained eye.

>> Top

Friday, 23 August 2013

Recovering A Deleted Page Or Post, Chapter 3

We've been advising anxious blog owners, for some time, how to recover deleted pages and posts.

The easiest solution, in the long run, is to recover the PageID / PostID, and re publish the deleted page / post.

Unfortunately, all deleted pages and posts can't be edited and re published. With new posts, un indexed by the search engines, you won't be able to find the post in cache - and you'll never determine the PostID. This will be a frequent problem with deleted pages - as static pages generally won't get indexed by the search engines - nor will they ever be included in the blog posts feed.

In some cases, even when you know the PageID or PostID, the page editor / post editor may simply reject your attempt to re edit - and give you another bX code.

Even so, all is not lost. You may have to rebuild the page or post - but you can generally keep the URL, of the deleted page or post, operational. Just plan the rebuilding process.

In cases where a deleted page or post can't be simply re published, you can publish a replacement page or post - and redirect both your readers, and the search engines, from the URL of the deleted page / post, to the replacement page or post.

To minimise loss of reader and search engine reputation, you'll want to publish a replacement page / post as soon as possible after the old page / post is mistakenly deleted. With replacement posts published in the same month as the original - and with all pages - this can cause the well known ugly URL suffix, to prevent a duplicate URL.

When you publish a replacement page or post, you have one chance to get the title and URL right - and prevent the ugly URL suffix. The one chance ends, when you hit the "Publish" button.

With a deleted post, you can use the Custom Permalink option ("Permalink", under "Post settings", in the post editor window) to make the published URL slightly different from the default. Alternately, you'll need to deliberately choose a slightly different Title, for the replacement post.

When you publish a replacement page, you won't have a "Custom Permalink" option. Your only option, in this case, is to choose a slightly different Title, for the replacement Page.

Static page URLs do not contain the year and month of publishing, so you'll need to use a different Title for every replacement page - even if you publish the replacement in a later month, or even a later year. Since static pages are generally not as widely publicised as posts, the different title should still be preferable to the alternative - the ugly page URL suffix.

Just choose the title and URL carefully, before you hit "Publish", to prevent long term embarrassment. And having published the replacement, setup a Custom Redirect, to keep the URL of the deleted page or post operational.

>> Top

Sunday, 18 August 2013

The Mysterious URL Hashtag Suffixes

From time to time, we see evidence of anxiety, in Blogger Help Forum: Something Is Broken.
Why do my posts have hashtag suffixes?
and from some, more anxiety
How do I know what hashtags to add, when referencing my posts?
These two blog owners don't understand the purposes of the suffixes.

Third party post linking services, like AddThis and LinkWithin, add the hashtags, to give them the ability to track access of the posts - in a blog which uses their service to link the posts.

Use of the hashtags is not required, simply to access the posts. In fact, including the hashtags, outside the context of the service providing the post links, could interfere with the service's ability to consistently track use of their product.

AddThis provides a reference Why is there an extra string after my url after putting your codes?.
They're there so that we can collect analytics when someone copies the URL out of the address bar instead of going through our sharing tool. It shouldn't affect people linking to your site and can provide insight into what content is the most popular on your site.

Essentially, the hashtags are not needed for accessing the posts in the blog. If you add the hashtags when referencing the posts outside AddThis, you may be creating false tracks of AddThis use. If you care about consistent reporting within AddThis, you probably should not add the hashtags to any of your own code.

Leave the hashtags to the internal portions of AddThis, LinkWithin, or whatever third party post linking service that you're using. AddThis even provides an option, to eliminate the hashtags completely.
If they're not wanted or are causing issues, you're free to disable address bark sharing tracking.
and
More information about address bar sharing analytics is available here: http://www.addthis.com/help/address-bar-sharing-analytics

Stop worrying about details which don't affect you - and get back to work on blog content.

>> Top

Sunday, 17 March 2013

Recovering A Deleted Page Or Post, Chapter 2

Blog owners have been deleting their pages and posts, then changing their minds later, since Blogger started providing the ability to delete pages and posts.

We've been advising anxious blog owners, for some time, how to recover deleted pages and posts. The easiest solution, in the long run, is to recover the PageID / PostID, and re publish the deleted page / post.

When the deleted page or post cannot be re published, the next option is to re build the page / post, possibly using feed cache.
Using this technique, you'll have to reformat the post content, as feed content is formatted relatively simply. When you publish the post, it will publish as a new post, with a new URL - so any external references to the missing post URL will still be broken.
Thanks to the recently offered Custom Redirects option, though, we can make this latter choice slightly less undesirable.

When a deleted page or post has to be rebuilt from the beginning, the classic prognosis was not good.
  1. The content is retrieved or rewritten, then re formatted.
  2. The page / post is re published, but under a new URL.
  3. The readers, and the search engines, adjust to the new URL being used.
For many blog owners, issue #3 is the cruelest blow - as the blog suffers reputation loss, from readers and search engines seeing
404 Not Found
for the deleted page / post.

Given enough determination and time, the blog owner can get through issues #1 and #2 - but issue #3 is the gift that just keeps on giving. Using Custom Redirects, though, that does not have to be the case.

It's a simple solution - and your readers and the search engines don't have to do anything unusual.
  1. Rebuild the page / post, using a carefully chosen Title / URL.
  2. Add a Custom Redirect.
    • From: The deleted (previously published) URL.
    • To: The new (re published) URL.
  3. The readers, and the search engines can view the re built page / post contents using the old URL - and update their record of the URL, as convenient to them, to point to the new URL. And the page / post never goes offline.
And you, the blog owner, can get back to work on new pages and posts.

>> Top

Monday, 18 February 2013

Custom Redirects, And Old FTP Published Blog URLs

Long ago, Blogger blog owners would publish a blog as part of an existing website. With the website published as "www.mydomain.com", they would create a website subdirectory "www.mydomain.com/myblog", and publish the blog there.

The option to publish a blog as "www.mydomain.com/myblog" required an externally maintained domain / website - and the Blogger feature "FTP Publishing". In 2010, Blogger, with many man hours spent fixing a constant stream of problems, retired "FTP Publishing", in favour of "Custom Domain Publishing".

Custom Domain Publishing, like FTP Publishing, lets us publish our Blogger blogs to non BlogSpot URLs. Unlike an FTP published blog, a custom domain published blog requires a separate subdomain for each different blog. If a non Blogger website is hosted as "www.mydomain.com", a Blogger blog can only be published to "blog.mydomain.com" - and "www.mydomain.com/blog" became an impossibility.

Last year, Blogger introduced Custom Redirects, as part of the "Search Preferences" feature. Now, once again, a Blogger blog can be addressed as "www.mydomain.com/myblog", when hosted as "www.mydomain.com" - though a non Blogger website (if one exists) cannot be directly hosted as "www.mydomain.com", simultaneously.

It may be possible, however, to host an externally published website as "site.mydomain.com", and a Blogger blog as "www.mydomain.com" - and use the Blogger "Missing Files Host" feature to locate website pages, dynamically, in "site.mydomain.com". There may be hope, for people who declined to migrate their FTP Published blogs, in 2009 - and who now have static "blogs" as frozen pages in their external websites.

>> Top

Monday, 21 January 2013

Removing The "/p/" From the URL

Ever since Blogger (finally) gave us the option to add static pages to our blogs, blog owners started asking
How do I make my pages URLs cleaner? The "/p/" in the URL is so messy looking.
Our typical response would be simple.
Sorry, you're stuck with the URL, as is, for a static page.
And, that was that.

Later, Blogger gave us the ability to redirect URLs within the blog - and that changed.

This is the URL of the topics index in this blog ("labels", to use the Blogger native term).
http://blogging.nitecruzr.net/p/topics.html
Here are two alternate URLs, which also reference the topic index.
http://blogging.nitecruzr.net/topicindex
and
http://blogging.nitecruzr.net/topic-index
Click on each link, and note where you go.

To make the alternate URLs work, all that I did was use "Custom Redirects", and add two entries.
From: /topicindex
To: /p/topics.html
and
From: /topic-index
To: /p/topics.html
Of course, the address displayed will be the address published - not the address entered into the browser. You can't change the address displayed - you can only simplify what has to be entered. And, to maintain proper spam mitigation policy, you can only redirect within the base URL of the blog.

Other than that, the possibilities are almost endless.

>> Top