SEO Specialist Interview Questions

"I started writing blog posts for a small online shop while I was at college, and the owner asked me why some posts got visitors for years while others died in a week. I didn't know, so I started reading, set up Search Console, and worked out that the posts that lasted answered a question people actually searched for. That was the hook. Since then I've spent two years at an agency, mostly on technical audits and content plans. What keeps me in SEO rather than paid is that the work compounds. A fix I ship this month can keep paying back for years, and I like the detective side, working out why a page isn't showing up. I want an in-house role now so I can see one site through over a longer stretch."

"On my CV I say organic sign-ups from our guides section roughly doubled in a year. My part was the plan and the technical work. I found that about forty guides were competing for the same searches, so I merged them into twelve stronger pages with redirects, rebuilt the internal links from the product pages, and wrote the briefs for the rewrites. The writers did the rewriting, and a developer fixed a slow template I'd flagged. Some of the growth was also the market, because the whole category grew that year. To be fair about it, I compared the merged pages against a set of guides we didn't touch, and the merged ones grew much faster. So I'd claim the diagnosis and the plan, and share the rest with the team."

"I split my sources into two groups. The first is primary: the search engines' own documentation, their official blogs and their notices of confirmed updates. The second is practitioners I trust, people who share their data and methods rather than hot takes. When I hear a new claim, I ask whether there's evidence and whether it matches what I see in our own Search Console data. If it's interesting but unproven, I test it on a small set of pages before changing anything big. I also keep notes on what I tested and what happened, so the team builds its own knowledge instead of borrowed opinions. That keeps me calm during update weeks, which helps everyone around me stay calm too."

"In the first couple of weeks I'd mostly listen and look. I'd ask what organic search is meant to drive for the business, what changed on the site in the last year, and whether there were any migrations. Then I'd go into Search Console: which pages are indexed and which aren't and why, which queries and pages bring clicks, and whether there are any manual actions or security issues. I'd run a crawl to find broken links, redirect chains and pages nothing links to, and check the main templates for speed problems. Anything that blocks crawling or indexing goes straight to the top. The bigger things, like restructuring content or adding new sections, I'd leave until I understand the business and have a baseline, so I'm not changing things I can't measure."

"I measure at three levels. Visibility, meaning impressions and average position for the queries and pages we care about. Traffic, meaning clicks from search and organic sessions in our analytics. And business results, like sign-ups, leads or sales from organic visitors, because that's what the company actually cares about. In Search Console I use the Performance report for clicks, impressions, click-through rate and position by query, page, country and device. I use the page indexing report to see what's indexed and why pages are left out, URL inspection for single pages, plus the sitemaps, Core Web Vitals and manual actions reports. I compare like with like, such as the same period last year for a seasonal business, and I note every release so I can connect changes to results."

"We once rewrote the title tags on around two hundred product pages to lead with a keyword I was confident about because it had more search volume. I changed them all at once, and after a few weeks click-through rate on those pages went down, even though positions barely moved. When I looked at the actual queries, people were searching with the product model number, which I'd pushed to the end of the title where it got cut off. The titles matched the keyword tool, not the searcher. I rolled back half the pages as a comparison, and those recovered. What I learned was to check real queries in Search Console before rewriting anything, and to test on one group of pages against a similar untouched group before changing everything."

"When I joined my current company, my first crawl listed over two thousand issues, and the tool marked hundreds as critical. Most didn't matter, like missing alt text on decorative icons. I sorted issues by two things: how many important pages each one affected, and how hard it was to fix. At the top were a staging robots rule that had leaked onto our help pages and a redirect chain on the main category pages. Both hit pages with real traffic and both were quick fixes. Next came template-level problems, where one change fixes thousands of pages. I parked the long tail. I showed the team a list of ten, not two thousand, with the expected impact of each, and we cleared the top five within a month."

"There are three steps. First, crawling: the search engine's bot discovers the URL, usually through a link from another page or from our sitemap, and fetches it. Second, indexing: it renders the page, running JavaScript if needed, works out what the page is about, picks a canonical version if there are duplicates, and decides whether to store it at all. Not every crawled page gets indexed. Third, ranking: when someone searches, it pulls candidate pages from the index and orders them using lots of signals, like how relevant the content is to the query, how helpful and trustworthy it looks, the links pointing to it, and page experience. So when a page isn't showing, the first thing I do is work out which of those three steps it's failing at."

