lesson learned | Vidal Quevedo

It made a small modification to my site’s permalink structure while I was developing a plugin: I changed my permalink structure from /%postname% to “/%postname%/” (notice the extra “/” in the latter).

Not a big deal, right? After all, your browser understands that:

http://www.vidalquevedo.com/how-to-load-css-stylesheets-dynamically-with-jquery

is the same as

http://www.vidalquevedo.com/how-to-load-css-stylesheets-dynamically-with-jquery/

With that in mind, this should be the same for your Google Analytics, right?

WRONG!

Actually, after I made that change, Google Analytics assumed that now the same page was actually TWO different pages, so the traffic data in one started to go down, while the the data in the other started to go up:

Here’s the traffic data with the “old” permalink structure:

And this one with the new one:

Same page, but now that it was being accessed via a “different” URL (with an extra “/” at the end), Google Analytics started to see it as two different pages. (Note thatÂ apparently I made the change on Sept 12, since that’s when traffic started to move from one page to another).

Bummer.

Needless to say, now I have “duplicated” pages all over my traffic data, because the extra “/” was added to all pages on the site. I corrected the permalink to what it was before, and hopefully everything will go back to normal.

The takeway

Modifying your site’s permalink (or link) structure will definitely take a toll on your traffic data. Fortunately, in this case, peopleÂ (and search engines) can still get to the aforementioned page (phew!) But if your permalink structure has changed drastically and there are no redirection solutions implemented, a page that was ranking really high in search results will actually go down until the “new” page takes the time to crawl up, and that can take a while…

So, lesson learned: modifying your permalink structure (even slightly) WILL mess up your traffic data.

While working with Google Custom Search Engine (CSE), I needed to access elements within the <iframe> containing the search results it generated. Using jQuery, I tried to select the iframe first and its content:

$('#cse-search-results iframe').contents();

But as soon as I tried to do something with it, I’d get a “Error: Permission denied to access property ‘nodeType’” message.

Turns out, <iframes> follow the same origin policy, which prevents you from accessing them directly if they weren’t generated from your own domain. Of course, you can create a proxy file with PHP to retrieve the data first and then add the resulting HTML to your script to get around this problem.

I know, I know… it makes sense now. But I just didn’t know, so, lesson learned!