Welcome to the Q&A Forum

My site serves a consumer-focused industry that has about 15-20 well recognized categories, which act as a pretty obvious way to segment our content. Each category supports it's own page (with some useful content) and a series of articles relevant to that category. In short, the categories are pretty focal to what we do.

I am moving from DNN to WordPress as my CMS/blog. I am taking the opportunity to review and fix SEO-related issues as I migrate. One such area is my URL structure.

On my existing site (on DNN), I have the following types of pages for each topic:

/ <topic>- this is essentially the landing page for the topic and links to articles</topic>

/<topic>/articles/ <article-name>- topics have 3-15 articles with this URL structure</article-name></topic>

With WordPress, I am considering moving to articles being under the root. So, an article on (making this up) how to make a widget would be under /how-to-make-a-widget, instead of /<widgets>/article/how-to-make-a-widget I will be using WordPress categories to reflect the topics taxonomy, so I can flag my articles using standard WordPress concepts.</widgets>

Anyway, I'm trying to get my head around whether it makes sense to "flatten" my URL structure such that the URLs for each article no longer include the topic (the article page will link to the topic page though).

Thoughts?

Thank you for the response, Linda. So, this is a slightly tricky one because I don't have a specific deadline per se, but also want to build a plan that gets me over to the new server as soon as possible, without falling into a trap of the switchover date just "floating". Let me put it this way.

I have the following "phases" for each of the articles (as reminder, I have around 200 such articles):

1. Create all articles: Using the planned titles, categories and URLs but with no content.
2. Move content across from old site to the new articles. Done with straight cut-and-paste (don't ask about importing - long story :)). This gets the data into WordPress posts as-is, but includes HTML markup from the old CMS, doesn't correctly use styles (some articles look pretty messy) and doesn't have a consistent use of H2 tags (H1 is the title). Most articles look "OK" but a) some are messy but readable for the human eye and b) the lack of H2 tags means there's no structure from an SEO-perspective.
3. Clean up article HTML/structure. Review each article, cleaning up the HTML and ensuring the content still makes sense and reads well. HTML clean-up includes removing HTML relevant to the old CMS and making sure I have article structure through use of H2 tags
4. Review each article for SEO. Will be using the Yoast SEO plugin and making changes recommended. The keywords are already decided (the URLs and titles in step 1 reflect those decisions) so for each article I will be reviewing the rest of the content and making sure it looks acceptable from an SEO perspective,

I am currently done with step 2 (all articles moved across, albeit some looking somewhat untidy and without any document structure). I am starting to work through step 3 now, but this is a time-consuming process.

I guess what this all boils down to is if I switch across will search engines "catch up" later, when I revise the content for structure and SEO changes. The existing site is not good - so, as it stands, search engines don't look on the site kindly.

One option is to just bite the bullet and move across (I'd see benefits from the title and URL changes, with the associated 301 redirects in place) and subsequently do steps 3 and 4. I'd actually like to do that but ONLY if I can be confident the search engines will end up in the same place as they would if I just waited till step 4 is done.

Another option is to finish step 3, move to the new server and then start updating articles for SEO (step 4).

Thanks.

Mark

I recently joined a community related to Internet Marketing and I am finding it very useful. One of the topics that comes up a great deal is what tools folks use to investigate content gaps. I've been a Moz subscriber for quite some time and understand that, compared to many of its competitors, it's a high end solution. So, feel pretty well positioned there.

However, one thing that appears to be lacking is what might be called a long tail discovery tool. I am well aware of Google's Keyword Planner and other free stuff (the problem there being... so are my competitors :)). But there are a number of tools out there - SEMRush, Long Tail Premium, Authority Metrics and so on - that focus very directly on that, with "scores" for keyword competitiveness that at least help narrow down to a possible set, using filtering.

While I accept that one might argue the merits - or otherwise - of each of these specific tools, it causes me to wonder why Moz doesn't have such a capability. I see some very successful web site owners describing their processes in the aforementioned community and long tail analysis is a key part of that.

It seems that Moz has a richness of features, including around keyword ranking. But it's not clear to me why it doesn't support long tail keyword discovery "directly" (as a specific feature). I really don't want to pay for another subscription

Thoughts?

Thanks.

Mark

Thank you, Donna. So, I've been doing some more thinking about this and it's a difficult balance. I have two ways to look at the whole issue.

• Through the aforementioned "big buckets", such as Planning, Looking Good, Your Wedding Day, etc. I see 4, maybe 5, of these.
• Through the "topics" (cakes, dresses, etc). We have quite a number of those.

The first one is best suited as the second tier ("folders" under the root) numerically - there are, say, 4 of them. However, they are pretty broad and I don't know how successful we'd be in what are very competitive SEO areas (wedding planning, for example, is right up there). Also, apart from the article/post lists (which would be featured in those pages), I am not sure how often they would change.

The second ones are more specific, but are numerically probably too broad for the second level. But the

So, still not sure how to structure this. But one thing I would like to clarify is that if I go with the former (big, broad areas) then having them as second-level entities is no worse, presumably, than just having /blog at the second level, right? It would seem to me that /blog has very little SEO value, whereas even something broad like /wedding-planning has at least some value, right?

Thanks.

Mark

Thanks again, Alan.

I am thinking that what I probably need is to 301 redirect all URLs of the form http://blog.<domain>.com/page</domain> to http://www.<domain>.com/page</domain>, yes? In short I don't want to use the blog subdomain anywhere so, to avoid SEO inefficiencies, I should presumably redirect as above so that everything ends up at the www subdomain.

I think

Thanks.

Mark