"On-page is everything on the page itself that helps it match a search and satisfy the person: the content, the title tag, headings, how well it answers the question, image alt text, internal links. An example is rewriting a product page title and adding the details buyers actually compare. Off-page is what happens elsewhere that signals trust, mostly links from other sites, but also mentions and reviews. An example is earning a genuine link from an industry site because we published original data. Technical is making sure search engines can crawl, render and index the site properly, so speed, redirects, canonicals, robots rules and sitemaps. An example is fixing a template that accidentally put noindex on every blog category page. They overlap, but the split helps me plan work."

"I start with how our customers describe the problem, from sales calls, support tickets and our own site search, not just from a tool. Then I expand those seeds in a keyword tool to see related terms, rough volume and difficulty. For intent, the best evidence is the results page itself. If the top results are guides, the intent is informational. If they're category pages with prices, it's commercial or transactional. If it's all one brand's pages, it's navigational. I write for what the searcher wants, not what I wish they wanted. Then I group terms that bring up mostly the same results, because one page can serve them, and map each group to a single URL so our own pages don't end up competing with each other."

"First, it matches the intent better. If people want a quick comparison, a long essay loses to a clear table. Second, it adds something the other page doesn't: first-hand experience, original photos or data, or steps someone actually tested, instead of rewording what already ranks. Third, it earns trust. There's a real author with relevant experience, claims are sourced, and it's kept accurate, which is roughly what people mean by experience, expertise, authoritativeness and trust. That isn't a single score, it's a description of what good content looks like. Length and keyword repetition aren't the point; covering the questions a searcher has next is. And it's supported by the site: strong internal links pointing to it, links from others because it's worth citing, and a page that loads cleanly without ads in the way. Keeping it ranking means reviewing and updating it, not just publishing it."

"Before choosing, I'd look at each post in Search Console: which queries they get impressions for, whether they swap places for the same query, and which one has the most links and traffic. If they're chasing the same intent, that's cannibalisation, and I'd usually merge. I'd keep the strongest URL, fold the useful parts of the other two into it, rewrite it so it's clearly the best answer, and 301 redirect the other two to it. Then I'd update internal links to point straight at the kept URL instead of through redirects. A brand-new URL only makes sense if none of the three has anything worth keeping, like links or history. After that I'd watch the kept page's impressions and position for a few weeks."

"I'd agree with the goal, being found in local searches, but push back on the method. Five hundred near-identical pages with only the city name swapped look like doorway pages, which search engine spam policies call out, and even if nothing gets penalised, most of them probably won't be indexed or rank. I'd ask where we actually serve customers and have something real to say. For those cities, maybe a few dozen, I'd build pages with genuinely local content, like the team there, local case studies, delivery times, local rules that differ by area, and real reviews. For the rest, one strong service page is usually enough. I'd suggest launching the first batch, measuring indexing and leads, and only expanding if they work."

"An editor on our team felt my brief for a guide forced an awkward keyword into the headline and every subheading, and said it read like it was written for a robot. She was partly right. I'd copied the exact phrase from the keyword tool, but search engines understand natural variations well. We sat down with the results page for that search and looked at what the top pages actually covered. We agreed the headline would use the natural phrase once, and I'd focus the brief on the questions searchers needed answered rather than on keyword counts. The piece read better and reached the first page within a couple of months. I changed all my briefs after that: intent, questions to answer and sources first, with keywords as a guide, not a quota."

"Internal links do three jobs. They help search engines discover pages, they pass authority from strong pages to the ones we care about, and the anchor text tells users and search engines what the target is about. On a large site, I'd start with a crawl to find orphan pages that nothing links to, and important pages that sit too many clicks from the home page. Then I'd find our strongest pages, usually the ones with the most external links, and make sure they link sensibly to key category or product pages. I'd use descriptive anchor text instead of 'click here', fix links that go through redirects, and add related-content blocks to templates, so good linking happens automatically instead of someone doing it by hand."

"I ask two questions: would a real person click it, and would the site link to us even if search engines didn't exist? A good link comes from a relevant, genuine site with its own audience, sits inside real content, and was given because we had something worth pointing to. Third-party authority scores are a quick filter, but they're estimates made by tools, not something the search engine itself uses. Links I'd avoid are paid links that aren't marked as sponsored, link swaps done at scale, private blog networks, and sites that exist only to sell links. At best those get ignored, and at worst they lead to a manual action. I'd rather earn five links from respected sites in our field than buy fifty from a spammy list."

"I'd take the request seriously, because what they really want is faster growth, and I'd explain the risk plainly. Paid links meant to pass ranking credit break search engine spam policies. At best the search engine learns to ignore them and we've wasted the budget. At worst we get a manual action and lose rankings we already earned. I'd go through a sample of the vendor's sites with them, because usually they're thin sites with no real readers. Then I'd offer an alternative for the same budget: a piece of original research, a useful free tool, or outreach to publications our customers actually read. I'd give a realistic timeline and a way to measure it, so the conversation ends with a plan and not just a no."

"robots.txt controls crawling, not indexing. If I disallow a URL there, well-behaved bots won't fetch it, but the URL can still end up in the index if other pages link to it, usually shown without a description. A noindex tag, or the same rule sent as an HTTP header, controls indexing: the bot crawls the page, sees the rule, and keeps it out of the results. The catch is that the bot has to crawl the page to see noindex. So if I block a page in robots.txt and also add noindex, the noindex is never read. I use robots.txt to stop bots wasting time on things like internal search results or endless filter combinations, and noindex for pages people can visit but that shouldn't show in search, like thank-you pages."

"Duplicate content isn't a penalty in itself, but it splits signals and wastes crawling. I'd pick one clean URL per product and make everything agree with it: a self-referencing canonical on the clean URL, canonicals on the parameter versions pointing to it, and internal links and the sitemap using only the clean URL. A canonical is a strong hint, not a command, so if our own links keep pointing at parameter URLs, the search engine may choose a different one. For filters that create thousands of near-empty combinations, I'd first stop linking to them in a crawlable way. If crawl waste is still bad, I'd block the worst patterns in robots.txt, but never the tracking-parameter URLs, because a blocked page is never fetched, so its canonical is never read. Then I'd check in URL inspection which canonical was chosen."

"There are three right now. Largest Contentful Paint measures loading, how long until the main content shows, and good is 2.5 seconds or less. Interaction to Next Paint measures responsiveness, how quickly the page reacts to clicks, taps and key presses across the visit, and good is 200 milliseconds or less. It replaced First Input Delay. Cumulative Layout Shift measures visual stability, how much things jump around, and good is 0.1 or less. They're judged on real-user field data at the 75th percentile of page loads, not on a single lab test. On priority, they're one part of page experience. It can help when lots of pages are about equally relevant, but it won't lift a page past more relevant content. So I'd fix templates that clearly fail, because slow pages also hurt conversions, but I wouldn't pause strong content work to chase a perfect score."

"Structured data is code on the page, usually JSON-LD, that describes the content using the schema.org vocabulary, like saying this is an article by this author, or this is a product with these reviews. What it can do is help search engines understand the page and make it eligible for rich results, like review stars, product details or breadcrumbs. What it can't do is guarantee those rich results appear, and it isn't a direct ranking boost. The markup also has to match what people can see on the page. Marking up reviews users can't see breaks the guidelines and can lead to a manual action. I test it with a rich results testing tool before release and watch the enhancement reports in Search Console for errors afterwards."

"First I'd confirm it with a live test in URL inspection, look at the rendered HTML and the screenshot, and check for blocked resources, because sometimes the fix is just a script or API path blocked in robots.txt. If the content still isn't there, the page depends on JavaScript that isn't running successfully for the crawler, maybe because of errors, timeouts, or content that only loads after a click or scroll. Rendering can also be delayed, so even working JavaScript can slow indexing. The reliable fix is server-side rendering or pre-rendering the important parts, so the product name, description and links are in the HTML response itself. I'd also check that links are real anchor tags with an href, not click handlers. And I'd bring the developers example URLs and evidence, not just a complaint."

"Local results come down mostly to relevance, distance and prominence, so I'd work on what we control. First, a separate verified business profile for each branch, with the right main category, accurate hours, photos and services. Second, the name, address and phone number written the same way everywhere: the profiles, the website and the main directories. Third, a page on the website for each branch with real local detail, like the address, a map, parking, the team there and the services offered at that location, linked from the main navigation and marked up with local business structured data. Fourth, reviews: an easy way to ask happy patients for one, and a polite reply to every review, including the bad ones. I'd track calls, direction requests and bookings per branch, not just rankings."

"I'd start with data before theory. In Search Console, if impressions and average position are steady but click-through rate is falling on informational queries, something on the results page is taking the click. AI-generated summaries are a likely cause, along with other features. I'd check a sample of those searches by hand and show the CEO screenshots, because the reports don't make it easy to isolate AI answers cleanly. Then what we change: make our pages the clearest, most specific source, so we're more likely to be the one cited, with direct answers early, original data or first-hand experience, and clean structure. I'd make sure the pages are crawlable and fast. And I'd shift some effort toward searches where people still click, like comparisons and buying decisions, and judge success by leads, not clicks alone."

"First I check it's real. I'd compare analytics with Search Console clicks, because a broken tracking tag can look exactly like a crash. If Search Console shows the drop too, I segment it by pages, queries, devices and countries. A sudden drop across the whole site points to something technical, so I'd ask what was released on Friday and check robots.txt, noindex tags, canonicals, redirects and server errors, and run URL inspection on a few key pages. If only certain page types or topics dropped, I'd check the dates of confirmed search updates and whether the results page itself changed. I'd also look for a manual action. By midday I'd send my manager a short note saying what I've ruled out and what I'm checking next."

"I'd raise it the same day, in writing, with whoever owns the launch, and be clear about the risk: without redirects the old URLs return errors, we lose the links pointing at them, and rankings can take months to recover. Then I'd make it easy to fix. I'd crawl the current site, pull every page with traffic or links from Search Console and analytics, and build a one-to-one map from each old URL to its closest new page, using 301 redirects, not everything dumped on the home page. I'd ask to check the new site on staging for leftover noindex tags, a blocking robots.txt, canonicals and internal links. If two weeks isn't enough to do it safely, I'd recommend moving the date. After launch I'd test the redirects, submit new sitemaps and watch the indexing and error reports daily."

"A few years ago a section of our blog lost a lot of traffic in the same week a confirmed search update rolled out, and I told my manager it was the update and we needed to improve content quality. Before we started rewrites, a developer asked if I'd checked the release notes. I hadn't. A template change the week before had moved the article body into a tab that only loaded after a click, so the rendered page was nearly empty. I'd matched a date to a story without checking the simpler explanation. We fixed the template, and traffic came back within a few weeks. I told my manager plainly that my first diagnosis was wrong. Since then I check releases, tracking and rendering before blaming any algorithm, and I keep a change log next to our traffic charts."

"I'd be honest: nobody can guarantee a ranking, because we don't control the search engine, and anyone who promises one is either guessing or planning something risky. But I wouldn't stop there. I'd look at the keyword with them: who ranks now, how strong those pages are, and whether their site has a page that truly matches what searchers want. Then I'd set goals we can control and measure, like fixing the technical issues in the first month, publishing a stronger page, and tracking impressions, position and leads from that page over the next three to six months. I'd also show them related, less competitive searches where they could win sooner. In my experience, clients respect a clear plan more than a promise."

"At my last company, our category pages had filters that created a huge number of crawlable URLs, and Search Console crawl stats showed the bot spending most of its time on them, while new products took weeks to get indexed. The dev team's sprint was full, so a ticket saying 'fix crawl budget' was never going to win. I pulled the server logs to show exactly where the crawler went, and linked it to money: new products that weren't findable in search during launch week. Then I made the ticket small and clear, with the exact URL patterns, the change I wanted and how we'd test it. The lead developer took it the next sprint. Afterwards, new products showed in search within a few days, and I shared the result with the dev team, which made my next request easier."

"In my agency role I presented a quarterly report to a client's finance director who'd just inherited the marketing budget. My usual report was full of rankings and impressions, and I could see it meant nothing to her. So I rebuilt it around three questions she cared about: how many enquiries came from search, how that compared with the same quarter last year, and what we'd do next. I kept one chart for the traffic trend and moved the technical detail to an appendix. When she asked why one page had dropped, I compared it to a shop being moved from the main street to a side street. She renewed the contract and asked for the same format every quarter. Since then I always start with the business number and only use SEO terms if someone asks."

"I work best where SEO is involved early, not called in the day before launch. In my last role we added a short SEO checklist to the ticket template, so developers flagged anything touching URLs, templates or robots rules, and I reviewed it during planning instead of after release. I like working in the open, with a simple dashboard everyone can see, and explaining the reason behind each request so people start spotting issues themselves. I don't need to own every change. What frustrates me is SEO treated as a last-minute gate, because that's when migrations go wrong. If I joined a team that isn't set up that way yet, I'd start by building a good relationship with the dev lead and the content lead, and earn a seat in planning."